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
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.
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
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
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
Holger Hans Peter Freyther