./configure --help indicates:
--enable-external-tests Include the VTY/CTRL tests in make check
[default=no]
but
./configure ... --enable-external-tests
configure: WARNING: unrecognized options: --enable-external-tests
the name of the option seems to be --enable-ext-tests.
The library allows to indicate zero as batch size if you want to use
the default size, however openbsc saves 'osmux batch-size 0' which is
not good as input.
Use OSMUX_BATCH_DEFAULT_MAX to explicitly initialize the batch size
from mgcp_parse_config().
The talloc_free on the nat lead to the freeing of the bsc_config
which lead to freeing of the rate_ctr_group. The rate_ctr_group
remained in a global list and the next creation of a bsc_config
would access dead memory. Fix it.
The free routine is only meant to be used by the test, for the
real nat we would need to make sure that all connections and
other state that refers to the cfg is removed/closed first.
Fix various memleaks in the test while we are at it. There are
still some to fix.
==7195== Invalid write of size 4
==7195== at 0x4043171: rate_ctr_group_alloc (linuxlist.h:65)
==7195== by 0x804D893: bsc_config_alloc (bsc_nat_utils.c:174)
==7195== by 0x804B5D2: main (bsc_nat_test.c:954)
==7195== Address 0x4311cbc is 52 bytes inside a block of size 208 free'd
==7195== at 0x4029D28: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==7195== by 0x4048D98: _talloc_free (talloc.c:609)
==7195== by 0x4052806: talloc_free (talloc.c:578)
==7195== by 0x804B58A: main (bsc_nat_test.c:940)
bsc_nat_ctrl.c: In function ‘set_net_cfg_cmd’:
bsc_nat_ctrl.c:360:3: warning: implicit declaration of function ‘bsc_replace_string’ [-Wimplicit-function-declaration]
bsc_replace_string(bsc_cfg, &bsc_cfg->acc_lst_name, cmd->value);
^
gbproxy_patch_bssgp: Move a check for tlli_info in front of the first
conditional that depends on it, and return immediately if it is NULL.
gbproxy_register_tlli: Initialize tlli_already_known to 0.
Fixes: Coverity CID 1232691
Fixes: Coverity CID 1232692
Sponsored-by: On-Waves ehf
Remove redundant information log message:
<000b> bsc_mgcp_utils.c:647 BSC doesn't want to use Osmux, failing back to RTP
<000b> bsc_mgcp_utils.c:669 bsc didn't accept to use Osmux (cid=0)
One single log message is just fine. The error path already indicates
the precise reason not to accept the request to use Osmux.
This patch includes several osmux fixes that are interdependent:
1) This adds Osmux circuit ID, this is allocated from the bsc-nat. This
announces the circuit ID in the CRCX MGCP message. This aims to resolve
the lack of uniqueness due to the use of endp->ci, which is local to
the bsc. This ID is notified via X-Osmux: NUM where NUM is the osmux
circuit ID.
2) The dummy load routines are now used to setup osmux both in bsc and
bsc-nat to resolve source port NAT issues as suggested by Holger. The
source port that is used from the bsc is not known until the first
voice message is sent to the bsc-nat, therefore enabling osmux from
the MGCP plane breaks when a different source port is used.
3) Add refcnt to struct osmux_handle, several endpoints can be using the
same input RTP osmux handle to perform the batching. Remove it from the
osmux handle list once nobody is using it anymore to clean it up.
4) Add a simple Osmux state-machine with three states. The initial state
is disabled, then if the bsc-nat requests Osmux, both sides enters
activating. The final enabled state is reached once the bsc-nat sees
the dummy load message that tells what source port is used by the bsc.
5) The osmux input handle (which transforms RTP messages to one Osmux batch)
is now permanently attached to the endpoint when Osmux is set up from the
dummy load path, so we skip a lookup for each message. This simplifies
osmux_xfrm_to_osmux().
After this patch, the workflow to setup Osmux is the following:
bsc bsc-nat
| |
|<------ CRCX ----------|
| X-Osmux: 3 | (where 3 is the Osmux circuit ID
| | that the bsc-nat has allocated)
|------- resp --------->|
| X-Osmux: 3 | (the bsc confirm that it can
| | use Osmux).
. .
| |
setup osmux |----- dummy load ----->| setup osmux
| Osmux CID: 3 |
In two steps:
1st) Allocate the Osmux Circuit ID (CID): The bsc-nat allocates an unique
Osmux CID that is notified to the bsc through the 'X-Osmux:' extension.
The bsc-nat annotates this circuit ID in the endpoint object. The bsc
replies back with the 'X-Osmux:' to confirm that it agrees to use Osmux.
If the bsc doesn't want to use Osmux, it doesn't include the extension
so the bsc-nat knows that it has to use to RTP.
2nd) The dummy load is used to convey the Osmux CID. This needs to happen
at this stage since the bsc-nat needs to know what source port the bsc
uses to get this working since the bsc may use a different source
port due to NAT. Unfortunately, this can't be done from the MGCP signal
plane since the real source port is not known that the bsc uses is not
known.
This patch also reverts the MDCX handling until it is clear that we need
this special handling for this case.
In the bsc-nat side, the osmux socket initialization can be done from
the vty. This ensure that the osmux socket is available by the time the
bsc-nt receives the dummy load that confirms that the osmux flow has
been set up.
This change is required by the follow up patch. This change ensures that
the Osmux socket in the bsc-nat is already in place by the time this
receives the dummy load.
Back in March 2013, some structures and defines related to decoded
measurement reports have been moved from openbsc to libosmocore
(libosmocore e128f4663104ed64e33e362cff2566f36d65e658) so that they can
be used also from osmo-bts. This finally makes gsm_lchan follow suit
for osmo-bts.
The gb_proxy shouldn't start to open the box of pandora by including the
gsm_data_shared.h file, particularly not without defining the BSC role.
In any case, as the reserved TMSI is something that's part of the GSM
specs, and not specific to the OpenBSC implementation, it should be part
of libosmocore.
All review feedback will be addressed _after_ the split of the
files. This is the only reasonable approach to get the split of
files merged. I didn't have the time to review all of the code
before the point of splitting.
This patch moves the peer related definitions from gb_proxy.c to
gb_proxy_peer.c and adjusts the prefix of each global symbol to
gbproxy_:
Peer definitions (prefix adjusted to gbproxy_):
peer_ctr_description -> gprs/gb_proxy_peer.c (static)
peer_ctrg_desc -> gprs/gb_proxy_peer.c (static)
*peer_by_* -> gprs/gb_proxy_peer.c
gbproxy_peer_alloc -> gprs/gb_proxy_peer.c
gbproxy_peer_free -> gprs/gb_proxy_peer.c
gbprox_cleanup_peers -> gprs/gb_proxy_peer.c
Sponsored-by: On-Waves ehf
This patch moves several functions and declarations out of gb_proxy.c
to make them reusable by other components and to separate them by
context and task.
Counter enums (prefix is changed to gbproxy_):
enum gbprox_global_ctr -> gprs/gb_proxy.h
enum gbprox_peer_ctr -> gprs/gb_proxy.h
Generic Gb parsing (prefix is changed to gprs_gb_):
struct gbproxy_parse_context -> openbsc/gprs_gb_parse.h
gbprox_parse_dtap() -> gprs/gprs_gb_parse.c
gbprox_parse_llc() -> gprs/gprs_gb_parse.c
gbprox_parse_bssgp() -> gprs/gprs_gb_parse.c
gbprox_log_parse_context() -> gprs/gprs_gb_parse.c
*_shift(), *_match() -> gprs/gprs_gb_parse.c (no prefix)
gbprox_parse_gmm_* -> gprs/gprs_gb_parse.c (static)
gbprox_parse_gsm_* -> gprs/gprs_gb_parse.c (static)
MI testing/parsing (prefix gprs_ added):
is_mi_tmsi() -> gprs/gprs_utils.c
is_mi_imsi() -> gprs/gprs_utils.c
parse_mi_tmsi() -> gprs/gprs_utils.c
TLLI state handling (prefix is changed to gbproxy_):
gbprox_*tlli* -> gprs/gb_proxy_tlli.c
(except gbprox_patch_tlli, gbproxy_make_sgsn_tlli)
Message patching (prefix is changed to gbproxy_):
gbprox_*patch* -> gprs/gb_proxy_patch.c
gbprox_check_imsi -> gprs/gb_proxy_patch.c
Sponsored-by: On-Waves ehf
Add LLC test messages containing XID (SAPI LLGMM, U frame) and IP traffic
(SAPI LL11, UI frame).
Add a test case containing a complete SGSN session with TLLI/PTMSI
patching enabled.
Sponsored-by: On-Waves ehf
This patch modifies gbprox_make_bss_ptmsi() to generate a new P-TMSI
when patch_ptmsi is set in the configuration instead of using the
P-TMSI assigned by the SGSN. It modifies gbprox_make_sgsn_tlli() to
either use a foreign TLLI based on the SGSN side P-TMSI or (if there
is none) generate a random TLLI if patch_ptmsi is set. Otherwise, the
TLLI used by the BSS is used.
The seeds for the pseudo-random sequences sre set based on time
initially. Note that these are neither cryptographically safe nor
protected against collisions.
Ticket: OW#1259
Sponsored-by: On-Waves ehf
This patch contains fixes for the TLLI tracking and handling.
It adds and uses gbprox_map_tlli() the map the source TLLI to the
destination TLLI while respecting whether it is current or assigned.
It removes gbprox_register_tlli() from the downlink path. It fixes
TLLI validation and disables the use of the BSSGP TLLI IE.
Sponsored-by: On-Waves ehf
Currently, these messages lead to a parsing error which prevents them
from being processed any further.
This patch sets the return value of gbprox_parse_llc to 1 in these
cases and fixes a segfault which is triggered by any non-04.08
message.
Sponsored-by: On-Waves ehf
Currently gbprox_patch_raid() updates the local MCC/MNC with every
BSS originated message, even if the RAI is an 'old' one.
This patch separates state updating and patching into 2 functions
gbprox_update_current_raid and gbprox_patch_raid. In addition, a
field named old_raid_enc is added to gbproxy_parse_context, which is
used for 'old RAI' IEs in Attach Requests and RA Update Requests.
Only the bssg_raid_enc in BSS originated message is used to update
the BSS side 'local' MCC/MNC.
Sponsored-by: On-Waves ehf
This patch splits the functionality of gbprox_get_detached_tlli_info
into 2 new functions:
- gbprox_tlli_info_alloc to allocate an intialized and detached
tlli_info
- gbprox_detach_tlli_info to detach an already attached tlli_info
Sponsored-by: On-Waves ehf
This VTY command add the following commands to the gbproxy node:
- patch-ptmsi: Enables P-TMSI/TLLI patching
- no patch-ptmsi: Disables P-TMSI/TLLI patching
Note that using these commands interactively can load to undefined
behavior of existing LLC connections.
Sponsored-by: On-Waves ehf
This patch separates BSS side from SGSN side TLLI/PTMSI tracking. When
TLLI/PTMSI patching is not enabled, the corresponding states shall be
identical. The TLLI/PTMSI state has been moved into the struct
gbproxy_tlli_state and is used twice in gbproxy_tlli_info.
Since the state handling for uplink and downlink messages is
diverging, gbprox_update_state() is replaced by two functions
gbprox_update_state_dl/gbprox_update_state_ul and
gbprox_process_bssgp_message() is replaced by
gbprox_process_bssgp_dl/gbprox_process_bssgp_ul.
Sponsored-by: On-Waves ehf
This patch adds the functions send_bssgp_ul_unitdata(),
send_bssgp_dl_unitdata(), send_llc_ul_ui(), and send_llc_dl_ui().
They are used instead of send_ns_unitdata() in
test_gbproxy_ra_patching(). This make it easier to modify TLLI, N(U),
and other parameters.
Sponsored-by: On-Waves ehf
The following parts of the messages have been fixed
- Attach Accept: checksum
- Attach Complete: checksum
- RA Update Accept: Use the same MS Radio Access Capabilities and
DRX Parameters like the other messages
The N(U) of most messages have not been fixed.
Sponsored-by: On-Waves ehf
Don't replace the current TLLI immediately, store it in an additional
'assigned_tlli' field and discard the old TLLI when both sides have
used the new one (see GSM 04.08, 4.7.1.5).
Add an Attach Complete message to test and check, whether the related
field of the corresponding tlli_info struct are set as expected
during the local TLLI validation cycle.
Sponsored-by: On-Waves ehf
Currently the enable_patching field in tlli_info is not updated,
when an IMSI is assigned to a TLLI that is already known.
This patch fixes this in gbprox_update_state() after the call to
gbprox_update_tlli_info().
The number of APN increases and the test output file is updated
accordingly.
Sponsored-by: On-Waves ehf