New define is available since libosmocore 1.1.0, and we already require
1.3.0, so no need to update dependenices.
Let's change it to avoid people re-using old BSC_FD_* symbols when
copy-pasting somewhere else.
Change-Id: Ia5a656567d212fa265aef1375d714d0c5fee5dd6
We don't want to fprintf directly, and we want to make sure to always
log as much context as possible.
Change-Id: I29ec935669175a08cb42e1666559b681c50a6e72
When we introduced the timeslot FSMs in
I82e3f918295daa83274a4cf803f046979f284366, the BS-11 stopped to work, as
the timeslot FSMs are never brought out of NOT_INITIALIZED stage.
Closes: OS#4666
Change-Id: I557cb105247552887ca47a0f2c1b06b71bca6cac
There are a number of OML messages which are not seen on IP based
BTSs. Those are perfectly normal and expected on E1 based BTS.
Change-Id: Icd87fc9f3652b21f9d569af2572d080c9ac89e8b
Closes: OS#4665
Up to 16 SI2quater are multiplexed; each fits 3 EARFCNS, so the practical
maximum is 48 (of course depending on how many bits are used by other SI2quater
elements).
Change-Id: Iabeed10053ee5899b4def3509aedd25abb2410a9
In rest_octets.c append_earfcn(), the unconditional bits added are 40, not 25.
Removing only 25 bits from the budget resulted in malformed SI2quater starting
with 4 configured EARFCNs, by adding more EARFCNs than fit in 20 bits.
These malformed SI2quater were also expected in gsm0408_test.c. Update the
expected SI2quater to what is being generated now. This patch passes the ttcn3
testing added in I45382f88686ca60e68569e93569fc4cfb63a0e0d, which provides some
confidence that the coding expected in gsm0408_test.c is now correct.
Related: OS#4652
Change-Id: I5df269f713456a6ccbb874d6b7faac4a6f123c67
According to 3GPP TS 44.018, section 9.1.2.4, if at least one of
the Channel Description IEs indicates frequency hopping, one and
only one of the following IEs shall be present:
- Mobile Allocation, after time (see 10.5.2.21);
- Frequency List, after time (see 10.5.2.13).
For some reason, osmo-bsc includes the GSM48_IE_MA_BEFORE instead
of GSM48_IE_MA_AFTER - fix this.
According to section 9.1.2.6 of the same document, if any of the
Mobile Allocation IEs (before/after time) is present, then the
network must ensure that either the MS has already received the
the proper reference cell frequency list (CA), or that the Cell
Channel Description IE (see 10.5.2.1b) is present.
Without this IE, the phone I was using in my testing setup sends
RR Status message with cause #100 "conditional IE error".
Fortunately, we already have generate_cell_chan_list(), since we
also need to include the Cell Channel Description in SI Type 1.
Change-Id: I43ef66c109b107ebcaa1cb6197637701b13b3787
Related: SYS#4868, OS#4545, OS#4546
Refactor osmo_bsc_sigtran_init(): invoke osmo_sccp_simple_client_on_ss7_id()
exactly once per cs7 instance.
When introducing MSC pooling to the ttcn3-bsc-tests, it became apparent that
osmo-bsc rapidly huts down and re-creates the SCTP link for each configured
MSC. This manifested in an osmo-stp crash (fixed in libosmo-sccp
I9b3ae6dfcf6efeabb7fb6c33503d1d7924fec2fa). I first tried to fix it by only
restarting an ASP when it wasn't found in the AS yet, but that created obscure
problems described in OS#4635 which in turn completely broke ttcn3-msc-tests.
This solution keeps osmo_sccp_simple_client_on_ss7_id() unchanged and instead
invokes it exactly once per cs7 instance.
Keep the same auto-config logic, but change and improve the mechanisms to
achieve it:
Replace the fail_on_next_invalid_cfg flag with a more accurate check against
remote PC collisions between configured MSCs. Before this patch, the code made
sure that at most one MSC lacks an explicit remote address (and cs7 instance),
so that no two MSCs get the same default remote PC. This patch more accurately
checks that no two MSCs use the same remote PC on the same cs7 instance,
period, whether implicitly or explicitly configured.
Before this patch, the logic amounted to creating cs7 instance 0 implicitly,
but it was not very obvious: If an 'msc' has an msc-addr configured, it is
associated with the cs7 instance that has this addr in its address book. If it
has no msc-addr configured, then msc->a.cs7_instance_valid == false. In that
case, msc->a.cs7_instance is still 0 (from talloc_zero) and hence
osmo_sccp_simple_client_on_ss7_id(ss7_id = 0) created cs7 instance 0. In this
patch, that logic remains unchanged, but is written out more explicitly: if any
msc has no cs7 instance associated, make sure to create cs7 instance 0
beforehand.
Then iterate all osmo_ss7_instances. If at least one MSC uses it, set up the
SCCP client on it and connect all MSCs as appropriate.
Related: OS#4625 OS#4635
Change-Id: I16f4f7f447f69525a2f57c4649ab295112904d6a
The IPACC protocol is an extension to the conventional RSL protocol
to negotiate ip address and port for RTP/VoIP. This protocol is BTS
specific (sysmobts, ip-access nanobts) and not used with E1 BTSs
The bsc VTY is able to trigger certain IPACC functions for debug
purposes. Some of those commands do not check if the BTS is really of
type IP-access before trying to send an IPACC command. Let's add
checks to prevent IPACC messages to be sent to E1 or otherwise
incompatible BTSs models.
Change-Id: I9ee78b6b1d342abaccc09a87dee6af79e76e5468
Related: OS#2547
According to 3GPP TS 48.058 (version 15.0.0), section 9.3.5, the
3GPP TS 24.008 "Mobile Allocation" shall for compatibility reasons
be included but empty, i.e. the length shall be zero. Therefore,
no matter if frequency hopping is in use or not, send it empty.
Change-Id: Ie224a45f10522332eac653fa371564f022108c3f
Related: OS#4545, OS#4546
In the state LCHAN_RTP_ST_WAIT_MGW_ENDPOINT_CONFIGURED, the event
LCHAN_RTP_EV_ROLLBACK is allowed and also handled in the action
callback, which causes a change to LCHAN_RTP_ST_ROLLBACK. However,
LCHAN_RTP_ST_ROLLBACK is missing from the out_state_mask.
Change-Id: Ifca3892901c8389beee6e4f0fea03c33cfbdc265
We assume the SI shall be re-sent because something has changed. This
means that change_mark should be incremented. Let's call
gsm_bts_set_system_infos() which already does the trick.
Change-Id: I73d9bd3cddc561f3a7af8bcc225fac126dca3f78
Closes: OS#3679
This recently merged patch introduced a new bad segfault in bsc_compl_l3() by
dereferencing conn->sccp.msc before it was set to the actual msc pointer:
commit 6281d4f869
"fix crashes due to OSMO_ASSERT(conn->lchan)"
Change-Id Id681dfb0ad654bdb4b71805d1ad4f39a8bf6bbd1
Fix that by moving the new checks back further down in bsc_compl_l3(), to where
conn->sccp.msc actually points at the msc.
Change-Id: Ic5832da7c58fce583caa504a90f18c334fc234f2
Found while playing with "rf_locked 1" on a 2TRX setup with channel
allocator descend. After applying the setting, the 1st TRX is still used
to allocate the channels. After this patch is applied, the BSC correctly
allocates channels from TRX0.
Change-Id: I5201d2749363c9cbd0706177bde09117b163cbe3
Starting from ttcn3-bsc-test-sccplite build #777, it was noticed
that osmo-bsc crashes with the following message:
Assert failed conn->lchan include/osmocom/bsc/gsm_data.h:1376
The cause of this is a recently merged patch that calls conn_get_bts() during
assignment_fsm rate counter dispatch:
"Count assignment rates per BTS as well"
commit b5ccf09fc4
Change-Id I0009e51d4caf68e762138d98e2e23d49acc3cc1a
The root cause being that the assignment_fsm attempts to count an Assignment
event for a BTS after the lchan has already been released and disassociated
from the conn.
The assertion is found in conn_get_bts(), which is used in various places. In
fact, each caller is a potential DoS risk -- though most are in code paths that
are guaranteed to have an lchan and bts present, having an OSMO_ASSERT() on the
relatively volatile presence of an lchan is not a good idea for osmo-bsc's
stability and error resilience.
- Change conn_get_bts() to return NULL in the lack of an lchan.
- Adjust all callers of conn_get_bts() to gracefully handle a NULL return val.
- Same for cgi_for_msc() and callers, closely related.
Here is a backtrace:
Program received signal SIGABRT
pwndbg> bt
0x0000555555be6e52 in conn_get_bts (conn=0x622000057160) at include/osmocom/bsc/gsm_data.h:1376
0x0000555555c1edc8 in assignment_fsm_timer_cb (fi=0x612000060220) at assignment_fsm.c:758
0x00007ffff72b1104 in fsm_tmr_cb (data=0x612000060220) at libosmocore/src/fsm.c:325
0x00007ffff72ab062 in osmo_timers_update () at libosmocore/src/timer.c:257
0x00007ffff72ab5d2 in _osmo_select_main (polling=0) at libosmocore/src/select.c:260
0x00007ffff72abd2f in osmo_select_main_ctx (polling=<optimized out>) at libosmocore/src/select.c:291
0x0000555555e1b81b in main (argc=3, argv=0x7fffffffe1b8) at osmo_bsc_main.c:953
0x00007ffff6752002 in __libc_start_main () from /usr/lib/libc.so.6
0x0000555555b61bbe in _start ()
In the case of the assignment_fsm counter, we now miss a chance to increase a
BTS counter for a failed Assignment, but this is a separate problem. The main
point of this patch is that osmo-bsc must not crash.
Related: OS#4620, OS#4619
Patch-by: fixeria
Tweaked-by: neels
Fixes: I0009e51d4caf68e762138d98e2e23d49acc3cc1a
Change-Id: Id681dfb0ad654bdb4b71805d1ad4f39a8bf6bbd1
osmo-bts (in combination with osmo-pcu) has been supporting paging
for CS services via PCU/PACCH for a very long time. Let's make sure
this is reflected by the correct BSS_PAGING_COORDINATION bit.
Change-Id: I0e80ca5afc06737273b6699bde6e325e454b57f6
Requires: libosmocore.git Ifb2e83eaf05dd36e5b203ed2de1a74864b039e38
Related: OS#2406
If the BTS downlink CCCH (PCH + AGCH) queue is full, it sends
us an RSL DELETE INDICATION. So far, osmo-bsc logs this as
<0004> abis_rsl.c:2026 Unimplemented Abis RSL TRX message type 0x14
which is not very helpful. Instead, make the log message more
descriptive and add a rate counter for monitoring.
Change-Id: I9bd2966db90e39ccca442d6bc9abc91e9a9147d4
Closes: OS#3190
Particularly on BS-11 with only one TRX installed, this will improve
the output of bs11_config from
PHASE: 2 Load MBCCU MBCCU0: Load BTSDRX MBCCU1: unknown 0x8 Abis-link: Down
to
Change-Id: I10a77315d537681985f8390b838a4cabfb7d27f3
PHASE: 2 Load MBCCU MBCCU0: Load BTSDRX MBCCU1: Not equipped Abis-link: Down
For historical reasons we had bsc_vty.c and osmo_bsc_vty.c. Ever since the
osmo-nitb split, there is no reason to keep these files separate. Merge
osmo_bsc_vty.c into bsc_vty.c (because osmo_bsc_vty.c is smaller).
I noticed this particularly because adding the NRI configuration required
adding things like #define NRI_STR in two separate files: once for the
'network' level vty, and once for the 'msc' level.
Change-Id: I7fd2ee631b22e38f3d96d8159dc1deaaca6a7013
This message may contain optional IEs (HSN, MAIO, ARFCN list),
so we cannot know the final length in advance. Let's set both
msg->{l2h,l3h} pointers and use msgb_l3len() to get the length.
Change-Id: I948ad4b847921324794a6eabd95d5583324da6e4
Related: OS#4545
3GPP TS 12.21 defines coding of 'ARFCN List' attribute as follows:
+---------------------------+--------------------+
| Attribute Identifier | 1st octet |
+---------------------------+--------------------+
| Length | 2-3 octets |
+---------------------------+--------------------+
| ARFCN1 | 4-5 octets |
+---------------------------+--------------------+
| ... | ... |
+---------------------------+--------------------+
| ARFCNn | (n * 2 - 3) octets |
+---------------------------+--------------------+
so this is basically TL16V, where L16 is the length of V.
In the Siemens dialect of OML coding rules are different though:
+---------------------------+--------------------+
| Attribute Identifier | 1st octet |
+---------------------------+--------------------+
| ARFCN count | 2nd octet |
+---------------------------+--------------------+
| ARFCN1 | 4-5 octets |
+---------------------------+--------------------+
| ... | ... |
+---------------------------+--------------------+
| ARFCNn | (n * 2 - 2) octets |
+---------------------------+--------------------+
so this is TCV, where C is the amount of ARFCNs in V.
This change fixes encoding of 'ARFCN List' for other dialects,
in particular encoding of the 'Length' field (1 vs 2 octets).
I verified the results in Wireshark (generic 3GPP TS 12.21
and ip.access dialect), everything looks good.
Change-Id: Iec1826f55459ac8e9355328a1a6bb0949874db60
Related: OS#4545
Tests for these counters are added in I2006f1def5352b4b73d0159bfcaa2da9c64bfe3f
(osmo-ttcn3-hacks).
Change-Id: I2ded757958dfa62b502efbab765203bcadf899e2
In the ttcn3 tests, the MSC round robin algorithm is affected by what tests ran
before, so an osmo-bsc test needs this to reset the round robin to get
predictable behavior to test against.
Change-Id: I2155d906505a26744966f442ffb1e87a6a9b494c
As in 3GPP TS 23.236, to offload an MSC, the BSC must be able to avoid
attaching new subscribers to it:
4.5a.1: "UEs being moved from one CN node are stopped from registering to the
same CN node again by an O&M command in BSCs and RNCs connected to the pool."
Change-Id: I6249201c15d0f6565aca643c21d2375c9ca58584
At this time, no MSC has been selected for handling this subscriber, so DMSC is
clearly the wrong logging category.
Change-Id: I9c6373e5f28c9c69a0609889188ef28ade11da3d
Use the new osmo_mobile_identity API to shed some code dup and simplify.
gsm48_paging_extract_mi() is now unused, drop.
(More refactoring to use osmo_mobile_identity follows in subsequent patch.)
Depends: If4f7be606e54cfa1c59084cf169785b1cbda5cf5 (libosmocore)
Change-Id: Id6cccaac64392b737b3bba8f3a22a88009adb23b
Move 'doc' subdir further down to "make sure" the osmo-bsc binary is built
before the docs.
Remove bsc_vty_reference.xml from the source tree.
In manuals/Makefile.am use the new BUILT_REFERENCE_XML feature recently added
to osmo-gsm-manuals, and add a build target to generate the XML using the new
osmo-bsc --vty-ref-xml cmdline switch.
Depends: I613d692328050a036d05b49a436ab495fc2087ba (osmo-gsm-manuals)
Change-Id: I5dc872149154e1a949bb6a2b9bbc1461e0fc51f6
Add only a long option to not clutter the cmdline namespace.
To add a long option without a short letter is slightly complex: use the 'flag'
and 'val' mechanism as in 'man 3 getopt' to write an option index to
long_option.
Depends: Ic74bbdb6dc5ea05f03c791cc70184861e39cd492 (libosmocore)
Change-Id: I316efedb2c1652791434ecf14a1e261367cd2fb7
This adds the assignment counters for the BTS as well and changes the
assignment_count() macro to increase both the counters for the BSC as
well as the BTS.
Related: SYS#4877
Change-Id: I0009e51d4caf68e762138d98e2e23d49acc3cc1a