This commit adds the following counters:
- attach-reqs: Number of Attach Request messages
- attach-rejs: Number of Attach Reject messages
- tlli-cache: Size of the TLLI cache
Sponsored-by: On-Waves ehf
These commands manage the TLLI list used to decide whether an APN
shall be patched or not. Note that this list is (currently) only
maintained if IMSI matching is used.
VTY commands (enable node):
show gbproxy tllis show all TLLI entries
delete-gbproxy-tlli NSEI stale purge all stale entries
delete-gbproxy-tlli NSEI imsi IMSI purge entry with the IMSI given
delete-gbproxy-tlli NSEI tlli TLLI purge entry with the TLLI given
Sponsored-by: On-Waves ehf
This patch adds IMSI/TLLI connection tracking and uses it to control
APN patching based on the IMSI. TLLI entries can expire based on age
and/or by limiting the TLLI list size.
VTY config-gbproxy:
no core-access-point-name disable APN patching
core-access-point-name none remove APN if present
core-access-point-name APN replace APN if present
core-access-point-name none match-imsi RE remove if IMSI matches
core-access-point-name APN match-imsi RE replace if IMSI matches
tlli-list max-age SECONDS expire after SECONDS
no tlli-list max-age don't expire by age
tlli-list max-length N keep N entries only
no tlli-list max-length don't limit list length
RE is an extended regular expression, e.g. ^12345|^23456
Ticket: OW#1192
Sponsored-by: On-Waves ehf
Currently, all patching state is stored globally in the gbproxy. Thus
the feature cannot be used safely with a concentrating gbproxy (NAT).
This patch moves the state and relevant counters to the gbprox_peer
structure. It adds code to resolve the corresponding peer when
packets are received by looking at BVCI, NSEI, and BSSGP IEs (BVCI,
RAI/LAI/LAC) when the peer is not passed to the
gbprox_patch_bssgp_message() function.
Test cases are also added for the SGSN->BSS case including test cases
with invalid identifiers.
Note that this patch should make it possible to use RAI patching at a
NAT gbproxy as long as the messages are not encrypted.
Ticket: OW#1185
Sponsored-by: On-Waves ehf
This patch adds a Detach Request (MO) / Detach Accept sequence to the
test, followed by another (here invalid) Act PDP Context Req which
should be APN patched.
Sponsored-by: On-Waves ehf
Add a DTAP GMM Information message with an IMSI in the BSSGP header
to enable the association between IMSI and TLLI.
The TLLI of the Routing Area Update messages is set to foreign.
Sponsored-by: On-Waves ehf
Patch the APN in every 'Activate PDP Context Request' message to the
value given by the 'core-access-point-name' command. If the command is
given without an APN, the whole APN IE will be removed. If the
command is being prefixed by a 'no', the APN IE remains unmodified.
The patch mode 'llc-gsm' is added to selectively enable the patching
of LLC session management messages. This is enabled implicitely by
the patch mode 'llc'.
Note that the patch mode should not be set to a value not enabling
the patching of LLC GSM messages ('llc-gsm', 'llc', and 'default' are
sufficient to patch 'Activate PDP Context Request' messages).
Ticket: OW#1192
Sponsored-by: On-Waves ehf
This patch extends the BSSGP patch code to also patch LLC information
elements along with MCC/MNC patching support for the following messages:
- Attach Request
- Attach Accept
- Routing Area Update Request
- Routing Area Update Accept
- P-TMSI reallocation command
Note that encrypted packets will not be patched.
Ticket: OW#1185
Sponsored-by: On-Waves ehf
This adds a feature to patch the BSSGP MNC/MCC fields of messages going
to and coming from the SGSN. To enable this feature, the gbproxy's
VTY commands 'core-mobile-country-code' and/or
'core-mobile-network-code' must be used. All packets to the SGSN are
patched to match the configured values. Packets received from the
SGSN are patched to the corresponding values as last seen from the BSS
side.
Note that this will probably not work with a gbproxy used for several
BSS simultaneously.
Note also, that MCC/MNC contained in a LLC IE will not be patched.
Ticket: OW#1185
Sponsored-by: On-Waves ehf
The wrong field has been use for the field length computation. This
hadn't any impact so far, since
sizeof(ctx->imei) == sizeof(ctx->imsi)
This patch fixes the computation to use the right field.
Sponsored-by: On-Waves ehf
This patch makes a few changes to improve readability:
- change the sendto() hexdump to start with NS instead of BSSGP
- use more specific message descriptions instead of 'UNITDATA'
- add a title line per test
Sponsored-by: On-Waves ehf
We need to discover the remote port as we are likely behind a NAT.
Right now the NAT code will just send to port 1984 on the BSC but
this might not arrive at the BSC. Include the CI (in the future we
need to include the endpoint address or send the dummy to the net
port). This is just an interim solution.
The CI is a MGCP value that is counted from 0 upwards. The code
is comparing a uint8_t with a uint32_t. This will only work for
up to UINT8_MAX calls and then will silently break. The code should
probably work with the endpoint number and not the CI. For now
truncate things and hope things work.
Jacob pointed out that "free_endp" refers to the memory of
the endpoint being freed. What we want is actually a way to
release an endpoint (and the resource it allocated) or in
the case of the testcase/testapp initialize the data structure
correctly. Introduce two names for that.
In case the sender didn't send a couple of frames we will have
a time gap that is bigger than the accepted delta. Add a new
testcase for this and update the next_time.
Transcoding from GSM to PCMA can lead to the MGCP MGW sending
two PCMA packages with the same sequence number and timestamp.
Once with the encoded audio and once completely empty.
This is because "state->dst_packet_duration" is 0 in most cases
(unless a ptime is forced) and we attempt to encode audio even
if there are not enough samples. The encode_audio return will
return 0 in that case which is not trated as an error by the
mgcp network code.
Handle rc == 0 specially and document the semantic.
The sequence number was read from the wrong place and then
the wrong byte order conversion routine was used so we ended
up wirting 0x00, 0x00 into the patched sequence number. Add
a testcase for that.
When going from a ptime of 10 to 20 a lot of alignment errors
are reported. In fact the alignment check should be done before
and after the transcoding. As this is not possible right now
only do it _after_ the patching.
It took me a long time to figure out that errx just exits and
the test output didn't indicate that the application was exited
early. Use a printf and good old abort in case of a failure.
The GSM handle was never released. This was found using valgrind
and the leak check.
==14933== 752 bytes in 1 blocks are definitely lost in loss record 15 of 19
==14933== at 0x4028B4C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==14933== by 0x4130201: gsm_create (in /usr/lib/i386-linux-gnu/libgsm.so.1.0.12)
==14933== by 0x80517AE: mgcp_transcoding_setup (mgcp_transcode.c:199)
==14933== by 0x8049691: given_configured_endpoint.isra.1 (mgcp_transcoding_test.c:198)
==14933== by 0x8049C11: test_transcode_result (mgcp_transcoding_test.c:328)
==14933== by 0x8049418: main (mgcp_transcoding_test.c:582)
<000b> osmux.c:177 Cannot find endpoint with cid=7
!
<000b> osmux.c:253 Cannot find an endpoint for circuit_id=7
The extra newline and '!' do not provide any extra value and
make reading the output more difficult. Just remove it.
An empty log_info is not enough. We need to make sure that at least
DLGLOBAL is present. Instead of doing that make sure that we have
enough entries.
==26163== Conditional jump or move depends on uninitialised value(s)
==26163== at 0x403B289: osmo_vlogp (logging.c:290)
==26163== by 0x403B3DA: logp2 (logging.c:339)
==26163== by 0x804D027: gbprox_relay2bvci (gb_proxy.c:347)
==26163== by 0x804D3CF: gbprox_rx_sig_from_sgsn (gb_proxy.c:589)
==26163== by 0x804DBFC: gbprox_rcvmsg (gb_proxy.c:685)
==26163== by 0x4052CB0: gprs_ns_process_msg (gprs_ns.c:669)
==26163== by 0x4052F70: gprs_ns_rcvmsg (gprs_ns.c:1053)
==26163== by 0x804BB49: gprs_process_message (gbproxy_test.c:488)
==26163== by 0x804BC4C: send_ns_unitdata (gbproxy_test.c:210)
==26163== by 0x804BDE8: send_bssgp_reset_ack (gbproxy_test.c:243)
==26163== by 0x804B54F: main (gbproxy_test.c:863)
==26163==
The peers are (talloc) children of the GPRS NS. This means the
peers (and the rate counters) are currently being deleted twice.
==23446== Invalid write of size 4
==23446== at 0x403C243: rate_ctr_group_alloc (linuxlist.h:66)
==23446== by 0x4050974: gprs_nsvc_create (gprs_ns.c:209)
==23446== by 0x405320D: gprs_ns_instantiate (gprs_ns.c:1330)
==23446== by 0x804ABEB: main (gbproxy_test.c:666)
==23446== Address 0x4300694 is 52 bytes inside a block of size 784 free'd
==23446== at 0x4029DA8: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==23446== by 0x4041B9D: _talloc_free (talloc.c:609)
==23446== by 0x4043292: talloc_free (talloc.c:578)
==23446== by 0x40532D3: gprs_ns_destroy (gprs_ns.c:1363)
==23446== by 0x804ABD7: main (gbproxy_test.c:660)
Make the llc_default_params structure from which data is initialized
large enough. Otherwise address sanitizer complains with out-of-bounds
reads.
Only SAPIs 1, 2, 3, 5, 7, 8, 9, 11 are defined for GPRS but the
struct gprs_llc_llme includes NUM_SAPIS lle's and they are populated
from the llc_default_params structure.
Jacob Erlbeck