We put a signed integer into this string but did not account
for the newline and for the terminating NUL of the string. Add
the newline to the string and add one for NUL. Spotted while
accidently having a CID of 255.
There appears to be a leak of CIDs:
<000b> mgcp_osmux.c:544 All Osmux circuits are in use!
There are paths that a CID had been requested and never released
of the NAT. Remember the allocated CID inside the endpoint so it
can always be released. It is using a new variable as the behavior
for the NAT and MGCP MGW is different.
The allocated_cid must be signed so that we can assign outside
of the 0-255 range of it.
Fixes: OW#1493
Extend the osmux only setting from the MGCP MGW to the NAT. This
is applied when an endpoint is allocated and/or when the allocation
is confirmed by the remote system.
Not tested. The impact should only be when the new option is
being used.
Fixes: OW#1492
Some systems only want to use Osmux. In case only Osmux
should be used fail if it has not be offered/acked.
Client:
Verified On, Off and Only with X-Osmux: 3 and without this field.
<000b> mgcp_protocol.c:823 Osmux only and no osmux offered on 0x14
<000b> mgcp_protocol.c:884 Resource error on 0x14
NAT:
Not tested and implemented
Fixes: OW#1492
sizeof(uint8_t) == 1 and there is no need to create an array
with 16 bytes and then only use the first two of them. This
means the CID range is from 0 to 127 and we should be able
to extend this to 256 by changing the array size to 32. Update
the testcase now that we can have more than 16 calls with Osmux.
* Test that one can get an id
* That they are assigned predicatble right now
* That returning them will make the number of used ones go down
* That allocating more will fail
The log message does not help and says where the data is
being sent to. This is because we have both a RTP and RTCP
port. Remember if we failed with RTCP or RTP and improve
the log message.
I was searching a case where the port was bound to a local
address (e.g. 127.0.0.1) and tried to send the data to a
public one (e.g. 8.8.8.8).
The signature of mr_config and the BSC implementation didn't
match and the compiler was warning about it:
osmo_bsc_api.c:530:2: warning: initialization from incompatible pointer type
.mr_config = bsc_mr_config,
^
osmo_bsc_api.c:530:2: warning: (near initialization for ‘bsc_handler.mr_config’)
Change the mr_config again and provide an implementation
that will set the ms and bts data structure. It would be
better to put the size outside of the IE but I am not going
to change it right now. It would also be nice to either move
the AMR setting into the "nitb" structure or have the msc
data be used _after_ the bts settings. This needs to be
cleaned up in the next step.
Manually verified by placing a MO call and checking that
both the channel mode modify and the mode modify request
contain the multi rate config with the rate mr config
(length two bytes, version 1, icmi==1, no start mode being
set).
This way a lot of if/else can just be killed by the caller deciding
which of the two instances to use.
I have copied both branches to new files, replace bts for ms in one
of them and ran diff on it. There is no difference.
Merge two copies into a local static helper function. The format
of the message will change and then it is easier to modify it in
one place than in two.
Sadly the original patch was merged before this clean-up so do
the clean-up as second step.
Conflicts:
openbsc/src/libbsc/abis_rsl.c
openbsc/src/libbsc/gsm_04_08_utils.c
The pre-release didn't add a newline after the apn and the patching
pattern command. Create a quirk command that combines both. The
pre-release didn't include a differentation between routing and
patching.
The TLLI handling has a different and more generic name now. Make
it handle the old one that is actively used.
Add a file with the broken format and the standard config file
test should pick it up.
In case of the RTP bridge mode we need to select the codec
ourselves. Rely on the same (incomplete) codec selection that
can be done using the mncc-int configuration node. This might
gain bearer capabilities support.
In case of a SDCCH a TCH/F will be attempted to be assigned.
This is an open issue for both modes and there should be a
preference for full or half-rate channels somewhere.
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]
Mike's patch included clean-ups I want to apply separately and
change them a bit. If we return from an else we don't need to
put the else.
* Try the E1 trunk first
* Then try a local virtual trunk
* Fail if none of the above returned
Remove the host portion of the endpoint Id. This requires less
configuration and we are probably fine to trust that MGCP only
received messages designated for it.
When using multiple interfaces on a system one can now configure
which will be served for the BTS ports and which will be served
for the network. The direct usage of source_addr is now only to
initialize the MGCP receiving port itself.
Make it possible to bind the call-agent to a specific IP address
and the network and bts end to different ip addresses. Begin by
clarifying which source ip address we want to have.
Use the existing ulaw encode/decode to support PCMU as well.
The MERA VoIP switch has some severe issues with the GSM codec
and it appears easier to enable transcoding for it.
The mera switch doesn't appear to cope with codec change
between a SIP 180 trying and the 200 ok connection result.
Inserting the codec is touching too many places. Ideally we
should have the transcoding function as pointer in the struct
as well but the arguments differ.. so it is not a direct way
forward.
Iridium is a satellite network which operates a GPRS-like that allows you to
get speeds up to 128kbit/s. However, it takes from 5 to 6 secs to get the
bandwidth allocated, so the conversation is garbled during the time.
This patch uses the new dummy padding support in libosmo-netif that is
controlled through the osmux osmux_xfrm_input_open_circuit().
This includes a new VTY option for osmux.
I guess none of our users knows what a mi_type=0x02 is, but most would
know what an IMSI or a TMSI is. So let's use the newly introduced
gsm48_mi_type_name() function to fix this.
For some odd reasons the XID is not a separate SAPI but has been kludged into
the GMM SAPI. This means we ahve to be careful not to dispatch XID frames into
GMM. We do this by introducing an explicit check for UI frames before the
dispatch to GMM.
The previous code already was doing "the right thing" but printed occasional
messages like "gprs_gmm.c:2082 Unknown GSM 04.08 discriminator 0x01: 01 00 0e
00 32 11 03 16 01 90 63 28 0b". Those should be gone after this patch.
Traffic cannot sent to BTS, if there is (currently) no logical channel
associated with the transaction.
This happens, if TCH traffic is received from upper layer, but there is
no lchan available before completing immediate assignment, handover or
assignment process.
[hfreyther: The code has not been moved to tch_frame_down
but the issue looks similiar]
The NAT sends an incomplete SDP file for the purpose of informing
the BSC about the remote IP/PORT early. The case of an incomplete
SDP file was not considered. Check if there is a codec and if not
skip it.
TODO: We need to have a better end-point life cycle test.
We have a lot of legacy that I am afraid to break. We have
everything in place to make a good codec selection (e.g. if
we can avoid transcoding, pick the one with best quality or
the lowest speed). Right now I have a specific case where
from all options I want to pick GSM. Guard the codec compat
check behind the disallow transcoding option to make sure
to not break legacy application.
First collect everything we know and the mapping. E.g. a genuis
could remap "3" to "AMR" so we only know the codecs once we are
at the end of the SDP file. Once we have collected everything we
can select the audio codecs. The current code is compatible in
that two codecs will be selected regardless of if they make any
sense or not.
mgcp_set_audio_info could re-use some of our codec information
but then the caller in the MGCP protocol needs to be updated as
well as we use the "I: GSM" information to derive the codec from
there.
The SDP file handling will get more complicated in terms of
codec selection so let's remove it from the protocol handling
before we start blowing it up in size.
The parsing code assumed that there will be a single payload
type and this assumption is clearly wrong. Forward all of the
payload types. The code is still only extracting the first
type from the list. The variable name has been renamed to
reflect this.
Using the talloc leak report we see that there are some msgb's
that are allocated for SMS but we don't have transactions or
SMS around. We need to improve the name of the messages to
uniquely dscribe where they are from but the obvious leak does
occur in this routine.
The no available transaction id is most likely the case where
we leak memory. This should not occur and shows another issue
with the smsqueue/smpp handling. It doesn't explain the subscr
reference count issue either.
Extract of the leak report:
GSM 04.11 contains 1160 bytes in 1 blocks (ref 0) 0x2517dc0
GSM 04.11 contains 1160 bytes in 1 blocks (ref 0) 0x24b56e0
GSM 04.11 contains 1160 bytes in 1 blocks (ref 0) 0x23e7930
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.
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);
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.
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.
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.
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.
In the libfilter source code, which is built regardless of --enable-nat,
headers from libosmo-sccp were used, thus causing a build failure (see
below) when building without --enable-nat, and libosmo-sccp not being
installed (or being installed in a prefix not otherwise included in the
build).
The build fails like this:
In file included from ../../../src/libfilter/bsc_msg_filter.c:27:0:
../../../include/openbsc/bsc_nat_sccp.h:27:37: fatal error: osmocom/sccp/sccp_types.h: No such file or directory
As the includes seem not to be actually needed, this change fixes the
issue by just omitting them.
There was no context for the SCCP CREF message and this means
that the msc_con was a plain NULL pointer that was dereferenced
and the application would crash.
Use the new API to pass the incoming MSC Connection which sould
be used for the SCCP CREF message as context. The code has not
been fed with an actual SCCP CR message.
The loop was used to print all returned addresses but we can
simply pick the first one. This is fixing a coverity issue that
the loop will be executed eaxactly once (and that was on
purpose).
Simplify the code and just take the first element (which might
be NULL).
Fixes: Coverity CID#1302852
We can't do much in case the fd is failing to be registered.
There should be a timeout that is catching this and it might
be able to repair it self.
Fixes: Coverity CID#1302854
The code to do that doesn't belong to the control interface, so
abstract it out to a separate function gsm_bts_set_system_infos().
[hfreyther: Fix the coding style...]
In case the query for "hostname" will fail c-ares will append the
domain name of /etc/resolv.conf and query again. We don't want that
so claim we provide a list of domain names and then don't provide
any.
I didn't intend to have pushed the c-ares code to master yet.
For real networks we need to check if the requested APN string
is allowed and then resolve the GGSN address through DNS. There
are countries with two or three digit MNCs and one could either
try to keep a list of countries that have two/three digits or
just try both of them. I have opted for the later for the ease
of the implementation.
C-Ares doesn't allow to cancel a request so we will need to
have the MMCTX and the Lookup have different lifetimes. We simply
set ->mmctx to NULL in case the MMCTX dies more early.
The selected and verified apn_str will be copied into the out
parameter. In case no static APN/GGSN config is present and the
dynamic mode is enabled a request will be made.
c-ares is an asynchronous DNS resolver and we need it to
resolve the GGSN address. This is integrating the library
into our infrastructure. We will create and maintain a list
of registered FDs (c-ares is currently only using one of
them) and (re-)schedule the timer after events occurred.
When needing to do an asynchronous DNS query we need
to keep the TLV data around. So create a wrapper that
takes a copy of it and frees it after the call. I can
change the code to add an out parameter to decide if
the msgb should be freed or not.
Pick network failure in case the msgb could not be
cloned in the hope the MS will retry then.
A real SGSN will dynamically resolve the APN name into the
GGSN IP Address. This means that after we have collected all
information we need to start to resolve the GGSN and then
can continue.
This is a left-over from the initial system where no PDP
was provided by the system. For now if there is a subscr
attached and no PDP context provisioned. He is not allowed
to have a data connection.
Update the testcase to create the pdp list entry more
early with a wildcard and then change it to a specific
match.
Include the hlr-Number of the subscriber in the CDR. This is useful
for debugging and understanding which equipment was used during the
test. In contrast to the MSISDN the '+' is emitted as the number
must be in international format already.
Copy the hlr-Number into the sgsn_data and use it during
the purgeMS. There is no unit test that looks at the data
we send so I manually verified this by looking at the output.
Below is the output of the test that purges the subscriber.
<000f> gprs_subscriber.c:170 SUBSCR(123456789012345) Sending GSUP, will send: 0c 01 08 21 43 65 87 09 21 43 f5 09 07 91 83 61 26 31 23 f3
We have verified/selected the APN. Either based on the subscriber
data, a global APN match. But at least this SGSN has looked at
what the MS has asked for and then selected a matching GGSN.
Clear LAC/RAC with pre-defined value in the RAI.
3GPP 29.060 v7.17.0 section 7.3.1 page 23:
"The SGSN may include the Routeing Area Identity (RAI) of the
SGSN where the MS is registered. The MCC and MNC components shall
be populated with the MCC and MNC, respectively, of the SGSN
where the MS is registered. The LAC and RAC components shall be
populated by the SGSN with the value of 'FFFE' and 'FF',
respectively.”
Most SGSNs pass the IMEI(SV). We currently only enquire about
the IMEI and then pad the 'SV' with 1111b (thanks to the encoding
routine). Sadly it insists on always writing the length which
means we have to memmove the data around by a single octet.
Manually verified using the pcu-emu and looking at the trace
using wireshark.
Give the GGSN another opportunity to determine which tarif
to apply for the SGSN/subscriber. This code assumes tha the
RAN is a GERAN system but the assumption has been made in
other places as well.
For PDP context creation we always want to include the RAI
for the current mmctx. This might help commercial GGSNs to
determine which charging to apply.
The charging_id is provided by the GGSN. Copy it into the CDR
part of the data structure so it will remain present until after
the pdp context has been deleted.
Make it possible to set a filename to use for the CDR. By
default no CDR will be generated. Forbid to set the interval
of 0 seconds as this will cause a lot of work. Add a very
basic VTY test.
This is consuming the new signals and allows to install several
different CDR/observing/event/audit modules in the future. For
getting the bytes in/out the code would have had to undo what the
rate counter is doing and at the same time adding a "total" to
the ratecounter didn't look like a good idea, the same went for
making it a plain counter.
Begin writing the values one by one and open/closing a new FILE
for every log messages. This is not efficient but easily deals
with external truncation/rotation of the file (no fstat for and
checking the links and size). As usual we will wait and see if
this is an issue.
Add some new members to our PDP context structure to see what it
is about.
In case there is a subscr attached to the MM context and there
is an encoded MSISDN we will attempt to decode it and in case
of an international number prepend a '+'. Assume that the array
size of gsm_mmcc_called->number is as big as ctx->msisdn for the
strncpy.
If QoS is only three bytes it does not include the allocation/
retention policy. Otherwise it does. Copy it depending on that.
We should have a macro for the clamping to reduce code duplication.
The insanity does come from the MAP data and this seems to be
the easiest in terms of complexity. It is an array of bytes that
is transported from MAPProxy to the SGSN and then simply forwarded.
The case of more than three bytes is neither unit nor manually
tested so far.
sgsn_create_pdp_ctx should use the subscribed QoS. When selecting
the PDP context we inject the QoS to be used into the TLV structure
and use it during the request. Assume a "qos-Subscribed" structure
only with three bytes and prepend the Allocation/Retention policy
to the request.
The MSISDN should be present for "security" reasons in the first
activation of a PDP context. Take the encoded MSISDN, store it for
future use and then put it into the PDP activation request.
The MM Context contains a field for a decoded MSISDN already. As
we need to forward the data to the GGSN I want to avoid having to
store TON and NPI in another place. Simply store the data in the
encoded form.
It is a bit arbitary to decide which one is the global
and which one is the local one. We might change it around.
I don't think we want to introduce it based on BTS.
For the BSC we will have the gsm48_hdr and don't need to
find data within SCCP. For legacy reasons we need to
initialize con_type, imsi, reject causes early on and
need to do the same in the filter method.
This means we need to require a talloc context and
simply operate on the list. I had considered creating
a structure to hold the list head but I didn't find
any other members so omitted it for now.
Move the filter methods to the filter module. This is
still only usable for the NAT and the _dt/_cr filter
routines need to move back to the bsc_nat in the long
run.
For customer requirements we want to be able to do
filtering on the BSC as well. The same messages need
to be scanned and the same access-lists will be looked
at. In the future we might even split traffic based
on the IMSI. Begin with moving the code to a new top
level directory and then renaming and removing the
nat dependency.
The idea of "subscriber_get_channel" was that different
requests would be coordinated. At the same time we have
seen that the "queue" can get stuck at both 31C3 and the
rhizomatica installations.
Voice calls and SMS do not need coordination. We should
be able to send SMS on a voice channel and switch the MS
from a SDCCH to a TCH in case we establish a voice call.
The SMS code itself needs to coordinate to obey the limit
of one SMS per direction but this should be enforced in
the sms layer and not on the subscriber.
Modify the code to have a simple paging coordination. The
subscriber code will schedule the paging and register who
would like to know about success/failure.
This allowed to greatly simplify the paging response
handling for the transaction code (and in fact we could
move the transaction list into the subscriber structure
now). The code gained to support to cancel the notification
of a request (but not the paging itself yet).
TODO: Cancel paging request in case no one cares about it
anymore.
In case the default TCH/F codec is "EFR" and we do an early
assignment from SDCCH to a TCH we would assign the TCH/H
codec. This is because the lchan_type will be neither a
TCH/H nor a TCH/F.
At the same time the _gsm48_lchan_modify code to check for
half vs. full-rate is the other way around. Align both.
It is full-rate if it is not a TCH_H. This will have some
other complications down the way (early assignment on
cells with only TCH/H). So the mode should not depend on
the _current_ channel but the kind of channel we want.
Currently the src_codec const variable is set to &src_end->codec
before src_end is checked against NULL. Since the assigment is just
an address operation and the memory where it points to is only
accessed after the NULL check, this does not harm technically.
Nevertheless this is potential source for errors if that code is
changed.
This commit moves the definition below the NULL check. This does not
comply with the coding style, but it cannot be split into definition
and a later assignment due to the const qualifier.
Sponsored-by: On-Waves ehf
We might have compiled transcoding into the MGW but
we don't want to enable it for a given user. Add a new
switch that should allow that.
I had manually tested the allow-transcoding/no allow
VTY interface for the primary interface and a new trunk
using show running-config.
It is unlikely that GSM, gsm and GsM refer to different codecs.
The mera mvts does send the audio codecs in lower case even if
RFC 3551 has them in upper case (but copy and paste is sometimes
too hard).
Currently the handling of the buffers is not done consistently. Some
code assumes that the whole buffer may be used to store the string
while at other places, the last buffer byte is left untouched in the
assumption that it contains a terminating NUL-character. The latter
is the correct behaviour.
This commit changes to code to not touch the last byte in the buffers
and to rely on the last byte being NUL. So the maximum IMSI/IMEI
length is GSM_IMSI_LENGTH-1/GSM_IMEI_LENGTH-1.
For information: We assume that we allocate the structure with
talloc_zero. This means we have NULed the entire imsi array and then
only write sizeof - 1 characters to it. So the last byte remains NUL.
Fixes: Coverity CID 1206568, 1206567
Sponsored-by: On-Waves ehf
Currently some VTY command do neither check the length of the source
string before calling strncpy nor ensure NUL-termination afterwards.
This can to destination string buffers whose contents are not
NUL-teminated.
This commit adds checks and corresponding warnings to the VTY
commands 'subscriber TYPE ID name .NAME" and "subscriber TYPE ID
extension EXTENSION".
Fixes: Coverity CID 1206570, 1206569
Sponsored-by: On-Waves ehf
When handling an incoming GSUP cancellation request, the cancel_type
if effectively ignored, such that is always handled as
GPRS_GSUP_CANCEL_TYPE_UPDATE and never as WITHDRAW.
This commit fixes the expression used to set the variable
is_update_procedure.
Fixes: Coverity CID 1267739
Sponsored-by: On-Waves ehf
Currently the inner loop in show_bsc_mgcp iterates of the timeslot
interval [0, 31]. Timeslot 0 is not valid, which causes
mgcp_timeslot_to_endpoint to generate a corresponding warning and to
return an invalid endp value. That value causes an out-of-bound
read access, possibly hitting unallocated memory.
This patch fixes the loop range by starting with timeslot 1.
Note that this does not prevent mgcp_timeslot_to_endpoint from
returning an invalid endpoint index when called with arguments not
within its domain.
Addresses:
<000b> ../../include/openbsc/mgcp.h:250 Timeslot should not be 0
[...]
vty=0xb4203db0, argc=1, argv=0xbfffebb0) at bsc_nat_vty.c:256
max = 1
con = 0xb4a004f0
i = 0
j = 0
[...]
==15700== ERROR: AddressSanitizer: heap-use-after-free on address
0xb520be4f at pc 0x8062a42 bp 0xbfffeb18 sp 0xbfffeb0c
Sponsored-by: On-Waves ehf
I omitted the check as this was already done by the verify
function for this command. Please Coverity and do the check
again even if it is not necessary. I begin to doubt the
usage of a "dedicated" verify method as well.
Silences: Coverity CID 1293150
On DT messages we directly write into the tracked SCCP
connection. This means "imsi" will always be NULL at
this check. Change the code to use con->imsi
Fixes: Coverity CID 1293151
We want to have a program add entries to the allow list
this can be done using:
$ bsc_control.py -d localhost -p 4250 -s net.0.add.allow.access-list.NAME "^IMSI$"
bsc_stat_reject is treating -1 as parsing failure but for the
global barring. Change it to another return value so it is
not counted as parsing failure.
We had issues with odd behavior on the nanoBTS which lead
to the introduction of the "broken" state. On busy multi
BTS cells (e.g. rhizomatica) with wifi backhaul the timeout
we set to wait for a RF Channe Release ACK is sometimes too
little and channels are marked broken that look to be okay
(besides the still to be determined delay).
In case of a sysmoBTS we now know that we can change the
state of a broken channel back to normal in case we do
receive the right response.
Manually verified using the Smalltalk BTS code
PackageLoader fileInPackage: 'FakeBTS'
bts := FakeBTS.BTS new.
bts btsId: '1903/0/0'.
bts connect: 'localhost'.
bts waitForBTSReady.
test := FakeBTS.OpenBSCTest new.
test bts: bts.
test requireAnyChannel
... wait for NITB output
<0004> abis_rsl.c:223 (bts=0,trx=0,ts=0,ss=0) Timeout during deactivation! Marked as broken.
... process pending messages
stdin next
<0004> abis_rsl.c:735 (bts=0,trx=0,ts=0,ss=0) CHAN REL ACK for broken channel. Releasing it.
So the channel went from broken to unallocated.
Change the paging strategy based on on if a LAC override
is in place or not. In case we had changed the LAC we need
to page on all the BTS. Change the "grace" handling to
iterate over the BTS and filter out all non matching ones
LAC in case no LAC handling is active.
Manually verified all four cases with a single BTS:
* No LAC handling and grace period
* LAC handling and grace period
* No LAC handling and not lock
* LAC handling and lock.
Related: SYS#1398
For MT we can't page per lac as we don't know which BTS was
the original one. Split the grace period and normal mode into
two methods so we can bloat both of them later.
We need to use different LAC/CI towards the core network.
It is a bit problematic as LAC/CI is a per BTS attribute
so this feature only works if a BSC manages everything in
the same LAC.
Related: SYS#1398
The write_queue is designed to have a maximum amount of pending
messages and will refuse to take new messages when it has been
reached. The caller can decide if it wants to flush the queue
and add the message again, create a log. But in all cases the
ownership of the msgb has not been transferred. Fix the potential
memory leak in the failure situation.
When reading from RTP socket, the first read() may fail right after
connecting to remote socket. Subsequent read() will work as it should.
If the remote socket does not open fast enough, the transmitted RTP
payload can cause an ICMP (connection refused) packet reply. This causes
the read to fail with errno=111. In all other error cases, the errno is
logged at debug level. In all error cases, reading is not disabled.
Conflicts:
openbsc/src/libtrau/rtp_proxy.c
[hfreyther: Fix typo, stop reading in all cases but ECONNREFUSED]
If a bad TRAU frame is received, it is forwarded to MNCC application
as GSM_BAD_FRAME. The application can now handle the GAP of missing
audio. (e.g. by extrapolation)
If TRAU frames are forwarded via RTP, bad frames are dropped, but frame
counter and timestamp of RTP sender state is incremented.
Conflicts:
openbsc/src/libtrau/rtp_proxy.c
[hfreyther: Merge without testcase, fix typo]
In case:
* No message_payload and a 0 sm_length was used
* esm_class indicates UDH being present
* 7bit encoding was requested
The code would execute:
ud_len = *sms_msg + 1;
Which is a NULL pointer dereference and would lead
to a crash of the NITB. Enforce the limits of the
sm_length parameter and reject the messae otherwise.
Fixes: Coverity CID 1042373
I used strdup in case the data would not be valid from after
the call to getopt and this creates a potential leak if a user
is specifying multiple configuration files. If I depend on the
fact that the string is a pointer into the argv[] array I can
kill the strdup and fix the unlikely leak.
Fixes: Coverity CID 1206578
We are deferencing conn earlier in this function without doing
a null check. At the time deliver_to_esme is called the conn
will always exist and even the lchan is likely to be present.
Remove the null check for conn right now.
Fixes: Coverity CID 1210594
For most configurations we don't address multiple GGSNs but
only want to enforce a list of APNs. In the future we might
add a special global GGSN context but not right now.
Fixes: SYS#593
This reverts commit f81cacc681.
Since the PURGE MS retry mechanism had been removed, this feature
is not used anymore. It just makes the code more complex.
Conflicts:
openbsc/include/openbsc/gprs_sgsn.h
openbsc/src/gprs/gprs_subscriber.c
openbsc/tests/sgsn/sgsn_test.c
Currently the APN IE in the Activate PDP Contex Request and the PDP
data that is stored with the subscriber is ignored completely.
This commit adds the sgsn_mm_ctx_find_ggsn_ctx that checks the APN IE
against the subscriber's PDP data entries if both are present. If
there is no match, the request is rejected.
If an APN IE has not been included but PDP data entries are present,
the function checks all of these entries against the static 'apn'
configuration to find a suitable entry.
If an APN has not been determined so far and any APN is allowed, the
configuration is checked with an empty APN string, to allow for
default configurations based on the IMSI prefix only.
If nothing of this succeeded but the request wasn't rejected either,
and there is no 'apn' configuration at all or if any APN is allowed
but a default configuration ist not present, the GGSN with id 0 is
used (if present).
Otherwise the request is rejected ('missing APN').
Ticket: OW#1334
Sponsored-by: On-Waves ehf
This commit adds the exported functions apn_ctx_find_alloc,
apn_ctx_free, apn_ctx_by_name, and apn_ctx_match to manage and
retrieve APN to GGSN mappings.
The following VTY commands are added to 'config-sgsn':
- apn APN ggsn <0-255>
- apn APN imsi-prefix PREFIX ggsn <0-255>
which maps an APN gateway string to an SGSN id. The SGSN must be
configured in advance. When matching an APN string, entries with a
leading '*' are used for suffix matching, otherwise an exact match is
done. When a prefix is given, it is matched against the IMSI. If
several entries match, a longer matching IMSI prefix has precedence.
If there are several matching entries with the same PREFIX, the entry
with longest matching APN is returned.
Ticket: OW#1334
Sponsored-by: On-Waves ehf
Currently the PDP info that is transmitted via GSUP is just parsed
and then discarded.
This commit adds a new data structure sgsn_subscriber_pdp_data and
maintains a list of those in sgsn_subscriber_data. The PDP data is
copied from an incoming GSUP UpdateLocationResult message. If that
message contains the PDPInfoComplete flag, the list is cleared before
new entries are added. The 'show subscriber cache' output now also
shows the PDP data entries.
Note that the InsertSubscriberData message is still not supported.
[hfreyther: Added talloc_free in gprs_subscr_pdp_data_clear]
Sponsored-by: On-Waves ehf
Create a control command to read and modify the gprs mode. Use
the get_string_value to indicate if the value was found or not.
This is useful for the ctrl interface where I didn't want to
replicate "none", "gprs" and "egprs". Share code to verify that
a BTS supports the mode.
Related: SYS#591
30f1f37638 introduced new channel
combinations but had a copy and paste error in the description.
The jenkins system didn't run the external tests so this issue
and others were not noticed until now.
Fix the copy and paste and update the test result.
This commit adds a check after a GSUP message has been decoded
whether it is an error message and does not contain a cause value.
If his is the case, the cause value is set to 'Network failure', so
that this cause if effectively the default value for error messages.
Sponsored-by: On-Waves ehf
Currently gprs_subscr_rx_gsup_message returns immediately after it
detects that an IMSI has not been given in the received GSUP message.
While this is ok for responses (result or error), a request should
always be answered.
This commit adds code to reply with a corresponding error message
("Invalid mandatory information") when it receives a request without
an IMSI.
Note that the generated error message will not contain an IMSI either.
Sponsored-by: On-Waves ehf
The cancellation type that is part of the UpdateCancellation message
is currently ignored.
This patch adds the missing glue between the existing GSUP and GMM
support. If the type is not present or has the value updateProcedure
the subcriber and MM context are siliently removed. Otherwise, a
message with cause 'implicitly detached' is sent to the MS. Since the
real cause is not known (the specification neither added a cause IE
nor defined a static cause value), the MS may get the real cause in
the following AttachRej.
Added VTY commands:
- update-subscriber imsi IMSI cancel update-procedure
- update-subscriber imsi IMSI cancel subscription-withdraw
the old form without the cause is no longer supported.
Sponsored-by: On-Waves ehf
Currently the subscr entry is no longer present, when PURGE MS
ERROR/RESULT arrives. In this case, an unspecific notice is logged
('unknown IMSI'). This clutters up the logfile with notices even in
perfectly normal operation.
This commit changes the code path that is used when a subscr cannot
be found for an incoming GSUP message. A check for PURGE MS RESULT
and ERROR is added and gprs_subscr_handle_gsup_purge_no_subscr is
called for these messages instead of gprs_subscr_handle_unknown_imsi.
Sponsored-by: On-Waves ehf
Currently the keep_in_ram flag is explicitely reset in
gprs_subscr_cleanup to cover the case, that the VTY 'create'
sub-command has been used to create the subscriber entry.
This commit completely removes keep_in_ram handling from
gprs_subscriber.c and adds a VTY 'destroy' sub-command to reset the
flag and remove the entry. So 'create' and 'destroy' can be used to
manager sticky entries that are kept even when a location
cancellation is done.
Added VTY command:
- update-subscriber imsi IMSI destroy
Sponsored-by: On-Waves ehf
Currently the MM context cleanup code is distributed over several
functions. sgsn_mm_ctx_free not only frees data structure but also
eventually stops the timer and does the subscriber clean-up.
mm_ctx_cleanup_free (gprs_gmm.c) cleans up the PDP contexts and
unassign the TLLI.
This commit moves the cleanup code from both functions into a new
unifying function sgsn_mm_ctx_cleanup_free that cares about the
clean-up of all related sub-systems.
Sponsored-by: On-Waves ehf
Currently, sgsn_update_subscriber_data can be called with mmctx ==
NULL and will find and associate the right context (if present) based
on the subscriber's IMSI. This will not happen in regular use
any more, since sgsn_update_subscriber_data will only be called when
subscribers are used (auth mode 'remote') and in this case
gprs_subscr_get_or_create_by_mmctx will already be called by
sgsn_auth_request. Therefore, MM context and subscriber are always
associated except for some test cases and experimental VTY usage.
The current implementation of sgsn_update_subscriber_data also causes
additional complexity for the deletion on MM contexts to avoid a
ipossible double-free MM contexts.
This commit removes the MM context <-> subscriber association code
from sgsn_update_subscriber_data. That function must always be called
with mmctx != NULL, now. To avoid problems with VTY and test usage,
the calling subscriber function now only call
sgsn_update_subscriber_data when mmctx != NULL, since the purpose of
that function is to update that state of an existing MM context after
subscriber data has been changed.
Sponsored-by: On-Waves ehf
The definition of subscr_put in gb_proxy_main.c will break linking if
symbols from libcommon are used. Since subscr_put is in libcommon,
there is no need for this dummy definition anymore.
This patch removes the dummy definition.
Adresses:
../../src/libcommon/libcommon.a(gsm_subscriber_base.o): In function `subscr_put':
/home/jerlbeck/git/build/openbsc/openbsc/src/libcommon/gsm_subscriber_base.c:90: multiple definition of `subscr_put'
gb_proxy_main.o:/home/jerlbeck/git/build/openbsc/openbsc/src/gprs/gb_proxy_main.c:56: first defined here
Sponsored-by: On-Waves ehf
Currently the sgsn_mm_ctx_free contains code to reset the mm->subscr
field that is also present in gprs_subscr_cleanup, which is called
directly afterwards.
This commit modifies the code path, so that the cleanup is done by
the gprs_subscr_cleanup function. The additional reference counter
increment is needed, since mm->subscr->mm->subscr (which is the same
like mm->subscr) will be reset (and unref'd) within
gprs_subscr_cleanup. Because the local variable subscr in
sgsn_mm_ctx_free is an additional pointer to the subscriber object,
it is consequent to adjust the reference counter when the assignment
is done.
Sponsored-by: On-Waves ehf
The old name is somewhat misleading. The function is rather preparing
the subscriber for a subsequent subscr_free, that is possibly invoked
by a subscr_put. It detaches the subscriber from the MM context and
optionally invokes a PURGE_MS procedure. Therefore the _cleanup
suffix is chosen (see mm_ctx_cleanup_free).
Sponsored-by: On-Waves ehf
Currently, the return value of gsup_client_connect is checked whether
it is < 0 and != -EINPROGESS. Since gsup_client_connect will only
return a negative value on a few permanent errors (not including
EINPROGRESS), rc is always != EINPROGRESS.
This patch removes the explicit check againt -EINPROGRESS and just
leaves the check rc < 0.
Sponsored-by: On-Waves ehf
Currently the size argument of strncpy is set to sizeof(mm->imsi) in
some places. If the source IMSI string is too long, the terminating
NUL byte in the static mm->imsi field gets overwritten.
This patch limits the size to sizeof(mm->imsi)-1, so that the last
byte of the buffer (that has been initialized to 0) is not
overwritten.
Fixes: Coverity CID 12065751, 12065754, 1206575
Sponsored-by: On-Waves ehf
Currently gprs_subscr_delete implicitely calls subscr_put, which
makes the code more complex than necessary (additional subscr_get) in
a few places. It also makes it more difficult to see, whether get/put
are balanced within a function. In addition, the functions are not
named consistently (gprs_subscr_delete vs.
gprs_subscr_put_and_cancel).
This commit changes the semantics of gprs_subscr_delete and
indirectly of gprs_subscr_put_and_cancel to not call subscr_put on
their argument, but to leave that for the caller to do it
explicitely.
It renames gprs_subscr_put_and_cancel to gprs_subscr_cancel to
reflect that change in the name, too.
Sponsored-by: On-Waves ehf
The subscriber cache would help in case:
* GPRS DETACH, GPRS ATTACH. In that case we might still
have some cached authentication tuples we avoid another
sendAuthenticationInfo request.
* After a detach the cache expiry would make sure to
eventually send a purgeMS to the HLR (which might be
ignored).
At the same time to make the cache work we will need to
make sure to start and stop timers. In case we don't
start we might accumulate subscribers. I am afraid that
the above two benefits do not outweight the complexity
of this implementation.
Currently old LLMEs and MM contexts that haven't been explicitly
detached or cancelled are not removed until another request with the
same IMSI is made. These stale entries may accumulate over time and
severely compromise the operation of the SGSN.
This patch implements age based LLME expiry, when the maximum age has
been reached, the corresponding MM context is cancelled. If such an MM
context doesn't exist, the LLME is unassigned directly.
The implementation works as follows.
- llme->age_timestamp is reset on each received PTP LLC message
- sgsn_llme_check_cb is invoked periodically (each 30s)
- sgsn_llme_check_cb sets the age_timestamp to the current time if
it has been reset
- sgsn_llme_check_cb computes the age and expires the LLME if
it exceeds gprs_max_time_to_idle()
Ticket: OW#1364
Sponsored-by: On-Waves ehf
[hfreyther: Fix typo in comment LMME -> LLME]
Currently the T3312 timer is directly set as encoded value when
generating the Attach/RAU Accept messages.
This patch adds GSM0408_T3312_SECS and uses it to set the
information element's value.
Sponsored-by: On-Waves ehf
Currently this optional IE is omitted, so that the optional
'Requested READY timer value' of the corresponding Request message
is used by the MS (or the default value if this IE is not used).
This patch extends gsm48_tx_gmm_att_ack and gsm48_tx_gmm_ra_upd_ack
to always include the IE set to the default value of T3312 (44s,
see GSM 04.08, table 11.4a).
Ticket: OW#1364
Sponsored-by: On-Waves ehf
Currently, all GPRS timer values are hard-coded. To make these values
configurable in seconds and to show them, conversion functions from
and to seconds are needed.
This patch adds gprs_tmr_to_secs and gprs_secs_to_tmr_floor. Due to
the limited number of bits used to encode GPRS timer values, only a
few durations can be represented. gprs_secs_to_tmr_floor therefore
always returns the timer value that represents either the exact
number (if an exact representation exists) or the next lower number
for that an exact representation exists.
Sponsored-by: On-Waves ehf
Currently the gsup_client_connect return 0 if the call to
ipa_client_conn_open was successful and -errno otherwise. This makes
it difficult for the caller to determine, whether the the whole
operation has been cancelled (currently on EBADF, ENOTSOCK,
EAFNOSUPPORT, EINVAL) or whether the GSUP client will retry to
connect after a timeout. This will cause gprs_gsup_client_create to
destroy the GSUP client object, even if the error might be temporary.
This patch changes the function to return 0 if (and only if)
ipa_client_conn_open was successful or the retry timer has been
started. Since the return value 0 doesn't guarantee, that a
subsequent call to gprs_gsup_client_send will succeed, this shouldn't
break anything.
Sponsored-by: On-Waves ehf
The per BSC code didn't guard against the init already having
been executed. This lead to:
Adding a osmo_fd that is already in the list.
<000b> bsc_nat_vty.c:1200 Setting up OSMUX socket
So a new socket got created and the old one leaked. Luckily
Linux appears to allow to bind multiple times so we were able
to just read from the new one. Use the same guard that is used
on the MGCP MGW. Re-order the log message to say "Setting up"
before we actually do that. I manually verified that osmux_init
is called at most once.
The log message was spotted by Roch
This patch drops the following commands:
- update-subscriber imsi IMSI insert authorized <0-1>
- update-subscriber imsi IMSI commit
since they are already covered by the 'update-location-result'
sub-command, except that this command doesn't create an new entry if
none is found with the given IMSI.
It adds the following command:
- update-subscriber imsi IMSI create
which can be used to create a new entry.
Sponsored-by: On-Waves ehf
Currently '\n' is used to end lines in the VTY output string
constants instead of inserting VTY_NEWLINE. This leads to incorrect
line starts in error messages.
This patch fixes that accordingly.
Sponsored-by: On-Waves ehf
Currently an error_cause of 0 is being used to indicate normal
operation. Albeit this is not a defined GMM cause, the value is not
explicitly reserved.
This commit adds the macro SGSN_ERROR_CAUSE_NONE and uses it for
initialisation (instead of relying on talloc_zero) and comparisons.
The value is set to -1 to be on the safe side. The VTY code is
updated to set the error_cause when using the
'update-subscriber imsi IMSI update-location-result CAUSE' command.
Sponsored-by: On-Waves ehf
Currently the access to subscr->sgsn_data->error_cause is not
protected against subscr == NULL like it is done in other code paths
of sgsn_auth_update.
This commit adds a conditional to avoid a NULL-dereference.
Fixes: Coverity CID 1264589
Sponsored-by: On-Waves ehf
Currently sgsn_alloc_ptmsi uses rand() to get a new P-TMSI and then
sets to upper 2 MSB. Therefore there is no lower limit of the
distance between 2 identical P-TMSI.
This patch changes the implementation to discard any random value
above 2^30 and to generate a new random number in that case until a
fitting number is found (or a repetition limit is reached). This way,
all number below 2^30 within the PRNG's period are used.
Ticket: OW#1362
Sponsored-by: On-Waves ehf
Currently no GSUP LocationCancellationResult message is sent back to
the peer (HLR), if the procedure succeeded at the SGSN's side.
This patch adds the missing message and put the whole request
handling of this procedure into a separate function.
Ticket: OW#1338
Sponsored-by: On-Waves ehf
Currently gprs_subscr_rx_gsup_message creates a subscriber entry if
such an entry doesn't exist for the IMSI within an
InsertSubscriberData GSUP message. This behaviour is not compliant to
GSM 09.02, 20.3.3.2 (Subscriber data management/SGSN) where it is
defined, that an error ("Unidentified subscriber") shall be returned.
This patch removes the case distinction, so that an existing
subscriber entry is required for all incoming GSUP messages.
Sponsored-by: On-Waves ehf
Currently, an incoming GSUP request message isn't answered at all if
it is not handled due to an error or missing implementation.
This patch adds GSUP error replies for these requests (and only for
requests). It also adds tests for these cases.
Note that several of these tests check for
GMM_CAUSE_MSGT_NOTEXIST_NOTIMPL, which will have to be changed, when
the features are implemented.
Sponsored-by: On-Waves ehf
GSM 09.02, 19.4.1.4 mandates that no other MAP procedures shall be
started until the PURGE_MS procedure has been completed.
This patch implements this by adding corresponding state and checks
to gprs_subscr_purge, gprs_subscr_location_update, and
gprs_subscr_update_auth_info. If an Update Location or a Send Auth
Info Req procedure is not started because of blocking, the retry
mechanism is aborted to shorten the blocking time. The outstanding
Purge MS procedure itself is not aborted.
Sponsored-by: On-Waves ehf
Currently, when the PURGE_MS_REQ to the HLR gets lost (e.g. by a
connection or peer failure), the expired subscriber entry will not get
deleted.
This commit adds a retry mechanism then restarts the procedure after
a timeout (currently 10s). The maximum number of retries is limited
(currently to 3 PURGE_MS messages). If none of these procedures is
completed (either with success or error), the subscriber data is
deleted.
Sponsored-by: On-Waves ehf
When a subscriber entry is going to be deleted by SGSN and when the
subscriber info has been obtained from a remote peer via GSUP, the
peer should be informed before the entry is really deleted. For this
purpose, MAP defines the PURGE MS procedure (see GSM 09.02, 19.1.4).
This patch adds support for the PURGE_MS_REQ/_ERR/_RES messages and
invokes the procedure when the subscriber entry is going to be
removed. This only applies if GSUP is being used, the Update
Location procedure has been completed successfully, and the
subscriber has not been cancelled. The removal of the entry is
delayed until a PURGE_MS_RES or PURGE_MS_ERR message is received.
Note that GSM 09.02, 19.1.4.4 implies that the subscriber data is not
to be removed when the procedure fails which is not the way the
feature has been implemented.
Note that handling 'P-TMSI freezing' is not implemented.
Ticket: OW#1338
Sponsored-by: On-Waves ehf
This commit implements the encoding and decoding of the messages
- Purge MS Request
- Purge MS Error
- Purge MS Result
and adds corresponding tests.
Sponsored-by: On-Waves ehf
Set the expiry delay after the subscriber has been deleted (e.g. by
freeing the MM context). If cancelled, the subscriber will be deleted
immediately and no timeout will be set. If the expiry time is set to
SGSN_TIMEOUT_NEVER, no timer will be started and the subscriber entry
will be kept until it is cancelled.
The following VTY command is added to the sgsn node:
- subscriber-expiry-time <0-999999> set expiry time in seconds
- no subscriber-expiry-time set to SGSN_TIMEOUT_NEVER
The default is an expiry time of 0 seconds, which means that the
subscriber entries are wiped out immediately after an MM context is
destroyed.
Note that unused MM contexts are not expired yet. Therefore the
subscriber will only be expired after a successful MM detach.
Sponsored-by: On-Waves ehf
Currently the error causes MSC_TEMP_NOTREACH, NET_FAIL, and
CONGESTION are silently dropped to force the MS to continue. On the
other hand, GSM 04.08/24.008, 4.7.3.1.4 in combination with 4.7.3.1.5,
require the MS to retry the attachment procedure for cause codes
above 15 instead of disabling GPRS. All of the mentioned GMM causes
have codes above 15, so using a REJECT message including the cause
code is a better choice. This way, the retry algorithm based on T3311
(15s, 5 times) and T3302 (default 12min) could be used.
This patch modifies gprs_subscr_handle_gsup_auth_err and
gprs_subscr_handle_gsup_upd_loc_err to proceed like when the access
has beed denied, except that the corresponding subscriber's
information fields are not cleared.
This has been successfully tested which an iphone which enters a
retry loop as it is being described in the specification.
Sponsored-by: On-Waves ehf
To unify the layout of the logging messages in gprs_subscriber.c,
this patch replaces each LOGP by LOGGSUBSCRP, unless a non-NULL
pointer to a subscr is not available. In those cases, it uses
LOGMMCTXP if a pointer to an MM context is available or LOGP
otherwise.
Sponsored-by: On-Waves ehf
Currently the GSUP message handling function in gprs_subscriber.c and
the functions in gprs_gsup_messages.c are not consistent with respect
to the return codes if an error happens. Albeit all error return
codes are negative, the semantics of the absolute value are not
clearly defined. In addition, some return codes are not passed to the
calling function.
This path changes these functions to always return a negated GMM
cause value in case of errors. Return values of called parser
functions are not longer ignored.
Sponsored-by: On-Waves ehf
Currently always a cause with the meaning of 'access denied' is
assumed. gprs_subscr_handle_gsup_auth_err just clears the auth
triplets and the authorized flag before calling the update function.
gprs_subscr_handle_gsup_upd_loc_err only clears the authorized flag
and calls the update function. This means, that an MS will not retry
to attach even on temporary network errors.
This patch changes these functions to use the GSUP error cause value
to decide, whether to clear the corresponding subscriber fields, to
just continue with the corresponding update function, or to log,
ignore and not pass the cause to the MS in case the error is directly
related to the GSUP protocol. The subscriber's error_cause field is
updated, if the update function is going to be called. The
error_cause fielt is reset on non-error GSUP messages.
Sponsored-by: On-Waves ehf
This patch extends gsm0408_gprs_access_denied and
gsm0408_gprs_access_cancelled to accept GMM cause codes. These are
then passed to the MS, unless gsm0408_gprs_access_cancelled is called
with cause 0 (no error -> updateProcedure).
Since gsm0408_gprs_access_denied uses GMM_CAUSE_GPRS_NOTALLOWED if
the cause is not set, and the subscriber's error_cause is never set
(and thus always 0), the SGSN's behaviour does not change with this
patch.
Sponsored-by: On-Waves ehf
Conflicts:
openbsc/include/openbsc/gprs_sgsn.h
[hfreyther: Conflict due the removal of the unused
authenticate flag]
Currently the mapping between GSM 04.08 (GPRS) protocol specific
numbers and their textual description was put into gprs_gmm.c and not
exported.
This commit moves the mappings to a new file gsm_04_08_gprs.c,
renames some of them, and exports them via gsm_04_08_gprs.h.
The following identifiers are renamed to match the corresponding type
names:
- gmm_cause_names -> gsm48_gmm_cause_names
- gsm_cause_names -> gsm48_gsm_cause_names
Sponsored-by: On-Waves ehf
This commit adds a line to the output of 'show sgsn' if the GSUP
client has been initialized:
- Remote authorization: [not] connected to HOST:PORT via GSUP
Sponsored-by: On-Waves ehf
Currently, the reconnect mechanism relies on gsup_client_updown_cb
which in turn gets called based on the OS' view of connection state.
This patch adds a timer based PING mechanism that regularly sends
PING messages and forces a reconnect if a PONG message won't be
received until the next PING message is scheduled. The current ping
interval is 20s.
Sponsored-by: On-Waves ehf
Conflicts:
openbsc/src/gprs/gprs_gsup_client.c
[hfreyther: Conflicts due the potential memleak fix by me. Removed
another TODO from the code as we stop the ping/pong timer]
Currently the IPA CCM messages are not handled by the GSUP client.
This means, that the client doesn't answer to PING and ID_GET and
logs notices when receiving PONG or ID_ACK. At least the PING
functionality (remotely originated PING) shall be supported.
This patch extends gsup_client_read_cb by a call to
ipaccess_bts_handle_ccm. Only when the return code is 0, the message
is processed further and checked for an OSMO/GSUP message. ID_GET
messages are answered by a dummy description, where only the
unit_name is set to 'SGSN'.
Sponsored-by: On-Waves ehf
The ipa_client_conn_open function does not distinguish between a
connection being already established or waiting for establishment.
In either case, the application gets informed about the connection
state via the updown_cb. The 'up' parameter is only set, if
poll/select consider the socket as writable.
This patch handles both cases equally and fully relies on the
updown_cb to adjust the gsupc obejct state.
Sponsored-by: On-Waves ehf
Currently, messages are added to the tx queue even if the connection
is down for some reason and all of these messages are eventually sent
after a re-connect. The MS has probably sent several Attach Requests
while the connection was down and will continue doing so. Therefore
these stored messages could be dropped.
This patch clears the queue before re-connecting and also extends
gprs_gsup_client_send to return immediately, when the connection is
not established instead of calling ipa_client_conn_send.
Sponsored-by: On-Waves ehf
[hfreyther: Replaced
while (!llist_empty(&gsupc->link->tx_queue))
llist_del(gsupc->link->tx_queue.next);
with new libosmo-abis API]
Currently the GSUP connection to a server is not restarted if the
connection cannot be established or is terminated during operation.
This commit adds a timer based connection mechanism, basically
consisting of a timer callback that calls gsup_client_connect. The
timer is eventually triggered (up == 0) or cleared (up != 0) by
gsup_client_updown_cb. It adds calls to osmo_timer_del() to
gsup_client_connect and gprs_gsup_client_destroy. The latter is now
called instead of talloc_free in gprs_gsup_client_create on error to
be on the safe side.
Sponsored-by: On-Waves ehf
This flag is used to determine, whether the Update Location procedure
shall be invoked. This is currently only set, when the 'remote'
authorization policy is set. When the flag is set, sgsn_auth_update
will not never be called directly by sgsn_auth_request, if an Attach
Request procedure is pending, even if the remote connection fails for
some reason.
Sponsored-by: On-Waves ehf
Currently the flag 'authenticate' is managed per subscriber.
This patch replaces that flag by a global cfg.require_authentication
flag that enables/disables the use of the Auth & Ciph procedure for
every subscriber. The flag is set by the VTY, if and only if the
authorization policy is 'remote'.
The VTY command
- update-subscriber imsi IMSI insert authenticate <0-1>
is removed.
Sponsored-by: On-Waves ehf
This commit adds GSUP client configuration (via VTY), connection set
up, and real message sending.
The following configuration commands are added:
- gsup remote-ip A.B.C.D set server IP address
- gsup remote-port PORT set server TCP port
Ticket: OW#1338
Sponsored-by: On-Waves ehf
This commit adds the client code to get subscriber information from a
remote server. It provides an IPA over TCP connection to transmit and
receive GSUP messages.
Sponsored-by: On-Waves ehf
Holger Hans Peter Freyther
Daniel Willmann
Neels Hofmeyr
Harald Welte