aboutsummaryrefslogtreecommitdiffstats
path: root/src
AgeCommit message (Collapse)AuthorFilesLines
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-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 Munaut2-0/+44
Signed-off-by: Sylvain Munaut <tnt@246tNt.com> Change-Id: I5a385614fc670946f83ea79cc176c2d448675672
2020-04-28om2k: Allow the CON configuration request to be triggered via VTYSylvain Munaut1-0/+3
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 Munaut1-0/+1
Signed-off-by: Sylvain Munaut <tnt@246tNt.com> Change-Id: I6d90554a54baa78f454281a486e4b5e95784fdee
2020-04-14vty: clarify EGPRS Packet Channel Request message supportVadim Yanitskiy3-20/+66
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-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
2020-04-05vty: fix: restore removed DNAT category as deprecatedVadim Yanitskiy1-0/+1
This logging category has been removed in [1], what caused test case execution failures on our Jenkins (since build #930). The problem is that configuration files may still contain this category in 'logging' section (see [2], [3], [4]), and osmo-bsc would refuse to start because of that. [1] Id965295dfe04f8bd5ce831db70c86f67b8dc290b [2] Ie2afacfc15589c26238214cddc00baaf80e993c1 [3] I266d6f6ed54d1457b1ca63b87fc1c29f6dd40caf [4] If02272c08ba2df37d1295d09c104d11f96abbe1e Change-Id: I111362d19aba325889bada5a46eea62343c30033
2020-04-01remove 'NAT' log categoryHarald Welte2-7/+2
This dates back to a time where osmo-bsc_nat was in the same repository, which is a long time ago. Change-Id: Id965295dfe04f8bd5ce831db70c86f67b8dc290b
2020-03-29Meas Tools, Avoid compiler format warningsKeith1-3/+3
Change-Id: I8d807ffc4571f2954e3d1083da673dc1235e7687
2020-03-29Meas Tools: Avoid unusable terminal in case of error on osmo_sock_initKeith1-5/+4
If, as before this patch we call initCDKScreen() before attempting to bind the socket, then the socket bind fails, we exit and the terminal needs a reset. Attempt to open the socket before initCDKScreen() so we don't end up with a messed up terminal if the socket call fails. Change-Id: Ia5148d9ef386df314bc2837b3cb672150250bd2a
2020-03-28Meas Tools: Avoid OSMO_ASSERT due to uninitialised logging.Keith2-0/+29
The measurement tools use libosmocore socket functions that will use logging if the socket cannot be opened, but the tools did not initialise logging, resulting in Assert failed osmo_log_info logging.c:235 backtrace() returned 9 addresses [.....] Initialise logging so that we get a nicer and more informative message, such as: unable to bind socket:(null):8888: Address already in use no suitable addr found for: (null):8888 Change-Id: Ib3b3558723682defcee22e7ea2d8bf5c2cff1278
2020-03-27VTY: let all descriptions end in \nosmith/alert-bufferOliver Smith3-18/+18
Change-Id: I00a183078679db50567286a78c9e4f9afa3466c6
2020-03-27VTY: add show bts failure reportOliver Smith3-0/+78
Save OML failure reports from each BTS. Add a VTY command to display them conveniently and optionally clear the list. OsmoBSC> show bts 0 fail-rep [2020-03-23 14:51:22] Type=processing failure, Severity=minor failure, Probable cause=Manufacturer specific values: Software warning, Additional text=test message sent from VTY [2020-03-23 14:51:19] Type=processing failure, Severity=minor failure, Probable cause=Manufacturer specific values: Software warning, Additional text=test message sent from VTY Related: OS#1605 Change-Id: I18aa17a721cd5eb1c98926dc2367229c0a50bc78
2020-03-26abis_nm: move fail report parsing to extra funcOliver Smith1-40/+60
Separate raw input parsing from handling the failure report. A follow-up patch will use the new parsing function to print saved failure reports to the VTY. While at it, put struct tlv_parsed inside struct nm_fail_rep_signal_data instead of a pointer, so we don't need an additional alloc. Also add error handling to the abis_nm_tlv_parse() call. Related: OS#1605 Change-Id: Ia51004faf620aa4d40435d58c70d758c9d0054d8
2020-03-23abis_nm.c: rx_fail_evt_rep: fix sd.btsOliver Smith1-1/+1
Use the extra bts pointer instead of mb->trx->bts, which does not point to an allocated bts. Related: OS#1605 Change-Id: Ie61512f5690763fa380bdf0e7fb4763dbda019d2
2020-03-19main: exit on mutually exclusive codecs settingsOliver Smith2-2/+25
Refuse to start with mutually exclusive codec settings, unless allow-unusable-timeslots is set in the network section of the config. The checks were already implemented and fill the error log if the config is invalid. Related: OS#3739 Change-Id: I3ccfc3b0a8641400cb97a23b24d7ed92d2ad25cd
2020-03-16osmo-bsc/bsc_vty: fail on get_amr_from_arg errorOliver Smith1-11/+20
Fail parsing osmo-bsc.cfg if the AMR modes are not in order or not unique. Related: OS#4199 Change-Id: Ic2f3690396fb0425f6b358e1e21a8b8b56eb3ae0
2020-03-12osmo-bsc/bsc_vty: set default gprs cell bvci to 2Oliver Smith1-0/+3
Do not use 0 as default, as it is reserved for signalling. Related: OS#4408 Change-Id: I499272f16aadd89f3bdb5d749e3e4f9e07056c15
2020-02-12bssap: Avoid logging error if no optional Global Call Ref IE receivedPau Espin Pedrol1-11/+15
Also take the chance to simplify related code and print erroneous IE data. Change-Id: I27ee9c6112f96d6839b8b6141888ac8fe377db65
2020-01-29OM2000: Add some more message types and IEs we now understandHarald Welte1-0/+41
OM2000 is not only used for the venerable RBS2000 family, but also for the more modern RBS6000 family, specifically the DUG 20 GSM baseband unit. In RBS6000, there are some protocol extensions which are not yet fully understood. However, we are understanding some bits around the MCTR (multi carrier transceiver?), a new MO that appears to be present for every physical RUS (Radio Unit) attached to the DUG 20. Let's add what we have learned so far. Thanks to Sylvain Munaut for his help with this. Change-Id: Ib868358eca12b94c4fcca58e94ec8ab1a4edfda2
2020-01-18VTY: fix writing of custom timer values to a configuration fileVadim Yanitskiy1-2/+0
Calling osmo_tdef_vty_write() twice: with and without the 'timer ' prefix definitely looks like a bug. After setting any timer to a custom (non-default) value, config_write_net() would generate an incorrect configuration file: $ osmo-bsc -c /tmp/osmo-bsc.cfg There is no such command. Error occurred during reading the below line: T10 10 Change-Id: I5cc893fb2077bb21f1f661e30a7ab2af1b9bd561
2020-01-15bsc_main: use higher default loglevels.Philipp Maier1-3/+3
The loglevels of DNM, DFILTER and DPCU are set to low, lets set them all to NOTICE Change-Id: I03a5426b341e9908ffc89240f97d6d3ea791b4a8 Related: OS#2577
2020-01-06Introduce nm_fail_rep_signal_data for "SS_NM, S_NM_FAIL_REP" signalHarald Welte1-1/+19
Let's not just pass around the raw msgb, but also all other metadata, such as the decoded parts of the TS 12.21 message. As there's no current consumer of that signal, this creates no compatibility issues. Change-Id: I5d4d9d422b4e23348ffbe69c6e87a31d5574f90d
2019-12-06gsm_04_80: Avoid using deprecated APIHarald Welte1-1/+2
gsm_04_80_utils.c: In function ‘bsc_send_ussd_release_complete’: gsm_04_80_utils.c:37:9: warning: ‘gsm0480_create_ussd_release_complete’ is deprecated: Use gsm0480_create_release_complete() instead. [-Wdeprecated-declarations] 37 | struct msgb *msg = gsm0480_create_ussd_release_complete(); | ^~~~ CC gsm_data.o In file included from gsm_04_80_utils.c:22: /usr/local/include/osmocom/gsm/gsm0480.h:120:14: note: declared here 120 | struct msgb *gsm0480_create_ussd_release_complete(void) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The commit is not changing the existing logic/assumption: TID 0 should not be in use by anything else at the point the USSD is generated. Change-Id: I739158dec62cd5f0c2080fbb426af9c024baef87
2019-12-03exit(2) on unsupported positional arguments on command lineHarald Welte3-0/+13
Change-Id: I3b8781e220326387f1c437c39aff8661326f1e0a
2019-12-02abis_nm.c: fix RSL connection timeout for trx->nr > 0Vadim Yanitskiy1-4/+21
After sending of NM_MT_IPACC_RSL_CONNECT message, we start a timer, and stop it on receipt of NM_MT_IPACC_RSL_CONNECT_{ACK,NACK}. When running a multi-trx setup, one can see the following warnings: DRSL NOTICE abis_nm.c:2852 (bts=0,trx=1) RSL connection request timed out DRSL NOTICE abis_nm.c:2852 (bts=0,trx=2) RSL connection request timed out even despite NM_MT_IPACC_RSL_CONNECT is actually being acknowledged. The problem is in abis_nm_rx_ipacc(): we cannot just use sign_link->trx, because the message itself was received over the OML link, so this pointer always gives us C0/TRX0. Instead, we must find a TRX by its number from the FOH header using gsm_bts_trx_by_nr(). Change-Id: Ib4b9a198da11c88a51cfa78ffb7e7235a6365ef4
2019-12-01Move a_reset_fsm regstration to __attribute__((contructor))Harald Welte1-4/+5
This way we can avoid the runtime overhead of checking whether or not it is initialized over and over again. It also brings this code more in line with other users of osmo_fsm_register(). Change-Id: I3c7220491cf6ffb1361e7259c0344df64a013a0a
2019-12-01check for osmo_ss7_init() error return valueHarald Welte1-1/+1
Change-Id: I0297352e3cba5f01a971dc5924f0fcc67d1e6b32
2019-12-01check for osmo_fsm_register() error return valueHarald Welte2-4/+4
Change-Id: I77e8ace007a3d6b9c40d3e158d1cdb7576aab77b
2019-11-23fsm: use deferred deallocationNeels Hofmeyr1-1/+3
Since osmo-bsc uses the MGCP client FSMs, it is required to enable this new feature to guarantee safe operation. The issue is described in detail in commit logs linked below. Depends: Ief4dba9ea587c9b4aea69993e965fbb20fb80e78 (libosmocore), I0adc13a1a998e953b6c850efa2761350dd07e03a (libosmocore) Related: I7df2e9202b04e7ca7366bb0a8ec53cf3bb14faf3 (osmo-mgw) Change-Id: Ib7fce7b7d54dfb87af97544796680919e5929a50
2019-11-20bsc: Send MS Power Control msg upon max MS power changePau Espin Pedrol6-3/+28
Lots of times, the MS power class is unknown until after the first channel has been activated, at which point the MS power class is received in messages such as LU update or CM Service Requet. Since the MS Power level is sent upon CHAN ACT, the only way to communicate the change of maximum MS Power (based on MS power class) after CHAN ACT is to send a MS Power Control msg. Let's do that. Related: OS#4244 Change-Id: I3d6b75578e5cb9b2ad474a0ad01362d846ebe135
2019-11-19abis_nm.c: replace magic numbers with NM_CHANC_* constantsVadim Yanitskiy1-3/+3
Change-Id: I60b20d617bd8710a95977e41ae32a431af4402a9
2019-11-19abis_nm.c: fix error message in verify_chan_comb()Vadim Yanitskiy1-1/+1
Change-Id: Ic72753d821c3ab72cda79be71aed1704beefe983
2019-11-19cosmetic: bs11_config: clean trailing whitespacePau Espin Pedrol1-4/+4
Change-Id: I55f478c753c38baa576abc6ba53c4f6c9cbe61c0
2019-11-19bsc: Adapt maximum MS Power Ctrl level based on band and MS Power classPau Espin Pedrol4-13/+126
Related: OS#4244 Change-Id: I6bff440b7797e710bca5af94fae546e5d55e6972
2019-11-13Fix some typosMartin Hauke26-45/+45
Fix typos and common misspellings in code comments and in the manual. Change-Id: I46fc9d424620c77ae9ccf78b58081bd303386d7c
2019-11-02osmo_bsc_main.c: fix CCCH_CONF computation: use pchan_from_configVadim Yanitskiy1-4/+4
As can be seen from include/osmocom/bsc/gsm_data.h: - pchan_from_config - channel configuration from the VTY/config (can be changed from the VTY at runtime, should not affect the existing RSL/OML connections); - pchan_on_init - channel configuration after the OML link is established (pchan_from_config is copied here); - pchan_is - the *actual* channel configuration currently active. Since we call bootstrap_bts() during the initialization, even before establishing any OML/RSL connections, neither pchan_on_init nor pchan_is can be used. Let's use pchan_from_config instead. This change fixes the problem discovered by @mqng2 and reported together with https://gerrit.osmocom.org/c/osmo-bsc/+/15909: CCCH_CONF in System Information Type 3 does not reflect the actual channel configuration, and always indicates a single CCCH combined with SDCCH. This also misleads the lchan allocation algorithm during the MO connection establishment. Change-Id: I8f9d7aa27f24b55732a4de933bc834ed930806fd
2019-11-02osmo_bsc_main.c: simplify computation of CCCH_CONFIGVadim Yanitskiy1-23/+10
Do not count the number of additional CCCHs if TS0 is using combined channel configuration (CCCH+SDCCH4), because they are only allowed if TS0 is not combined with SDCCH. Get rid of the 'switch' statement using the following formula: CCCH_CONFIG = (N << 1) where N is the number of additional CCCHs. Change-Id: I1430500999389e9b30e55ea89a8a5ea5071f7957
2019-11-02osmo_bsc_main.c: verify the physical channel mapping at startupVadim Yanitskiy2-0/+61
As per 3GPP TS 45.002, section 3.3.2.3, and table 3 of clause 7, the following limitations apply mapping of CCCH/BCCH channels: - TS0/C0 shall be configured as CCCH/BCCH (optionally combined); - combined CCCH (CCCH+SDCCH4) can only be used on TS0; - additional CCCHs can be on TS2, TS4, and TS6; - additional CCCHs are not allowed if TS0 is combined. Let's make sure that OsmoBSC is properly configured before starring. Change-Id: I758ef80f7884ba35cdf59d671ee30222ffb9d68b
2019-11-02VTY: also print the active phan config in ts_dump_vty()Vadim Yanitskiy1-2/+3
Change-Id: I45c93a737ad82a2525f941e89cd19d4cedbf6f02
2019-10-31Remove unused API classmark_is_r99()Pau Espin Pedrol1-10/+0
Furthermore, similar API already exist in libosmocore: osmo_gsm48_classmark_is_r99() Change-Id: I6763d8c894f0a0555a9801bddbc0a12c2b945599
2019-10-29rsl: Send IE MS Power Param to osmocom BTS models onlyPau Espin Pedrol1-2/+10
Since MS Power Param IE content is operator dependant, it's currently not known which kind of content non-osmocom BTS support/allow, so let's avod possibily breaking those BTS until each BTS has been checked separately. Related: OS#1622 Change-Id: If44121222042bdac06c2a5e70f7b35a88b00b27c
2019-10-29rsl.c: Clean up some repeated use of long chains of pointersPau Espin Pedrol1-5/+9
Further accesses will be addter in forthcoming commit, so let's first store the pointers in variables to clean up the code. Change-Id: Ie5ea0f44dfb5731cab7e8e5a3dd3d791ee703df7
2019-10-28rsl: Send IE MS Power Param during CHAN ACT and MS PWR CTRL messagesPau Espin Pedrol1-0/+5
TS 48.058 sec 8.4.1 CHANNEL ACTIVATION and state: """ The BS and MS Power Parameters elements are included to indicate that BS and/or MS power control is to be performed by BTS. The maximum power to be used is indicated in the BS and MS Power elements respectively. """ Since we always want the BTS to do autonomous MS power control, let's add it. Related: OS#1622 Change-Id: Icaaa61b363b093f00b6653c3df64d3e66583b9f8
2019-10-28bsc_vty: Fix typo in 'no depends-on-bts' cmdPau Espin Pedrol1-1/+1
Change-Id: I32e0d3dc8672206f346d25b45e06e9e3fe0b64e7
2019-10-11sigtran: Set default remote ip to localhost instead of nullPau Espin Pedrol1-1/+2
NULL or 0.0.0.0 should actually not be used upon connect() calls. Whoever, it worked so far because osmo_sock_init2() calls getaddrinfo() on it which does the 0.0.0.0->127.0.0.1 translation. osmo-msc already passed 127.0.0.1 as default address, so let's do the same here. Change-Id: Ib0d33c66faab78e609742638425cb8a0c382406f
2019-10-03gsm_08_08.c: Mark func bsc_find_msc() staticPau Espin Pedrol1-1/+1
Its currently only used by bsc_compl_l3() in same file. Change-Id: I7273a9452dbc4c1285cfa69269fa36ab09551d89
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-26 15:10:42 +0000