| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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.
|
|
In case no static ggsn is configured the code would crash
with the assumption that there is always such a GGSN.
|
|
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
|
|
Implement it similar to the msisdn_enc/msisdn_enc_len and
extend the testcase to include it as well.
|
|
The HLR-Number can be passed from the MAP Proxy to the SGSN and
can then be used for the CDR module or passed during the purgeMS
operation.
|
|
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.
|
|
Bits 3 to 8 are spare bits and should be set to 1 in etsi
specifications. Do that.
|
|
Signed-off-by: Max <max.suraev@fairwaves.co>
|
|
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.
|
|
All calls should and do go through the
sgsn_mm_ctx_cleanup_free function.
|
|
|
|
|
|
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.
|
|
Add roundtrip test for the new QoS IE. It will be consumed in
later commits.
|
|
Extract the new MSISDN IE from the GSUP message and verify that
it is read/written to the message.
|
|
QoS is a mess. In MAP there is qos-Subscribed which is then extended
using ext-QoS-Subscribed, ext2-QoS-Subscribed, ext3-QoS-Subscribed
and maybe even ext4-QoS-Subscribed by now. The MAP ASN1 files defined
how these need to be "linearized". Instead of copying this I have
decided to include the two semantics with/without the Allocation/Retention
policy using the size of the data.
|
|
When asking the GGSN to create/open a PDP context one needs
to send a MSISDN. The MSISDN can only be provided through the
GSUP interface.
|
|
In case we filter the request and it was a Location Updating
Procedure we should reject it.
|
|
|
|
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.
|
|
|
|
|
|
Remove the last occurence of NAT datastructures in the filtering
module and add the ctx to the filter request structure.
|
|
|
|
|
|
With the "local" and "global" list name we might pick the
wrong argument. Avoid it by passing them as a struct.
|
|
Push back the parameters we need to pass. auth_imsi doesn't
know anything about the nat now.
|
|
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.
|
