aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2020-05-18release 1.6.0-fw.9fairwaves/1.6.0-fw.9Kirill Zakharenko1-0/+6
Change-Id: I514dc8f9a3846d074b9b7e9552a2d53613719e85
2020-05-18Merge fairwaves/WIP-dyn-chan-load, fairwaves/log-work, ↵Kirill Zakharenko14-20/+245
fairwaves/mt_mm_info_crash into master Change-Id: I3fe36316310ba03f3d2a2eb78c61bd394ba7c459
2020-05-18bssap: Handle BSSMAP CONFUSION message.Alexander Chemeris4-0/+69
We decode the mesage and print it to the log files at ERROR log level. We also count it in the BSSMAP message counters. There is not much else we could do about it. Requires: libosmocore.git Change-Id If8afd2d096fb66c6c2f255a08fc1129de3d09cec Change-Id: Ib4cd94f185f751b2384842222678ff671ac413c4
2020-05-18stats: Correctly count lchans under BORKEN/NOT_INITIALIZED TS.Alexander Chemeris1-0/+8
lchans under a BORKEN/NOT_INITIALIZED TS should be counted as used just as BORKEN lchans under a normal TS. Change-Id: Ic3dbc6b176d5dcff7ed2589bb875abf93e9f7ab0
2020-05-18stats: Add a BTS/BSC counter PAGING_NON_ACTIVE.Alexander Chemeris2-0/+6
Otherwise we're missing an important part of the callflow and the counters of responded/expired paging requests don't add up to attempted paging number. Change-Id: I1755be40d29980b75353cb4b8087d1ce0d92854a
2020-05-18stats: Add counters and gauges for BORKEN lchans/TSAlexander Chemeris5-11/+148
Now we can monitor the situation with the BORKEN lchans and TS in our BTS's over time. Change-Id: I427bbe1613a0e92bff432a7d76592fe50f620ebe
2020-05-18borken: Recover from more TS borken states.Alexander Chemeris1-3/+16
Change-Id: Ic87c325a73690ede1b81b4d33bac65a1a4beea2d
2020-05-17log: Demote "SAPI=%u ESTABLISH CONFIRM" message from ERROR to DEBUG.Alexander Chemeris1-1/+1
Not sure why this specific message is ERROR while similar ones around are DEBUG. So let's fix this disparity by demoting this message level. Change-Id: I655d4555f037def354aacbc5f089794f5fe811ed
2020-05-17log: Demote "CHAN RQD: reason" to INFOAlexander Chemeris1-1/+1
The "CHAN RQD: reason" message is purely informational and is a part of normal operation. Nothing to NOTICE there. Let's demote this to DEBUG. Change-Id: I325f2beb3248ed8eb25d1d8494c3868c5be4b758
2020-05-17Fix crash in bsc_patch_mm_info()Alexander Chemeris2-11/+3
osmo-bsc has crashed with the following backtrace: 0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 1 0x00007f0bc49b38db in __GI_abort () at abort.c:100 2 0x00007f0bc581ba30 in osmo_panic () from /usr/lib/x86_64-linux-gnu/libosmocore.so.12 3 0x00005648ceeced69 in conn_get_bts (conn=<optimized out>) at ../../include/osmocom/bsc/gsm_data.h:1392 4 0x00005648cef37164 in conn_get_bts (conn=0x5648cf769e80) at osmo_bsc_filter.c:87 5 bsc_patch_mm_info (conn=conn@entry=0x5648cf769e80, data=<optimized out>, length=<optimized out>) at osmo_bsc_filter.c:48 6 0x00005648cef371b6 in bsc_scan_msc_msg (conn=conn@entry=0x5648cf769e80, msg=msg@entry=0x5648cf77ead0) at osmo_bsc_filter.c:159 7 0x00005648cef33988 in dtap_rcvmsg (msg=0x5648cf72b2f0, length=40, conn=0x5648cf769e80) at osmo_bsc_bssap.c:1215 8 bsc_handle_dt (conn=conn@entry=0x5648cf769e80, msg=0x5648cf72b2f0, len=40) at osmo_bsc_bssap.c:1299 9 0x00005648cef3b2b7 in handle_data_from_msc (msg=<optimized out>, conn=0x5648cf769e80) at osmo_bsc_sigtran.c:152 10 sccp_sap_up (oph=0x5648cf72b378, _scu=<optimized out>) at osmo_bsc_sigtran.c:267 11 0x00007f0bc5813c03 in _osmo_fsm_inst_dispatch () from /usr/lib/x86_64-linux-gnu/libosmocore.so.12 12 0x00007f0bc51a8935 in sccp_scoc_rx_from_scrc (inst=inst@entry=0x5648cf6a8d60, xua=xua@entry=0x5648cf720150) at sccp_scoc.c:1695 13 0x00007f0bc51a62f3 in scrc_rx_mtp_xfer_ind_xua (inst=inst@entry=0x5648cf6a8d60, xua=xua@entry=0x5648cf720150) at sccp_scrc.c:459 14 0x00007f0bc51a9545 in mtp_user_prim_cb (oph=0x5648cf7681f8, ctx=0x5648cf6a8d60) at sccp_user.c:182 15 0x00007f0bc51a09c6 in m3ua_rx_xfer (xua=0x5648cf764a80, asp=0x5648cf45f540) at m3ua.c:586 16 m3ua_rx_msg (asp=asp@entry=0x5648cf45f540, msg=msg@entry=0x5648cf71e880) at m3ua.c:739 17 0x00007f0bc51b0763 in xua_cli_read_cb (conn=0x5648cf441ed0) at osmo_ss7.c:1761 18 0x00007f0bc55fab53 in osmo_stream_cli_read (cli=0x5648cf441ed0) at stream.c:232 19 osmo_stream_cli_fd_cb (ofd=<optimized out>, what=1) at stream.c:321 20 0x00007f0bc580edcf in ?? () from /usr/lib/x86_64-linux-gnu/libosmocore.so.12 21 0x00007f0bc580f526 in osmo_select_main_ctx () from /usr/lib/x86_64-linux-gnu/libosmocore.so.12 22 0x00005648ceecfb2f in main (argc=<optimized out>, argv=<optimized out>) at osmo_bsc_main.c:953 Apparently, there is no lchan allocated at this moment, so conn_get_bts() crashes. But we only use it to get to "network" which we can do much easier and safer by doing conn->network. Change-Id: Id3f7b3efba60c0f050c1be98e5e539f1dab4cd57
2020-05-17bssmap: Ignore repeated BSSMAP RESET ACK messages.Alexander Chemeris1-1/+4
We're sending multiple RESET messages to establish a conection with an MSC and MSC can (and often will) respond with multiple RESET ACK messages. We should not treat this as an ERROR as it used to be in the original code. Change-Id: I109d638d5167e24f0357e3541415b9e7269aa5d1
2020-05-16A-bis: fix logging level mismatch in abis_nm_rcvmsg_fom()Vadim Yanitskiy1-2/+2
Change-Id: If8f76af4d1e0eb2d7b3534e620e2816cdbbe0b7d
2020-05-16log: Adjust "new SIGTRAN connection" logging levelAlexander Chemeris1-2/+2
The "new SIGTRAN connection" message is sent on every new transaction between an MS and MSC, i.e. A LOT during normal operation. Let's demote it to INFO and clarify that this is about SCCP connection instead of a generic SIGTRAN term. Change-Id: I711b70ae84aa98f43ea3f807ea5c8464b71ca6bb
2020-05-16log: Fix "Paging request failed" logging levelAlexander Chemeris1-1/+1
"Paging request failed" message can be logged e.g. when we're already paging this subscriber which means we get hundreds of these messages in a perfectly normal situation. Let's demote this to INFO and adjust the wording. Change-Id: I97214796906ac599338e87b2b4b5465ab6b2447a
2020-05-15bsc_vty: Coding style fix - brackets around a complex if/elseAlexander Chemeris1-2/+2
Change-Id: I771ef866aba6af9e2a10a06e593eef78b7405377
2020-05-13manual: fix config example typo 'msc-addr'Neels Hofmeyr1-1/+1
Change-Id: Ifb84d7ceddc772e3e1ae59c8d5859b6be6f1b4eb
2020-05-11stats: Rename BSSMAP Rx message counters to match Tx ones.Alexander Chemeris3-19/+19
Change-Id: I29e42687ac084a60007f0b1ec6ec0a102fb4007f
2020-05-11stats: Add counters for Tx BSSMAP messages.Alexander Chemeris8-3/+105
We already have counters for Rx side, now we also count Tx side. See comments in the msc_ctr_description array implementation for the details. Change-Id: I89a173f6bdd9a3c21233fe01d07ab2ff0442bb10
2020-05-11handover_test: Properly allocate MSC data struct.Alexander Chemeris1-9/+1
Without a properly allocated MSC struct, touching counters crashes the test. Change-Id: I7498d2891259be9b532845627f14ac75e98e703e
2020-05-11stats: Only dereference a connection pointer after checking for NULL.Alexander Chemeris1-1/+2
Addresses CID 210261. Change-Id: Ic7e7c92c5b9ff696fa7f4cd0d69451cd22333f71
2020-05-09timeslot_fsm: Allow PDCH_ACT_ACK in BORKEN state.Alexander Chemeris1-0/+8
It should be fine if we receive PDCH_ACT_ACK late. We should just go into the PDCH state as normal. Change-Id: If816b681e0b2e76fb7122cf211e15eeee92451ee
2020-05-09lchan: Allow transition from BORKEN state to WAIT_RF_RELEASE_ACKAlexander Chemeris1-0/+1
In the lchan_fsm_borken() we request to change the state to LCHAN_ST_WAIT_RF_RELEASE_ACK in response to a late LCHAN_EV_RSL_CHAN_ACTIV_ACK event but this transition is prohibited by the FSM definition, so the channels stay in the BORKEN state forever. :( Change-Id: I17a9b935a116eb842fd0239ef53d73bef35e6511
2020-05-09bsc_subscr_conn_fsm: Fix a typo in the comment life->liveAlexander Chemeris1-1/+1
Change-Id: Ideba357678a59e3f314a0d618d181a233a43b4de
2020-05-09stats: Fix Rx DTAP error stat descriptionAlexander Chemeris1-1/+1
Change-Id: Ie6debad36a49005676ff47eda644c90eee5dc461
2020-05-09a_reset: Rename SIGTRAN connection to BSSMAP MSC assocation in log messagesAlexander Chemeris1-2/+2
Explanation from Harald: There are plenty of things that can happen above the bare SCTP/M3UA connection which can happen, such as SCCP or MTP level routing problems. The fact that a MSC responds to a BSSMAP reset tells us that all of the underlying SS7 transport network is operational and the MSC responds to us. Go draw an IP analogy: Saying "SIGTAN connection up" here is like saying "Ethernet link up" when you get an ICMP response. Change-Id: If9d37c94f2f2b6cffef97f445774766993f538db
2020-05-09bts_nokia_site: Fake 12.21 OM objet state as "OK" when boot is doneSylvain Munaut1-0/+35
Parts of Osmo-BSC want to see the NM state as valid ... Signed-off-by: Sylvain Munaut <tnt@246tNt.com> Change-Id: I0db11819d23e40272c4aa6fd093365b9c13f7bcf
2020-05-09stats: Export connected OML/RSL links count per BTS.Alexander Chemeris3-0/+8
Change-Id: I88c8025940a0eecb034b1c70f76ea17937fa0325
2020-05-09stats: Add counters for received BSSMAP messages.Alexander Chemeris3-0/+47
Change-Id: I3f08d71b58b4e8d6f61376d85c2051e194aa8e43
2020-05-09stats: report a number of configured BTS to a stats gauge.Alexander Chemeris3-0/+26
It's useful to know how many BTS are actually configured to compare it to a number of connected BTS's. Change-Id: I41cb60f9cb962003227e4a7b63db05acbcdb6f4c
2020-05-09stats: Add a stats gauge for the MSC links count.Alexander Chemeris3-6/+78
Change-Id: Ibe4b29056ba704a27b925cfdba49f343ee34f428
2020-05-09om2k: Fix invalid use of linked list when building hopping freq listSylvain Munaut1-4/+6
I originally assumed that after a complete scan with llist_for_each_entry the loop counter would be either NULL or a valid entry. That's just not the case. Fixes: CID#210256 Signed-off-by: Sylvain Munaut <tnt@246tNt.com> Change-Id: Iad647b74771c4ac406a88effd371ed7748c8847e
2020-05-09gsm_data: Update trx_is_usable for ericsson BTSSylvain Munaut2-0/+16
There is no bb_transc oject. Signed-off-by: Sylvain Munaut <tnt@246tNt.com> Change-Id: I34bb808cd21575ff25d36e6df028b140935a008f
2020-05-09chan_alloc: Don't re-invent trx_is_usable and use existing helperSylvain Munaut1-2/+1
Signed-off-by: Sylvain Munaut <tnt@246tNt.com> Change-Id: I1ca4a6ac6ec2f4e40c8421f31871d9c9e5ac5de5
2020-05-09osmo_bsc_sigtran: Fix a SSCP-> SCCP typo in a commentAlexander Chemeris1-1/+1
Change-Id: Iee7e87922f2aa034840993b4bfad3de8defbf5f1
2020-05-09chan_alloc: Add comments for the *_chan_load() functions.Alexander Chemeris1-0/+2
Change-Id: Ie199104fd4a6c0d5218f56b958d12fac4612fd78
2020-05-09Fix a comment for the handle_unitdata_from_msc() function.Alexander Chemeris1-2/+2
Change-Id: If20632cfe63b78c2cb17c1bb9d12207a4956be64
2020-05-09stats: Fix stat group index for BTS stats.Alexander Chemeris1-1/+1
osmo_stat_item_group_alloc() should be initialized with the BTS number. Change-Id: Iedef08af56ab6985894d89ff7b285246424ca9e7
2020-05-09Fix indent whitespace and log message.Alexander Chemeris1-5/+5
Change-Id: I985bf8ac4ce6136812692c06b6dc78edc6bde652
2020-05-08stats: Remove dots from the end of stats descriptions.Alexander Chemeris1-2/+2
Change-Id: I4e66b3c864f6c54332fd6dabb0ec549c3590a1f2
2020-05-08stats: Report per channel type load to statsd counters.Alexander Chemeris3-0/+82
Change-Id: I2eac4c93061204aeb8f3d223f7e78158c61c7156
2020-05-08ctrs: Correctly count load total for dynamic timeslots.Alexander Chemeris1-0/+22
From the CS perspective, there is no difference whether this is a dynamic TS in NONE/PDCH mode or a static TCH in UNUSED mode since BSC can switch into USED mode at any moment. So we should count dynamic timeslots in the "total" count. A bit of a challenge here is that GSM_PCHAN_TCH_F_TCH_H_PDCH timeslots could be either switched to a single TCH/F or to two TCH/H, so the total can't be calculated reliably beforehand. In this code we assume TCH/F since this gives a lower total count. Change-Id: Iabd70e8adbf15eb3b7a7be597281ea99b352317b
2020-05-08om2k: Wait for OM TRX links to stabilize before trying to bring up TRXSylvain Munaut1-10/+31
The OM2K link "per-trx" only comes up after MCTR is setup. So that means we need to wait for it before trying to boot the TRX itself. He we simply apply a "dumb" 5 sec timeout as this is the most reliable way I found to get this working reliably. Tracking the link state proved difficult and unreliable: - Multiple TRX can be present with their link coming up in random order. - They can already be up at the start (BTS already initialized from a previous boot) and so the link may actually come up, down, and up again. - All of theses transitions might happens before/after we get to the OM2K_BTS_S_WAIT_TRX state depending on how the LAPD timeout expire, if the BTS config was actually changed or not and how much time it takes to apply the new config. So all in all, what we must do is wait for the link to stabilize ... hence just waiting 5 second. Signed-off-by: Sylvain Munaut <tnt@246tNt.com> Change-Id: I55a06e08b9c52ff6e97e8c72f2d55770809eba51
2020-05-08om2k: Properly update the 'fake' 12.21 states using OM2000 statusSylvain Munaut1-3/+39
Signed-off-by: Sylvain Munaut <tnt@246tNt.com> Change-Id: I1caafa2e87c6198bf3b1a77f0fa1edc774deeef9
2020-05-08om2k: Add support for MCTR configurationSylvain Munaut2-1/+83
Currently only supports a single MCTR with fixed configuration Signed-off-by: Sylvain Munaut <tnt@246tNt.com> Change-Id: I96b8bb2c01c05bf153fc924f62bd6aafa96725ee
2020-05-08om2k: Rename MCTR config request constants for consistencySylvain Munaut1-6/+6
Signed-off-by: Sylvain Munaut <tnt@246tNt.com> Change-Id: I776b0016837e018500ef69acb2f30a274008818e
2020-05-08om2k: Add option to limit OML version during negotiationSylvain Munaut3-8/+91
Starting from G12R13 the MCTR swiches to BSC controlled mode. And although we think we know how to configure it (via MCTR Conf Req), something doesn't work right and the timeslot configuration is not accepted. (TS Conf Result shows "Data not according to request"). So as a workaround for now, we use this version of the protocol where we don't configure the MCTR (it's in "BTS controlled mode") and with this protocol, the BTS accepts our timeslot config and we can bring the system up. This commit add a generic option to limit either OML or RSL IWD version to any value. It also keeps track of the actual negotation version so we can react to it in other places of the code. Signed-off-by: Sylvain Munaut <tnt@246tNt.com> Change-Id: I8f0b0ba72056ea4250fe490e7a38630c77c04f65 better version limit Change-Id: Ia789f8ede3eab7eeca6c759da0109e0b53398f60
2020-05-08bts_ericsson_rbs2000: Whitelist the E1d input driverSylvain Munaut1-2/+4
Signed-off-by: Sylvain Munaut <tnt@246tNt.com> Change-Id: Ief9093706d6ca20f8162ca541dcc4669c13e2cbc
2020-05-08bts_ericsson_rbs2000: Init all the TRX, not just C0Sylvain Munaut1-2/+6
Signed-off-by: Sylvain Munaut <tnt@246tNt.com> Change-Id: I9417f433f759ce21b8b6e0b74cd686df5388f8c5
2020-05-08om2k: Fix the frequency specifier for TX/RX/TS conf requestsSylvain Munaut1-7/+38
* OM2K_DEI_FREQ_SPEC_RX: (hop << 15) | (rx_addr << 10) | arfcn . hop Hopping marker . rx_addr is not really the TRX number, it's just a sequential number different for all TRX, doesn't need to be 'in-order' of TRX . arfcn The ARFCN number (0 for hopping and 1023 for 'no frequency') * OM2K_DEI_FREQ_SPEC_TX: (hop << 15) | (tx_id << 10) | arfcn tx_id Pretty much same as rx_id except here we know that the order doesn't have to match TRX order. It seems to even vary from one reboot to another on some real-world capture we got. . hop Hopping marker . tx_addr Same as 'rx_addr' above but for TX . arfcn The ARFCN number (0 for hopping and 1023 for 'no frequency') * OM2K_DEI_FREQ_LIST: Groups of 3 bytes (24 bits), 1 per frequency used. (tx_addr << 20) | (rx_addr << 16) | (is_c0 << 10) | arfcn . tx_addr See above . rx_addr See above . is_c0 Must be 1 if that ARFCN hosts the C0. (first TRX of a MCTR) . arfcn The ARFCN number (Note MAIO must also be set properly on the different TRX/TS sharing a frequency ... ) The way we generate theses here is what we gathered from real-world traces: - Each 'TX' of each TRX is set to the ARFCN set in that TRX config - Each 'RX' of each TRX is configures as 'hopping' (which I assume means it will just pick the appropriate freq ?) - For each TS, we use : . tx_addr of the TRX that has the ARFCN we want to TX on . rx_addr of the TRX where the TS we're configuring is . arfcn The actual ARFCN we want to add to the list This is incomplete but will work for the 1 MCTR case. Config for multiple MCTR or multiple virtual-bts still need to be handled but it's not yet known exactly how those need to be configured. Signed-off-by: Sylvain Munaut <tnt@246tNt.com> Change-Id: Ie39a857543adaa11d1822346d8563ce3718412c8
2020-05-08om2k: Dispatch TS_EV_OML_READY to TS FSM only when it's actually readySylvain Munaut1-6/+10
Signed-off-by: Sylvain Munaut <tnt@246tNt.com> Change-Id: Ic2a84ea406e9a39332313d63b27d73f334d4e0a0
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-20 08:47:01 +0000