| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
|
|
For debugging it is nice to know how many requests are
pending. Simply count it and print it besides the paging
part.
|
|
At the rhizomatica sites some unauthorized subscribers have a
last used from long time ago but a bigger reference count. This
means that we have an unbalanced subscr_get/subscr_put that we
need to investigate. These two fixes are genuine fixes but are
unlikely to fix the issue I am not understanding yet.
|
|
In case the SMPP payload didn't include the right fields we
would leak the subscr reference count.
|
|
In case the subscriber is currently busy we would omit the
subscr_put. This seems to be very hard to hit as the subscr
need to be active and at the same time be selected for the
purge operation.
|
|
Various paging clean-ups. I couldn't re-produce the assert that
was hit by Rhizomatica in the subscriber code. Let's clean things
up a bit to avoid some of the potential issues this code had.
Always stop paging regardless of where the subscriber is at the
time of the cancellation.
|
|
Implement sending MDCX on the newly allocated channel and send
the data to the same destination as the currently connected one.
This way the receiver can implement RTP RFC Appendix A.1 and
deal with the new source.
|
|
For the LCR rtp-bridge audio should directly flow to the
remote system. In contrast to the original patch audio
will now flow directly from the BTS to the remote system.
This assumes that BTS and the remote system are in the
same network segment and can directly communicate.
There are various limitations in the first iteration of
the implementation:
We could (and in the future) should delay the assignment
but currently we are forced to pick the channel and move
it to the audio state. In case we are located on a SDCCH
we always need to change but if we are on a TCH we could
send the ipa.CRCX and change the audio state a lot later.
The net effect is that the audio codec selection needs to
be done in the NITB code and not in the system connected
to it.
This only works with ip based systems. For E1 systems one
could still use the RTP socket or even try to move this
out of the process.
There is no code for handover handling and it relies on
the remote system dealing with the SSRC change of the
system.
|
|
This adds the protocol definition for the RTP bridge extension
of Andreas Eversberg and bumps the protocol version.
I added the missing mncc mappings from value to string.
[ 5cf8fb10ea3addcae74d37f4dbf1c1be664df53e protocol extension
5dac90de38990b188f499c602bf18a4f232070e8 payload extension]
|
|
In case the SMPP payload didn't include the right fields we
would leak the subscr reference count.
|
|
In case the subscriber is currently busy we would omit the
subscr_put. This seems to be very hard to hit as the subscr
need to be active and at the same time be selected for the
purge operation.
|
|
For debugging it is nice to know how many requests are
pending. Simply count it and print it besides the paging
part.
|
|
So in case somebody is starting paging from within a paging
expired callback we would dispatch the paging request right
away with the same failure.
|
|
|
|
As the comment says we should not rely that the paging
occurs on the current LAC. We might page at more BTS.
Walk all the BTS to stop paging. No callbacks will be
issued by this stop operation.
|
|
In case we can't page on a BTS then stop it everywhere. The
callers of paging_request assume that this is kind of an
atomic operation and we should help with that.
|
|
Coordinate with the normal subscriber channel requests instead
of going to page ourselves. This might lead to getting a channel
that is of a different type though.
|
|
vty_interface_layer3.c:584:4: warning: format '%d' expects argument of type 'int', but argument 3 has type 'long unsigned int' [-Wformat=]
sizeof(subscr->extension)-1, VTY_NEWLINE);
|
|
So in case somebody is starting paging from within a paging
expired callback we would dispatch the paging request right
away with the same failure.
|
|
|
|
As the comment says we should not rely that the paging
occurs on the current LAC. We might page at more BTS.
Walk all the BTS to stop paging. No callbacks will be
issued by this stop operation.
|
|
In case we can't page on a BTS then stop it everywhere. The
callers of paging_request assume that this is kind of an
atomic operation and we should help with that.
|
|
Coordinate with the normal subscriber channel requests instead
of going to page ourselves. This might lead to getting a channel
that is of a different type though.
|
|
vty_interface_layer3.c:584:4: warning: format '%d' expects argument of type 'int', but argument 3 has type 'long unsigned int' [-Wformat=]
sizeof(subscr->extension)-1, VTY_NEWLINE);
|
|
Signed-off-by: Max <max.suraev@fairwaves.co>
|
|
When two phones use the same TMSI and no A3A8 is possible
we could end in a hard to detect issue. Assume that the IMSI
will not clash and we have issues for foreign simcards.
|
|
In case foreign simcards are used we can not do authentication
and ciphering. In case a TMSI is re-used too early and we do
page using TMSI we can't know which of the two MS is responding
to us. We could change the "secure channel" routine to ask for
the IMSI and only then stop the paging.
As we don't have ciphering there is not much use in using the
TMSI. Add a mode "no assign-tmsi" that will not assign the TMSI
during LU. Now CM Service Request and Paging Response will
work using the IMSI. There can't be a clash with that.
[ciaby fixed the vty write to use the right name]
|
|
When we can't find the TMSI then the subscriber is not in our
VLR. We have not consulted with the HLR and it is better to not
use such a severe error code.
|
|
|
|
in_address is not 'accidently' included by FreeBSD when we include
the osmocom/core/select.h header file. We need to include a bit
more.
In file included from mgcp_protocol.c:38:
../../include/openbsc/mgcp_internal.h:134:21: error: field has incomplete type 'struct sockaddr_in'
struct sockaddr_in forward;
|
|
List needs to be executed from within the right configuration
node to see if it is available or not. list on the toplevel
will uncoditionally show "smpp" as part of the logging config.
|
|
Struct osmo_msc_data contains int core_ncc, which is actually the
MNC part of the PLMN, not to be confused with the Network Colour
Code.
The following patch renames this field for clarity and consistency
with the standards.
|
|
|
|
If we have tried SMPP first and it was not routable, and then
tried the local delivery there is no point in trying SMPP with
the same parameters again. Leave early and return unknown sub
to the caller.
|
|
default-route would only be looked at after there has been
no subscriber in the local database. Depending on the setup
this is not what one wants. This has been discussed at the
OsmoDevCon and there have been hacks in some branches. Let's
introduce a VTY command to select if SMPP should be consulted
first and then fallback to the current behavior.
|
|
|
|
Even if it is using BSC/NITB types let's put it in the header
file than just declaring it at a place that could bitrot in a
way that doesn't lead a warning.
|
|
The "default-route" for SMPP will be used after a local
subscriber look-up. Sometimes we want to route everything
to SMPP. Make this possible by changing this routine.
|
|
Use the same trick as done by the dlopen check to not
have everyone link against the library.
|
|
We just link to libosmovty and if it requires crypt internally it
needs to link to that (and not us). This looks like a left-over
from when we moved the VTY code out of OpenBSC
|
|
We don't need to consume all the entropy of the kernel but can
use libcrypto (OpenSSL) to generate random data. It is not clear
if we need to call RAND_load_file but I think we can assume that
our Unices have a /dev/urandom.
This takes less CPU time, provides good enough entropy (in theory)
and leaves some in the kernel entropy pool.
|
|
Introduce another authentication scheme using MILENAGE. In the
future reading from /dev/urandom will be replaced with libcrypto.
|
|
We are using the token to find the right bsc_config and
then we can use the last_rand of the bsc_connection to
calculate the expected result and try to compare it with
a time constant(???) memcmp.
|
|
Check if the NAT has sent 16 bytes of RAND and if a key
has been configured in the system and then generate a
result using milenage. The milenage res will be sent and
noth the four byte GSM SRES derivation.
|
|
Generate 16 byte of random data to be used for A3A8 by
the BSC in the response. We can't know which BSC it is
at this point and I don't want to send another message
once the token has been received so always send the data
with an undefined code. The old BSCs don't parse the
message and will happily ignore the RAND.
/dev/urandom can give short reads on Linux so loop
around it until the bytes have been read from the kernel.
|
|
Instead of doing open/read/close all the time, open the
FD in the beginning and keep it open. To scare me even
more I have seen /dev/urandom actually providing a short
read and then blocking but it seems to be the best way
to get the random byes we need for authentication.
So one should/could run the cheap random generator on
the system (e.g. haveged) or deal with the NAT process
to block.
|
|
Unfortunately the basic structure of the response is broken.
There is a two byte length followed by data. The concept of
a 'tag' happens to be the first byte of the data.
This means we want to write strlen of the token, then we
want to write the NUL and then we need to account for the
tag in front.
Introduce a flag if the new or old format should be used.
This will allow to have new BSCs talk to old NATs without
an additional change. In the long run we can clean that up.
|
|
In case the token was not correct, just close the connection.
It is not clear that forcing a new TCP connection is going to
give us any extra security here. But with the upcoming auth
handling it does make sense to have both case look similar.
|
