aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2020-04-09VTY: make configurable: T23002, T23005, T23006osmith/abis-loadtest-timersOliver Smith1-0/+3
Default value is the current default of 5s for all timers that are not specified. It should be changed to what the spec says instead. Related: SYS#4897 Change-Id: I637fcdde93c11158de46157d494c060bb36bdcfb
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-06rest_octets: cosmetic: fix alignment in gprs_cell_optionsVadim Yanitskiy1-2/+2
Change-Id: I344ea61df8cc910d9b524c9b2f0e03721eefe56c
2020-04-05doc/manuals: remove deprecated DNAT from the VTY referenceVadim Yanitskiy1-10/+5
Change-Id: Ib21c30041508a9ec9afda56bda95bddf4d665bc8
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 Welte4-13/+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-30manual: add SCCPlite sectionNeels Hofmeyr1-1/+32
Change-Id: I8eddc47353d6afd756865321a9e97f6cee4ce2d7
2020-03-30manual: add SCCP/M3UA section from common chaptersNeels Hofmeyr3-1/+15
Link to the osmo-gsm-manuals/common/cs7-config.adoc chapter to fully explain the 'cs7' client configuration. Related: OS#2767 Depends: Ia2508d4c7b0fef9cdc57e7e122799a480e340bf7 (osmo-gsm-manuals) Change-Id: I5b4973901f02046322b852fd9862517982d21bd9
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: regenerate bsc_vty_reference.xmlOliver Smith1-7/+88
Change-Id: I27bcde8d36dcf8daa9d24b4b581c9526b73cb35e
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 Smith4-0/+86
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 Smith3-41/+64
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-22manual: add "Multiple Instances" section, akin to other manualsNeels Hofmeyr1-0/+67
Related: OS#2767 Change-Id: Ideb137f19d19144d35b05eb036098045bbb18d64
2020-03-19main: exit on mutually exclusive codecs settingsOliver Smith3-2/+28
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-17osmo-bsc-minimal.cfg: fix codec-listOliver Smith1-1/+1
All timeslots are configured for full rate, so the codec list must also have a full rate codec. Fix this error on startup: "Configuration contains mutually exclusive codec settings -- check configuration!" All other example configs don't have mutually exclusive codec settings. Related: OS#3739 Change-Id: Iddac13c7d644ed57b6d9e6a57d23d88c01bd8b8e
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 Smith2-0/+16
Do not use 0 as default, as it is reserved for signalling. Related: OS#4408 Change-Id: I499272f16aadd89f3bdb5d749e3e4f9e07056c15
2020-03-11tests/Makefile.am: allow running only one VTY testOliver Smith1-1/+4
Add VTY_TEST variable, just like in osmo-hlr Change-Id I4ad7ddb31b2bfb668b3540cfef658417dd442375. Change-Id: Ieb08ae57bd8bb68c9a8593b3e1175eae9064ac57
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 Welte2-0/+42
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 Welte2-1/+33
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
2020-01-03Bump version: 1.5.0.43-e1f08-dirty → 1.6.01.6.0Pau Espin Pedrol3-7/+68
Change-Id: I21556570e35d662bb902d5c1afc911b82d5eb1e6
2019-12-11debian, osmoappdesc.py, tests: switch to python 3osmith/fix-python3Oliver Smith4-226/+226
Make build and external tests work with python3, so we can drop the python2 dependency. This should be merged shortly after osmo-python-tests was migrated to python3, and the jenkins build slaves were (automatically) updated to have the new osmo-python-tests installed. Related: OS#2819 Depends: osmo-python-tests I3ffc3519bf6c22536a49dad7a966188ddad351a7 Change-Id: I438ca0c4b8e7957d0f347a5b2f5c4cb93f9325e6
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-05doc: osmux: use generated svg instead of pychartOliver Smith2-45/+824
Replace python 2 code using pychart to draw a graph in osmux-reference.adoc with the generated svg file. The upstream of pychart is dead, there is no python 3 version, and python 2 is EOL at the end of 2019. This is the only time we ever made use of pychart in osmo-gsm-manuals, so with this change, we can just drop the dependency. I've generated the chart by saving the python code in chart.py, then: $ ./chart.py --format=svg --font-size=3 > chart.svg Related: OS#2819, OS#4193 Depends: osmo-ci I754b133d77743582bd84c33c74ecc9eb9ca4c0ef Change-Id: I36b721f895caee9766528e14d854b6aa2a2fac85
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-01manual: Fix copy+paste errorHarald Welte1-1/+1
Change-Id: I787c4bd4b30a6620a987efed4fd8b46e14a7ea64
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 Pedrol10-3/+33
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 Pedrol6-14/+133
Related: OS#4244 Change-Id: I6bff440b7797e710bca5af94fae546e5d55e6972
2019-11-13Fix some typosMartin Hauke48-88/+88
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 Yanitskiy3-0/+63
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-31gsm_data.h: Remove unused func declarationsPau Espin Pedrol1-3/+0
Change-Id: I189d34b6db78de749e1901733d0df35411e0d583
generated by cgit v1.2.3 (git 2.25.1) at 2024-09-22 22:48:59 +0000