aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2020-05-10release 1.6.0-fw.6fairwaves/1.6.0-fw.6Kirill Zakharenko1-0/+7
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
2020-05-08om2k: Use the "from config" TS config to setup OM objectsSylvain Munaut1-3/+3
During the configuration of the TS object through OML we must use pchan_from_config since it's too early to use anything else. Signed-off-by: Sylvain Munaut <tnt@246tNt.com> Change-Id: Iecdc911a79b66d8f3d746347710ad697cb288174
2020-05-08om2k: Properly name message 0x0136, found to be MCTR Statistics ReportSylvain Munaut1-2/+9
Signed-off-by: Sylvain Munaut <tnt@246tNt.com> Change-Id: I4b4389fd2e7bf0b3078b8ff60f6ea109114a4475
2020-05-08bts_nokia_site: Fix LAPD segfault during reset procedureHarald Welte2-25/+32
The existing Nokia *Site code destroyed the LAPD SAP instance for OML while processing an OML message. Once the stack frame returned back to the LAPD code, the LAPD SAP was gone -> segfault. Let's work around this by moving deletion of the LAPD SAP out-of-line by starting a timer 0ms in the future. Not particularly nice, but effective. Change-Id: I6270c7210f600e53f845561898245d2fd30a368d Closes: OS#1761
2020-05-05om2k: Acknowledge the unknown MCTR messages we get from time to timeSylvain Munaut1-0/+3
This is probably a fault report of some kind, but didn't get any confirmation or naming from anywhere for it yet. Signed-off-by: Sylvain Munaut <tnt@246tNt.com> Change-Id: I8333093d09f27f61094c7f5854573aa16e4bf28c
2020-05-05om2k: Acknowledge the HW Infos ReportsSylvain Munaut1-0/+7
Signed-off-by: Sylvain Munaut <tnt@246tNt.com> Change-Id: Ida92c9ca59a608854737ba9e330a5394cceff0fe
2020-05-05om2k: Fix type of msg_type in abis_om2k_tx_simpleSylvain Munaut1-1/+1
Thoses messages IDs are 16 bits and the upper 8 bits are sort of important :D Signed-off-by: Sylvain Munaut <tnt@246tNt.com> Change-Id: Ifcc1a01fdbf66a0f6f44cf8fed60dc19e72dd56a
2020-05-05om2k: Fix TS channel config payload for non-superchannel caseSylvain Munaut1-4/+8
* In superchannel mode, those 3 are required. * In normal mode, "Config Type" is optional and the two others are forbidden. Signed-off-by: Sylvain Munaut <tnt@246tNt.com> Change-Id: If02d02c067ae8af8ce693ddfb8747212f3f4e441
2020-05-05om2k: Don't use slashes in FSM IDs and use dashes insteadSylvain Munaut1-3/+4
slashes are invalid so we can't use om2k_mo_name() directly, so we just build it manually with dashes. Signed-off-by: Sylvain Munaut <tnt@246tNt.com> Change-Id: I3cfc19670e6d7bb607d796cabcee5e86a15d1985
2020-05-04gsm_data.h: Comment the 'nokia' BTS fieldsHarald Welte1-6/+6
Change-Id: I5e3eaf3dee97e2edcd80b20c3acf85bd89b40cdc
2020-05-04timers: T->X: 23002, 23004, 23005, 23006Oliver Smith2-5/+5
Make various internally used timers negative, to indicate that they are Osmocom specific. A follow-up patch will make them configurable. Change-Id: I6f8be40ea54a3083f4b21ab938cc1723fc67c2ef
2020-04-28om2k: Add VTY command to allow TX of arbitrary message for testingSylvain Munaut3-0/+45
Signed-off-by: Sylvain Munaut <tnt@246tNt.com> Change-Id: I5a385614fc670946f83ea79cc176c2d448675672
2020-04-28om2k: Allow the CON configuration request to be triggered via VTYSylvain Munaut2-0/+4
Signed-off-by: Sylvain Munaut <tnt@246tNt.com> Change-Id: Id1171a151773182bb5cdc14c023c3637fb9ad0bc
2020-04-28om2k: Allow TG and MCTR to be manipulated via VTYSylvain Munaut1-1/+3
Signed-off-by: Sylvain Munaut <tnt@246tNt.com> Change-Id: I3983ba9f06c48d515a7b739b00f05023af632267
2020-04-28om2k: Add definitions for the TG objectSylvain Munaut2-0/+2
Signed-off-by: Sylvain Munaut <tnt@246tNt.com> Change-Id: I6d90554a54baa78f454281a486e4b5e95784fdee
2020-04-20handorer.h: Fix compilation with gcc-10Harald Welte1-1/+1
/usr/bin/ld: bsc_subscr_conn_fsm.o:/home/laforge/projects/git/osmo-bsc/src/osmo-bsc/../../include/osmocom/bsc/handover.h:26: multiple definition of `mr'; abis_rsl.o:/home/laforge/projects/git/osmo-bsc/src/osmo-bsc/../../include/osmocom/bsc/handover.h:26: first defined here See also https://alioth-lists.debian.net/pipermail/debian-mobcom-maintainers/Week-of-Mon-20200413/000649.html Change-Id: Ic21af84f2a6de48d220940f30dad02a0e7683ce8
2020-04-14vty: clarify EGPRS Packet Channel Request message supportVadim Yanitskiy6-26/+76
According to 3GPP TS 44.060, section 12.24, GPRS Cell Options IE contains two parameters related to 11 bit Access Burst support: - ACCESS_BURST_TYPE - whether the 8 or 11 bit format shall be used in the PACKET CHANNEL REQUEST message, the PTCCH/U block, PACKET CONTROL ACKNOWLEDGMENT and the PS HANDOVER ACCESS messages on the PRACH (if present). - EGPRS_PACKET_CHANNEL_REQUEST - whether EGPRS capable MSs shall use EGPRS PACKET CHANNEL REQUEST message for Uplink TBF establishment on the RACH or on the PRACH (if present). The VTY option 'gprs 11bit_rach_support_for_egprs' actually controls the second parameter - EGPRS_PACKET_CHANNEL_REQUEST, though it may be hard to understand this from its name and description. This patch is actually a group of tightly related changes: - deprecate 'gprs 11bit_rach_support_for_egprs (0|1)': - update its description to avoid any possible confusion, - print a warning if it's used in non-EGPRS mode, - print a warning if it's still used; - introduce '[no] gprs egprs-packet-channel-request': - ensure that it can only set / printed in the EGPRS mode; - take a chance to clean-up / rename the related struct members: - 'supports_egprs_11bit_rach' -> bool 'egprs_pkt_chan_request', - remove 'supports_egprs_11bit_rach' from 'gprs_cell_options' because we already have 'ext_info.use_egprs_p_ch_req' there. Change-Id: Ied5bd10a806aeeac65ef32339d4ab0e3700e5da9
2020-04-11configure.ac: fix libtool issue with clang and sanitizerEric1-0/+5
As pointed out at https://github.com/libexpat/libexpat/issues/312 libtool does not play nice with clang sanitizer builds at all. For those builds LD shoud be set to clang too (and LDFLAGS needs the sanitizer flags as well), because the clang compiler driver knows how linking to the sanitizer libs works, but then at a later stage libtool fails to actually produce the shared libraries and the build fails. This is fixed by this patch. Addtionally LD_LIBRARY_PATH has no effect on conftest runs during configure time, so the rpath needs to be set to the asan library path to ensure the configure run does not fail due to a missing asan library, i.e.: SANS='-fsanitize=memory -fsanitize-recover=all -shared-libsan' export CC=clang-10 ASANPATH=$(dirname `$CC -print-file-name=libclang_rt.asan-x86_64.so`) export LDFLAGS="-Wl,-rpath,$ASANPATH $SANS $LDFLAGS" Change-Id: If71654d87b375b4b882ab527e89353cd035f695b
2020-04-06vty: 'gprs 11bit_rach_support_for_egprs': clarify error messageVadim Yanitskiy1-2/+1
Change-Id: I491d319f2829902a8c449db515f928cf7e480482
2020-04-06vty: 'gprs 11bit_rach_support_for_egprs': drop redundant checkVadim Yanitskiy1-7/+1
The VTY command parser would not allow values other than 0 or 1. Change-Id: Ic29fac12414f1821702759a9f5260e941c9868b5