In Debian 13 armv7l, time_t and suseconds_t are "long long int" instead
of "long unsigned int" as seen on x86_64 and aarch64. Fix it by casting
to "long unsigned int".
Related: OS#6828
Change-Id: I416b31dd11a82ad52f6a662d7e099123a5c77fff
According to TS23.003, CI should be unique in a LAC.
Previous commit wrongly introduced a while ago a new "bts 2" with same
LAC and CI as "bts 1" in config file.
This makes current tests fails once a hashtable is added to lookup bts
by lac, since the hashtable code does prepend new bts instead of
appending them. As a result, bts 2 is returned instead of bts 1 being
previously returned.
Also change the ARFCN+BSIC since it was also duplicated. It makes not much
sense to have 2 neighbor BTS with same ARFCN+BSIC.
Fixes: 97ed3c8d97
Change-Id: I7d1ebd529e050ecb4c14b9d3523637e4c8c87e1d
Some users actually want to deploy osmo-bsc connected to more than 256
BTSs. Allow them to do so.
This is about increasing the integer size / maximum value of the
internal "bts->nr" ID usef eg. during VTY configuration.
The ipaccess OML bts_nr is still kept as uint8_t so nothing changes over
the wire. That's because in ipaccess OML, in general each BTS is
bts_nr=0 (bts->bts_nr) under its own ipa connection.
NOTE: This patch doesn't add support to handle >256 BTS over PCUIF,
which still keeps its (struct gsm_pcu_if)->bts_nr as uint8_t.
This is not much of a problem yet though, since the requirement to run
>256BTS is needed in a network where osmo-bts is used, and hence PCUIF
is handled at each BTS.
Related: SYS#7062
Change-Id: I607a68efeb5f4a50cce107d11d3c5126b7d8f81a
The size of bts->nr is implicitly or explicitly used or taken into
account in several places in the code.
Add a new type to make it easier to define its size and range in one
place.
This also helps in identifying fields contains an BSC-implementation
"bts_nr" vs theip.access Abis OML "bts_nr" sent over the wire, which is
always a uint8_t according to spec.
Related: SYS#7062
Change-Id: Ic0db2873fa9795024aba4399da495a0d8f7504b0
There is no reason to allow the 5.90k mode alone. Allow them all
and let codec negotiation figure out the AMR rates to use.
Change-Id: I33e297a28bcaf8fd9ccddb20ce9ce092ab57d2e0
It's safer to deny emergency calls by default, and thus require
osmo-bsc users to allow them manually iff such calls can actually
be routed to their local emergency services.
This reduces the risk of a situation, when a person having a real-life
emergency would be trying, for instance, to call an ambulance via a
test network, which does allow emergency calls but cannot route them.
Change-Id: I5296b3031c14a896caa33b16bf04db762b9f30bf
A switch (bool) is used to enable or disable NSVC 0 or 1. It is enabled
via any "gprs nsvc 0|1" command and disabled via "no gprs nsvc 0|1"
command. If it is disabled, it is treated as unconfigured, similar when
no remote IP or port has been defined.
Related: OS#6006
Change-Id: Ia112e86aa35f6a245d98ef1b3720c18835faeda6
We already recover broken lchans where an ACTIV ACK or REL ACK arrives
late. Now add a recovery path for lchans that are broken because no
ACTIV ACK or REL ACK arrives at all.
Add a timeout of X28 = 30s to the lchan BORKEN state.
On timeout, attempt both a Channel Activation and a Channel Release. If
any of them is ACKed, we have successfully synced BTS and BSC's state.
After successful recovery, place the lchan back in the UNUSED state,
available for servicing subscribers.
If recovery is unsuccessful, just continue to attempt recovery every
further X28 seconds.
Patch-by: osmith, nhofmeyr
Related: osmo-ttcn3-hacks I9b4ddfc4a337808d9d5ec538c25fd390b1b2530f
Related: OS#5106
Related: SYS#6655
Change-Id: Ic4728b3efe843ea63e2a0b54b1ea8a925347484a
"enum lchan_select_reason" gets a new selection reason: "SELECT_FOR_VGCS"
The selection "direction" can also be changed via VTY.
Change-Id: I6b96d0a1df68efa5858b98297ebe0944b1473aaf
Related: OS#4852
We don't want to have duplicate EARFCNs in the config file.
The desired behavior is modifying existing EARFCNs.
Change-Id: Ia2fd8bd86d9f093967c1b0b0135151d2d5386dc1
Related: SYS#6401
* osmo-bsc currently does not support adding multile EARFCNs
with different thresh/prio/qrxlv parameter values;
* adding an EARFCN which already exists creates a duplicate;
* adding an UARFCN which already exists fails;
* adding UARFCN=0 fails.
Change-Id: Iece6b9058f4eb06f8f2c19311de4f2eea01cfe82
Related: SYS#6401
Do this by setting the minimal value for T3105 to 1 in its timer definition.
Fixes: Coverity scan CID#307389
Change-Id: I1fd0b92ab507a58fed6e9649eaa4770f1ad1cbad
Since there were complaints about this old parsing code during recent
code review in Ifdc9e04bf1d623da65bfb8a2fddea765601f6d9b, and now also
coverity finds something odd in it, just rewrite this.
Related: CID#310912
Change-Id: I96cd5d88ec6808a2915c6bccd0c0140216f328f2
In osmo-bsc, there's currently 0..1 Lb links and 0..N A links, where N
is the number of MSC, but links can be shared in the underlaying stack
(struct osmo_sccp_instance), hence range 0..N of different
osmo_sccp_instance (identified by PC).
Even more, the Lb and A link can share the same underlaying stack, so
osmo-bsc can end up with only 1 struct osmo_sccp_instance shared by all
the above mentioned links in case all are configured under the same PC.
Total range A+Lb is 0..(1+N).
A struct gsm_subscriber_conn stores 2 struct sccp_instance*, one for
Lb (conn->lcs.lb.*)and one for A (conn->sccp.*).
They can actually point to the same sccp_instance or to different ones,
as explained above, depending on the configured setup. In any case, a
gsm_subscriber_conn needs 2 rb_nodes since it can hold
any of the 2 conn_ids independently (A or Lb).
The previous patch forgot to add that 2nd rb_node as well as some
initialization and release code for the Lb conn. This patch addresses
that.
When the 2nd rb_node, a problem when iterating the rbtree appears: how to
find out the "conn" pointer from the rb_node pointer, since the rb_node pointer
can be any of the 2 rb_nodes inside the struct at a different offsets.
In order to solve that problem, a new struct bscp_sccp_conn_node is
added, which holds all the relevant information used by the rbtree lookup code
in a generic way (rb_node and conn_id), plus a backpointer to the struct
bsc_gsm_subcriber it relates too.
Fixes: 85062ccad3
Change-Id: If42d93adee71d646766929a09bc01ae92b734ef3
It was found that on a busy osmo-bsc process (>1000 concurrent calls
spead over different BTSs), a good amount of time is spent iterating the
subscribers list trying to find a subscriber based on a TMSI (1.60% of
total CPU time used by osmo-bsc).
This patch introduces a new rbtree under struct bsc_subscr_store which
allows storing all the busbs ordered by TMSI.
This way, lookup time changes O(N) -> O(log(N)), at the expense of
increased insert/deletion time O(1) -> O(log(N)).
Related: SYS#6200
Change-Id: If27429e715ef4b327177e427249e68321a6e83cc
This allows keeping the bsc_subscriber storage internals outside of main
gsm_network code, while easily allowing making the internal
implementation more complex (in order to optimize it in a follow-up
commit).
It is also nice since we get rid of uncommon procedures being used in
this code, like allocating an llist directly as a talloc context, etc.
Change-Id: I616e8872af4ac63a6985f8900909e324ba889192
This option should be used for any executables which are used only
for testing, or for generating other files and are consequently never
installed. By specifying this option, we are telling Libtool that
the executable it links will only ever be executed from where it is
built in the build tree. Libtool is usually able to considerably
speed up the link process for such executables.
Change-Id: I37f078bdc17e128298b956f493ff5c03ef476f98
Prepare to include gsm_08_08.h in more files in the following patch,
without wrapping these functions it won't build anymore. Remove the
unused stub for bsc_assign_compl() while at it.
Related: OS#4393
Change-Id: I6cb84f493204e393fd719148f54b8bbc173588a4
This patch affects *only* on osmo_fsm instance IDs, which are visible on
the CTRL and VTY interfaces to identify FSM instances, and in the log.
Why bother: An upcoming patch wants to replace gsm_pchan_ids[] with
osmo_fsm_inst_update_id_f_sanitize(gsm_pchan_name(x)), this is an
explicit step to match gsm_pchan_names[].
Change-Id: I4a540744cced466f0ca4fc605db4d0ec14ee8e87
Show the timeslot_fsm, lchan_fsm, assignment_fsm fi->id strings.
The IDs include the current pchan configuration. I want to tweak the
composition of these in an upcoming patch, so the test should show
whether any FSM IDs change from that.
Change-Id: If369f23fa140b9d7792f5a511815cbbd14b371e9
We already use "OSMO_DYN" as C name for "fully dynamic" timeslot config,
when working with osmo-bsc.cfg I dearly miss this short name, it is a
pain / has become ridiculous to write 'tch/f_tch/h_sdcch8_pdch'.
Introduce 'dynamic/osmocom' and 'dynamic/ipaccess' as default names for
our dynamic timeslots on VTY and CTRL. The old 'tch/f_tch/h_sdcch8_pdch'
and 'tch/f_pdch' are still supported.
Change-Id: I37719edd867c777d1ce944b8e2f1efffac38f00e
I'm going to add a regression test that probes lchan_fsm. I noticed that
I have to call lchan_fsm_init() for osmo_fsm_register(). Let's make this
implicit as we usually do now, to not have to register FSMs in tests.
Change-Id: I58760e743c78a370aedc9720f265c0f8da5c2045
Prepare some basic tests for 'timeslot' / 'phys_chan_config', because an
upcoming patch will add the 'osmodyn' alias, and this test shall show
the changes on the VTY.
Change-Id: I2c4aab90bcbc9019ca004fb1d4945476edbb7363
*.vty tests are picked up by the Makefile.am by means of a wildcard --
they are run when they are there. So when you forget to add it to
EXTRA_DIST, it will be run in your local build tree, but it will be
silently omitted from a distribution tar, and nothing will complain
about it gone missing.
Instead, also use a *.vty wildcard in EXTRA_DIST. So any *.vty test
added to the git source will both be run *and* included in distribution
tars implicitly.
Change-Id: I47c9011b5e0e2886d221e34e6aa281d1dd0495c7
The second NSVC MO has been explicit skipped and never been interacted with.
osmo-bts is already supporting it for a long time as well the PCU is
supporting it at least since the NS2 code migration.
Fixes the ttcn3 test case BTS_Tests.TC_pcu_socket_two_nsvc.
Closes: OS#5835
Change-Id: I3486a7cc9a424602b73f8adc2fefce169213e46b
