This is the first step in creating this repository from the legacy openbsc.git.
Like all other Osmocom repositories, keep the autoconf and automake files in
the repository root. openbsc.git has been the sole exception, which ends now.
Add vty tests for BSC configuration reloading.
Load BSCs configuration on bscs-config-file command:
* remove all runtime configured BSC not in the config file
* close connections to all BSC with updated token value
Sponsored-by: On-Waves ehf
Introduce new configuration option bscs-config-file which includes BSC
configuration from the given file. Both absolute and relative (to the
main config file) paths are supported.
Add 'show bscs-config' command to display current BSC configuration.
Note: it is still possible to have BSC configuration in the main
file (provided proper index number is used) and in runtime but BSC
configuration is no longer saved automatically. The management of
included configuration file is left to external tools.
Update configuration examples.
Sponsored-by: On-Waves ehf
Add ctrl_vty_init() calls and feed the ctrl_vty_get_bind_addr() return value to
ctrl_interface_setup() in the following programs:
For osmo-sgsn, move the control interface setup invocation below the config
parsing, so that the ctrl_vty_get_bind_addr() can return the configured
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
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.
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
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.
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)
This patch adds the voice muxer. You can use this to batch RTP
traffic to reduce bandwidth comsuption. Basically, osmux transforms
RTP flows to a compact batch format, that is later on decompacted
to its original form. Port UDP/1984 is used for the muxer traffic
between osmo-bsc_nat and osmo-bsc_mgcp (in the BSC side). This
feature depends on libosmo-netif, which contains the osmux core
Osmux is requested on-demand via the MGCP CRCX/MDCX messages (using
the vendor-specific extension X-Osmux: on) coming from the BSC-NAT,
so you can selectively enable osmux per BSC from one the bsc-nat.cfg
file, so we have a centralized point to enable/disable osmux.
First thing you need to do is to accept requests to use Osmux,
this can be done from VTY interface of osmo-bsc_nat and
osmo-bsc_mgcp by adding the following line:
osmux batch-factor 4
This just initializes the osmux engine. You still have to specify
what BSC uses osmux from osmo-bsc_nat configuration file:
In this case, bsc 1 and 3 should use osmux if possible, bsc 2 does
not have osmux enabled.
Thus, you can selectively enable osmux depending on the BSC, and
we have a centralized point for configuration from the bsc-nat to
enable osmux on demand, as suggested by Holger.
At this moment, this patch contains heavy debug logging for each
RTP packet that can be removed later to save cycles.
The RTP ssrc/seqnum/timestamp is randomly allocated for each MDCX that
is received to configure an endpoint.
The old ipa_msg_recv() implementation didn't support partial receive,
so IPA connections got disconnected when this happened.
This patch adds the handling of the temporary message buffers and uses
It has been successfully tested by jerlbeck with osmo-nitb and
Sponsored-by: On-Waves ehf
The filtering architecture already allowed to specify a reject
reason but this has not been used for the access-lists. Extend
the access-list to include a reject reason and extend the test
case to honor it.
So far the payload type used in RTP streams has been taken from the
trunk configuration in NAT mode.
This patch changes the implementation to use the payload type
announced in the SDP part of MGCP messages and responses. SDP
descriptions more than one m=audio line are not yet supported
properly (always the last one is taken).
Sponsored-by: On-Waves ehf
* The post-routing is applied after the first re-writing. To do this
the new number is copied back into the called data structure.
* Add a testcase that goes from 0172 to 0049 and then back to 0049
using the post rule with a table lookup.
* Increase the rewritten rule to five digits (this is the easiest
for the unit test). This will add another 40kb to the runtime size.
* Create a unit test that tests adding and removing the prefix rules.
* Use the regexp match to replace from one package
The name sccp_connection is used in the osmo-sccp code, sccp_connections
was used in the NAT for tracking a sccp_connection. Rename it so it is
obvious that the struct belongs to the nat.
The rename was done with sed:
$ sed -i s,"struct sccp_connections","struct nat_sccp_connection",g \
include/openbsc/*.h src/osmo-bsc_nat/* tests/*/*
We want to send a TRAP with the MGCP statistics from the NAT and
the connected BSC. The BSC endpoint can be either released because
of a DLCX from the MGCP CallAgent or the SCCP Connection release on
This is why we need to queue the statistics when the deleting the
endpoint on the BSC. The processing is continued once the response
arrives. This code assumes that the response of the DLCX will be sent
by the remote side. The current amount of outstanding responses can be
seen on the VTY. This assumption is based on the fact that the BSC has
already responded to the CRCX and maybe to the MDCX.
The MGCP RFC is bended to prefix the transaction identifier with "nat-"
to easily detect the response and hand it to the handler. This will
then parse the response and generate the TRAP. The current version is
v1. We assume that the transaction space is big enough and we will
not re-assign the transaction identifier too early.
nat: Catch up with controlif_setup API change
We now save a control handle reference in the nat
osmo-bsc: Catch up with controlif_setup API change
We now save a control handle reference in the gsm network
Introduce number rewriting of SMS-SUBMIT. Introduce a new list,
move code around to help with finding a new number, somehow the
number encoding for TP-DA is borked, 03.40 references 04.11 but
the length appears to be strlen(number) without taken the type
field into account.
Match IMSI and destination address against a set of entries, if it
is matching the header will be modified and no sender report will be
requested. Change the test case to request the sender report and then
verify that this bit is reset to 0.
The idea that MCC and MNC is enough to classify a subscriber
turns out to be wrong. Certain operatos license a number range
of IMSIs to others. When we see a '^' in the MCC field we treat
it as a regexp. The code now turns the MCC/MNC into a regexp
for the IMSI. It is not using extended POSIX regexp to match
the behavior of the access list.