path: root/openbsc/src/libbsc
AgeCommit message (Collapse)AuthorFilesLines
2019-08-05Remove undefined param passed to {logging,osmo_stats}_vty_add_cmdsPau Espin Pedrol1-1/+1
Since March 15th 2017, libosmocore API logging_vty_add_cmds() had its parameter removed (c65c5b4ea075ef6cef11fff9442ae0b15c1d6af7). However, definition in C file doesn't contain "(void)", which means number of parameters is undefined and thus compiler doesn't complain. Let's remove parameters from all callers before enforcing "(void)" on it. API osmo_stats_vty_add_cmds never had a param list but has seem problem (no "void"), so some users decided to pass a parameter to it. Change-Id: I7d9d477b983b0d62f01237d90acaa7ce455c3c3d Related: OS#4138
2018-08-28Fix heap-use-after-free due to OML link destructionPau Espin Pedrol2-2/+28
Back-port from osmo-bsc.git 9862bcb5cdb9ece0acfdfb7c81e00c05fcd33ad3. ipaccess_drop_oml was being called inside an osmo_fd cb context, were -EBADF must be returned if the structure holding the osmo_fd is freed. In the middle of the path (see OS#3495 for path tree) it goes through a signal dispatch, so it's impossible to make sure we return some value to the osmo_fd cb. As a result, it is required to defer dropping the OML Link from current code path and do it through a timer. Fixes following ASan report: 20180822124927913 <0004> abis_nm.c:787 OC=RADIO-CARRIER(02) INST=(00,00,ff): CHANGE ADMINISTRATIVE STATE NACK CAUSE=Message cannot be performed 20180822124927913 <0004> osmo_bsc_main.c:186 Got CHANGE ADMINISTRATIVE STATE NACK going to drop the OML links. 20180822124927913 <0015> bts_ipaccess_nanobts.c:406 (bts=0) Dropping OML link. ... ================================================================= ==17607==ERROR: AddressSanitizer: heap-use-after-free on address 0x62e000060a68 at pc 0x7f5ea8e27086 bp 0x7ffde92b6d80 sp 0x7ffde92b6d78 READ of size 8 at 0x62e000060a68 thread T0 #0 0x7f5ea8e27085 in handle_ts1_write input/ipaccess.c:371 #1 0x7f5ea8e27085 in ipaccess_fd_cb input/ipaccess.c:391 #2 0x7f5ea9147ca8 in osmo_fd_disp_fds libosmocore/src/select.c:217 #3 0x7f5ea9147ca8 in osmo_select_main libosmocore/src/select.c:257 #4 0x555813ab79d6 in main osmo-bsc/osmo_bsc_main.c:922 #5 0x7f5ea76d02e0 in __libc_start_main (/lib/x86_64-linux-gnu/ #6 0x555813ab84e9 in _start (/bin/osmo-bsc+0x34d4e9) Fixes: OS#3495 Change-Id: If9e73a3251547625a2372d58f1d8b87210d9f312
2018-08-28abis_nm_ipaccess_rsl_connect: Log bts and trx nrPau Espin Pedrol1-2/+2
Back-port from osmo-bsc.git 24f2f55132f7230e387aef85612dcd6fc59cebe5. Change-Id: I134a3da3700381043bc93aed300ce4ec263e8698
2018-06-13chan_alloc: Fix crash when failing to allocate channelPau Espin Pedrol1-1/+1
Fix a really silly bug I introduced recently (same commit in osmo-bsc.git doesn't contain the issue). Fixes: d05d05b2773a1dc96a51104034942d504f2b1166 Related: SYS#4254 Change-Id: I7bac2ce001d4a6dcea2a896af30edf84942b68de
2018-05-30abis_rsl: rsl_rx_chan_rqd: Format bts log string as in everywhere elsePau Espin Pedrol1-2/+2
Change-Id: I2c0db366caef5632d4e04feeda1f83e79a58995f
2018-05-30chan_alloc: Print bts nr on chan alloc failurePau Espin Pedrol1-2/+2
Change-Id: I51bb656b5fef3247edc63477f391c954c4b28f56
2018-05-28acc_ramp: Increase log level of some messagesPau Espin Pedrol1-5/+4
Right now, it's impossible to see any ACC Ramping information unless RSL category is set to DEBUG. Barring and Allowing Access Control Class is an important event which should be printed in most cases. Increase log levels of messages printed during some error conditions to be handled as errors. Backport of osmo-bsc.git commit 67f20bc356a4908bdb71b5dfc6a1932e6c1fac68. Change-Id: Iec10c2be7aa5efeadd6b0706916678acc5461111
2018-04-19chan_alloc.c: Fix log var formatting issuesPau Espin Pedrol1-2/+2
Backport from osmo-bsc.git Change-Id I7a5e5d26f250f954853c12cfd4de08fed68c178e. Change-Id: Id2ed51eed42e9fd9c91d257c245f7bce8d568f3a
2018-04-16fix handling of state changes in acc rampingStefan Sperling3-36/+112
Take both the operative and administrative states into account when deciding whether to start ACC ramping, and examine old/new state values to avoid triggering ramping for a no-op state change. This requires a fix to gsm_trx_lock_rf(): This function overwrote the old administrative state of a trx before enqueuing a state change request towards the BTS. The BTS will confirm this request with an ACK, at which time a signal is generated which the ACC ramp code listens to. We must not overwrite the old state value until the signal has been handled, otherwise the signal handler cannot tell what the old state was. Tested with a virtphy setup, nanobts, and osmo-bts. This is a port of osmo-bsc commit cda994edb20d24032d6ab4e916d0e9411671cfc0 Change-Id: I235d2c5fa962f2f338e77d0c11502921b37f4c36 Related: OS#2591
2018-04-16only trigger acc ramping if trx 0 is usable and unlockedStefan Sperling1-4/+9
Starting an ACC ramping process while TRX 0 is unusable or locked is pointless. For instance, after loading a config with 'rf_locked 1' for trx 0, the ramping process was started as soon as the BTS established RSL, even though the air interface was still down. ACC ramping should instead be triggered once TRX 0 is unlocked. This is a port of osmo-bsc commit 4d3d2436cdf3296ddc110be4022dc2ec13d3eb86 Related: OS#2591 Change-Id: I2cc9c1b8193546ea04ea5beb3751c2206f0215f2
2018-04-16trigger acc ramping on state-changed-event reportsStefan Sperling1-2/+10
Trigger ACC ramping not only when an Administrative State Change ACK is received from a BTS, but also when an administrative state change is reported for TRX 0 in a State Changed Event Report. This should allow ACC ramping to work with any BTS which reports an administrative state change to 'unlock' using either of these OML messages. Tested with a sysmobts and a nanobts. The sysmobts only reports TRX locked/unlock changes in Administrative State Change ACKs, not via State Changed Event Reports. The nanobts is known to send both of these OML messages in quick succession, so do not re-trigger ramping if it's already in progress. This is a port of osmo-bsc commit b06c7a253752ecb67fd20cdf0b069688b561af0e Change-Id: I6443635b822b6cd776f6dc8a6ee73ab09e865b04 Related: OS#2591
2018-04-16rename helper functions in the acc ramp code to avoid confusionStefan Sperling1-13/+13
The word 'enabled' was used in two contexts: Whether ACC ramp is enabled as a feature, and whether a particular access control class is permantly allowed/disallowed via VTY configuration. Rename some helper functions to avoid the use of the word 'enabled' in the latter context. This is a port of osmo-bsc commit 0ad90b39b9e638b5e3d926c9261d26e777ca478c Change-Id: Ic1e5a1f969823cfbfb9fe9e959db87c1717c3a83 Related: OS#2591
2018-04-16trigger acc ramping based on trx rf-locked stateStefan Sperling2-1/+49
Make ACC ramping listen to network management signals and trigger or abort ACC ramping based on the RF locked state of TRX 0. This is a port of osmo-bsc commit 60ecdeffecf3db4ad044c5ee0185f384d1b16eb3 Change-Id: I4124f1da3dadec003de45c1da8435506ee8f0a34
2018-04-16ensure that acc_ramp_init() is only called onceStefan Sperling3-33/+29
There are plans to register signal handlers in acc_ramp_init(). Once we do that, the acc_ramp_init() function should only be called once to avoid duplicate signal handlers on the handler list. However, the acc_ramp_init() function currently serves a dual-purpose: 1) Initialize the acc_ramp structure for a bts 2) Enable or disable ACC ramping Add new functions to support use case 2, and call acc_ramp_init() just once while reading the configuration file. The VTY commands which enable/disable ACC ramping use the new APIs instead. Also, rename acc_ramp_start() to acc_ramp_trigger() and tweak its semantics so that it can always be called regardless of what the current configuration settings are. This prepares us for triggering ACC ramping upon events other than "RSL link-up". This is a port of osmo-bsc commit ea33341cf7b52d432be98f2280b4a5f3129ef667. Also remove a call to acc_ramp_init() which should have been removed in openbsc commit ebc1e39d919f5f919cb176ee9c6cbbccc8d620b1 Change-Id: Iadd25016e6478a9dc5da1db42e6192ce0f5cc746 Related: OS2591
2018-04-16only log actual access control class ramping changesStefan Sperling1-2/+4
Silence log messages about no-op changes to access granted to access control classes. For example, these always occur while configuration files are being loaded. This is a port of osmo-bsc commit 53d40e078e9df20103b7ed26daa936720c9dec83 Related: OS#2591 Change-Id: I2f892b998eb8119e623c1d87ffe865b48f7d5a87
2018-04-11libbsc: set_net_mcc_mnc_apply: Fix memleak on parsing incorrect mcc mncPau Espin Pedrol1-0/+2
Change-Id: I507b0eced7d86f8e978012f6c19f728cd481196b
2018-04-09fix initialization of acc rampingStefan Sperling1-4/+4
Remove a redundant call to acc_ramp_init() during bootstrap_bts(). ACC ramping state is already initialized during VTY config parsing, and bootstrap_bts() accidentally disabled ACC ramping again even if it was enabled in the configuration. This bug was introduced in last-minute refactoring during review of when the acc_ramping_enabled flag was moved from struct gsm_bts to the acc_ramp structure itself. Also remove an acc_ramp_init() call in bootstrap_rsl(). It is no longer needed as it serves no purpose other than initializing the bitmasks of barred ACCs. To ensure that ACC ramping configuration provided to the BTS via system information stays correct, we move the call to acc_ramp_start(), which has the same effect on barred ACCs, further up. Port of osmo-bsc commit f34fb4828249eab44b4515e0e54b3ee0491d0051 Fixes: 8469818e33ef81e9f707a0c4dd13d7b91ecf83f5 Related: OS#2591 Change-Id: I5834fd953e65b8453dee0a7751d5a4cae12be83a
2018-04-09fix a format string error in bts_update_t3122_chan_load()Stefan Sperling1-1/+2
In a debug log message, an unsigned 64-bit value was printed with %lu but it should be printed with PRIu64 from inttypes.h instead. Port of osmo-bsc commit 5b6aa650f1a6df22ec99797bd3635ea791998a88 Change-Id: Ia29feec023117734e4f50ae3487871e715821fed
2018-03-27bsc: paging: Fix losing paging messages for BTSPau Espin Pedrol1-5/+5
Since eb241aa1d5720a36cf97f29390c2890cf3aecba7 (year 2010) we are delaying transmission of paging packets 500ms in order to avoid crashing the nanobts because of sending too many packets. In consequence, if 2 BSSMAP PAGING messages arrived in less than 500ms, since the 1st one was already in the queue, when 2nd one was handled then paging_request_bts would return -EEXIST (negative value) and paging_request_stop was called which would remove the paging in the queue. As a result, the paging would be lost unless a new 3rd BSSMAP PAGING message would arrive after this second one (which of course could be again removed by a 4th sent less than 500ms afterwards), and so on. Furthermore, it doesn't make sense to call stop_paging in here, so the easy fix is to remove it to avoid the issue mentioned above. Change-Id: I2605367b2735b48bce2b31504c444360b5ca6953
2018-03-27bsc: Improve handling of paging_request return valuePau Espin Pedrol1-0/+3
Detail better in the API documentation what's the expected return value for paging_request. Change-Id: I17fa3b549bff297531b2777d658b0e0112a3031f
2018-03-22backport support for 3-digit MNC with leading zerosneels/mnc3Neels Hofmeyr6-52/+100
Backport the patches with the following change-ids: osmo-bsc.git: I5b097dbb6329f284e3b4914a744d5c3ad628f715 I8e722103344186fde118b26d8353db95a4581daa I78f30aef7aa224b2e9db54c3a844d8f520b3aee0 I38ac98a4d25159cfd4f686efbfbaf8f00625a6d8 osmo-iuh.git: I29ebcddd45fe3079f8883589a83cc7216a535475 Also apply change of ipac_bcch_info.cgi to struct osmo_cell_global_id in src/ipaccess/network_listen.c, a change that appears to not have been necessary in the new split repositories. Related: OS#3010 Change-Id: Ibf50fd7e1ca5472d0a38fcb87c68227d6de44f42
2018-03-14Add support for Access Control Class ramping.Stefan Sperling6-3/+378
Access Control Class (ACC) ramping is used to slowly make the cell available to an increasing number of MS. This avoids overload at startup time in cases where a lot of MS would discover the new cell and try to connect to it all at once. Ramping behaviour can be configured with new VTY commands: [no] access-control-class-ramping access-control-class-ramping-step-interval (<30-600>|dynamic) access-control-class-ramping-step-size (<1-10>) (The minimum and maximum values for these parameters are hard-coded, but could be changed if they are found to be inadequate.) The VTY command 'show bts' has been extended to display the current ACC ramping configuration. By default, ACC ramping is disabled. When enabled, the default behaviour is to enable one ACC per ramping step with a 'dynamic' step interval. This means the ramping interval (time between steps) is scaled to the channel load average of the BTS, i.e. the number of used vs. available channels measured over a certain amount of time. Below is an example of debug log output with ACC ramping enabled, while many 'mobile' programs are concurrently trying to connect to the network via an osmo-bts-virtual BTS. Initially, all ACCs are barred, and then only one class is allowed. Then the current BTS channel load average is consulted for scheduling the next ramping step. While the channel load average is low, ramping proceeds faster, and while it is is high, ramping proceeds slower: (bts=0) ACC RAMP: barring Access Control Class 0 (bts=0) ACC RAMP: barring Access Control Class 1 (bts=0) ACC RAMP: barring Access Control Class 2 (bts=0) ACC RAMP: barring Access Control Class 3 (bts=0) ACC RAMP: barring Access Control Class 4 (bts=0) ACC RAMP: barring Access Control Class 5 (bts=0) ACC RAMP: barring Access Control Class 6 (bts=0) ACC RAMP: barring Access Control Class 7 (bts=0) ACC RAMP: barring Access Control Class 8 (bts=0) ACC RAMP: barring Access Control Class 9 (bts=0) ACC RAMP: allowing Access Control Class 0 (bts=0) ACC RAMP: step interval set to 30 seconds based on 0% channel load average (bts=0) ACC RAMP: allowing Access Control Class 1 (bts=0) ACC RAMP: step interval set to 354 seconds based on 59% channel load average (bts=0) ACC RAMP: allowing Access Control Class 2 (bts=0) ACC RAMP: step interval set to 30 seconds based on 0% channel load average (bts=0) ACC RAMP: allowing Access Control Class 3 (bts=0) ACC RAMP: step interval set to 30 seconds based on 0% channel load average Port of osmo-bsc commit a5c1e8727c391bc56847a00b2ecc08787573b91f Change-Id: Idd5c4fd7ea2e10086d9b26deee3a71f9469d1280 Related: OS#2591
2018-03-14Add stat items for the BTS's channel load average and T3122.Stefan Sperling1-0/+3
In addition to logging the current values of a BTS's channel load average and T3122 override, maintain stat items for these values. This allows for plotting these values over time, for instance. These values show up in the VTY under 'show stats' like this: base transceiver station: Channel load average.: 25 % T3122 IMMEDIATE ASSIGNMENT REJECT wait indicator.: 32 s Port of osmo-bsc commit 4e9d40db2f86bfbd4d9c8bf9e3d9196f5ddf22c6 Change-Id: I766bd51f539dd96236b9c81d661e9d31f5027db4
2018-03-14bts chan_load: ignore unusable BTSStefan Sperling1-0/+5
For unconnected BTS, the channel load would report a "bogus channel load sample" every second (on RLL debug). Instead, skip unusable BTS. This follows up on commit 6cee893a0f2c4e53155a2631aff12a5f615b973d / I57e38f6d6ba3b23cc6e1f9520b90261dbb1f1cec 'Make "waiting indicator" of IMMEDIATE ASSIGN REJECT dynamic.' Port of omo-bsc commit f802f7fd7aec1d91084231a80bbce6f2ed7bd299 Change-Id: Icd50d101244641a6ffdde17e60d7a89719225c65
2018-03-14Make "waiting indicator" of IMMEDIATE ASSIGN REJECT dynamic.Stefan Sperling5-19/+122
The IMMEDIATE ASSIGN REJECT message contains a wait indicator which tells an MS requesting a channel to wait for a specified amount of time before trying to request a channel again, i.e. the wait indicator controls the T3122 timeout value in the MS. Previously, the wait indicator was fixed to 10 seconds. This is not sufficient if there are a lot of MS requesting channels because the MS will retry too soon. Instead of using a fixed value, maintain a dynamic wait indicator value based on average channel load. The load (used vs. available channels on a BTS) is sampled once per second, and once 8 samples have been collected we update a BTS-specific T3122 wait indicator based on the measured load. While the wait indicator could go up to 255 seconds, this initial implementation keeps it in the range from 10 to 128 seconds. Further experimentation and testing will show whether higher wait indicator values are desirable, if the sampling rate needs to change, or if the function mapping the load measurement to a wait indicator value should change (currently we map the load average linearly into the range [10, 128] inclusive). Port of osmo-bsc commit 6cee893a0f2c4e53155a2631aff12a5f615b973d Change-Id: Id9df0e790ece8108212b2ddf718cf2953f5b9bd4 Related: OS#2592
2018-03-12sysinfo: Fix regression causing missing L2 Pseudo-Length in SI5/SI6Harald Welte1-5/+5
Fixes a regression in the code generating SI5* and SI6 on SACCH, where the L2 pseudo-length is not part of the 'struct' definition we have in gsm_04_08.h and hence has to be encoded manually into the first byte of the SI buffer. We were doing this correctly until April 2017, when the following patch was merged: > commit 6f0e50c8337355eb59033903ede9ab6528890835 > Author: Max <> > Date: Wed Apr 12 15:30:54 2017 +0200 > > Prepare for extended SI2quater support This patch cacidentially overwrote the l2_plen that was just enoded, as the 'struct' was no longer pointing to 'output' (si_buf+1), but now directly to the start of the si_buf. NOTE: The Wireshark RSL dissector (and more recently also LAPDm) contain a similar bug, so the SACCH will not be decoded correctly after applying this patch. Nevertheless, it's correct. back-port of OsmoBSC Change-Id: Ie8c907b1317566670aeb68f933ceefd552c17565 Closes: #3059 Related: #2963 Change-Id: Iaf5feefc1bb3194dd491955fee418795c61787f7
2017-11-27vty: Add cmd to configure 3g Early Classmark SendingPau Espin Pedrol3-3/+30
In state prior to this patch, "3G Early Classmark Sending Restriction" bit in SI3 rest octets was always set to H, which is a sane default as the policy to send the information is then controlled by "Early Classmark Sending Control" bit in the same octet. However, it seems Quortus SoftCore can have some issues decoding the option, so let's add a vty cmd to be able to disable it for those having any issues. Related: SYS#4021 Change-Id: Ic1afe071038a3bb5871d7ff40f665c8644f801ec
2017-11-27Use type bool for boolean fields in gsm48_si_ro_infoPau Espin Pedrol1-7/+7
Change-Id: Ic0981fca96f4927717ca335be1dab00a5d17fd6c
2017-11-01vty: skip installing cmds now always installed by defaultNeels Hofmeyr3-6/+0
vty_install_default() and install_default() will soon be deprecated. Depends: I5021c64a787b63314e0f2f1cba0b8fc7bff4f09b Change-Id: I4951982fc78ae167d8e16a672d7af44d703721a9
2017-10-23Make TRX rf locking more visibleMax3-7/+11
* log administrative state transitions * log what's caused it * while at it, mark boolean variable as such Cherry-picked from osmo-bsc be356ed32fbd28dc8d1460371d9e47511b20ac63 Change-Id: I3e25a19fac4d0b4886d825c9876771b1f66efe58 Related: SYS#3864
2017-10-23libbsc: Use correct printf formatting for uint64_tPau Espin Pedrol1-4/+4
unsigned long can be 32 bits on some arch/OS, while "current" field is always 64 bit because it's a uint64_t. Change-Id: I9719c69ef661bb46d8bb43cf8d6537c3e8d47826
2017-10-17bsc_api: Fix NULL secondary_lchan access in handle_ass_failPau Espin Pedrol1-2/+4
Related: OW#3893 Program terminated with signal SIGSEGV, Segmentation fault. 0 gsm_lchan_name (lchan=lchan@entry=0x0) at gsm_data_shared.c:342 (gdb) bt 0 gsm_lchan_name (lchan=lchan@entry=0x0) at gsm_data_shared.c:342 1 0x0805ab80 in lchan_release (lchan=0x0, sacch_deact=sacch_deact@entry=0, mode=mode@entry=RSL_REL_LOCAL_END) at chan_alloc.c:410 2 0x0805c1dd in handle_ass_fail (msg=0x94142b8, conn=0x9251048) at bsc_api.c:459 3 dispatch_dtap (msg=0x94142b8, link_id=0 '\000', conn=0x9251048) at bsc_api.c:598 4 gsm0408_rcvmsg (msg=msg@entry=0x94142b8, link_id=0 '\000') at bsc_api.c:658 5 0x08058ca2 in abis_rsl_rx_rll (msg=0x94142b8) at abis_rsl.c:1686 6 abis_rsl_rcvmsg (msg=0x94142b8) at abis_rsl.c:2097 7 0xb7e8cf9a in handle_ts1_read (bfd=0x94e8e08) at input/ipaccess.c:271 8 ipaccess_fd_cb (bfd=0x94e8e08, what=1) at input/ipaccess.c:386 9 0xb7ee8434 in osmo_select_main (polling=polling@entry=0) at select.c:158 10 0x0804bd7c in main (argc=6, argv=0xbfc27144) at osmo_bsc_main.c:272 (gdb) print lchan $2 = (const struct gsm_lchan *) 0x0 Possible scenario in which this crash can appear: 1- gsm0808_assign_req() calls handle_new_assignment() which sends an CHAN ACTIVATE msg and arms T10 timer. 2- ACTIVATE ACK is received (handle_chan_ack), which calls gsm48_send_rr_ass_cmd() which sends an ASSIGNMENT CMD, and doesn't disable/modify T10 timer. 3- T10 timeout is triggered (assignment_t10_timeout()), which sets conn->secondary_lchan = NULL 4- Immediately after, the ASSIGNMENT FAILURE message (which might have been already queued) is processed in handle_ass_fail, and then the crash occurs. This race condition is not an issue for handle_ass_compl() path because there's this check there which would trigger most probably if secondary_lchan is NULL: "if (conn->secondary_lchan != msg->lchan)" Change-Id: Ied5bd90b9c06f27135a2e3c46e40d49d27d9a387
2017-10-01Make sure BA-IND in all SI2xxx is '0' and in all SI5xxx is '1'Harald Welte2-3/+21
In masurement reports sent by the MS, this can then be used to correlate if a given measurement report was in response to a BCCH/neighbor list received on BCCH (SI2xxx) or on dowlink SACCH (SI5xxx). Closes: OS#2525 Change-Id: I1cd0dc51026dcd0e508e63eea4e333e6b184787a
2017-10-01libbsc: document arguments of generate_bcch_chan_list()Harald Welte1-1/+7
Change-Id: I5afc6e6a5a1d6b6a8ee73fdb60cc28074cf8585b
2017-09-27Show OML link uptime in vtyMax3-3/+29
Save the time when OML link to BTS was established and show it in vty. That's useful when troubleshooting issues like periodic/sporadic BTS restart. Related: SYS#3889 Change-Id: I9e4e8504afe8ca467b68d41826f61654e24d9600
2017-09-04handover_decision: Fix condition for power budget handover attemptIvan Kluchnikov1-1/+1
Handover attempt for power budget case should be performed every N SACCH frames, where N = Power Budget Interval. First measurement report with mr->nr = 0 was used for the first handover attempt in this case, which is not correct, because first usable report should have mr->nr = net->handover.pwr_interval-1. Moreover using the first measurement report with mr->nr = 0 for handover attempt could lead to unnecessary handover, because usually av_rxlev for first measurement report from MS is worse than for following reports. Change-Id: If7f54a4cb179eaa9e5eb147b9477633ac618e69e
2017-08-30SI13: drop PBCCH-related bitsMax2-44/+16
According to 3GPP TS 44.018 §1.8 the "network shall never enable PBCCH and PCCCH". Change-Id: I319e71a4b0c682361529e9c21377398a826b934b Related: OS#2400
2017-08-14Fix gsm_pchan2chan_nr() to use RSL_CHAN_OSMO_PDCHHarald Welte1-1/+1
When converting from GSM_PCHAN_PDCH, we should generate a RSL channel number IE with the osmocom extension RSL_CHAN_OSMO_PDCH rather than claiming it is a regular TCH/F channel. This is important as this function is used by osmo-bts, too - and it decides which channel number IE is put in the GSMTAP header for both GSMTAP tracing as well as the GSMTAP based osmo-bts-virtual. In order to avoid any unintended effect on libbsc, we make sure to modify rsl_ipacc_pdch_activate() to always use GSM_PCHAN_TCH_F in related RSL message. Change-Id: Ie34219e64a6d89da4a79f2db8ec73d1909fb8280
2017-08-13handover_logic: set correct link to bts for subscriber_connection in case of ↵Ivan Kluchnikov1-0/+1
moving this connection to another bts In case of successful completion of handover gsm_subscriber_connection could be moved from one bts to another, so connection link to bts should be replaced by link to bts, which owns new_lchan. This bug was detected, because conn->bts->nr is used in call control log messages and wrong number of bts was observed in these messages after handover. Change-Id: Idc7dd412b7580c451e716b73ef7549826c60b0d9
2017-08-09timer vty: also print the default value in cmd docNeels Hofmeyr1-13/+13
Rationale: allows seeing all timer defaults at once by doing OsmoBSC(config-net)# timer ? Before, defaults are visible only by doing on each timer: OsmoBSC(config-net)# timer t1234 <tab> Change-Id: I8259234e5c62e058dde56d531071440bbab11462
2017-08-09vty: add 'default' keyword to timer configNeels Hofmeyr1-3/+14
Change-Id: I4e837e8bedfad7ac4fd50048ecb016ddb37c2397
2017-08-09cosmetic: vty for timers: remove obsolete range checkNeels Hofmeyr1-6/+0
The VTY parsing already ensures the parameter range being 1..65535, no need to check the range again. Change-Id: I1cffa5b01cd5c589f1e42998e32135f1da8c960b
2017-07-20remove code disabling T3109 if configured to 0Harald Welte1-4/+0
We no longer permit timers with a 0 value, so this case can never happen. Also, if it should happen, I'd rather have a timter expiring immediately (and breaking something) than not being started in the first place. Change-Id: Ibfcdd3ddc0155caee89c501498329bde247621a0
2017-07-20bsc_vty: Don't allow timers of zero (0)Harald Welte1-2/+2
It typically doesn't make sense to configure any of the GSM RR timer to 0 (Seconds). In fact, accidentially configuring any of the timers to zero might have severe side effects, such as "stuck channels" described in Change-Id: I517828f2f0c80ec01cb63648db2626f17a67fe57
2017-07-20GSM timers: User reasonable defaults; don't save if equal defaultHarald Welte2-13/+25
A number of the GSM timers (including T3109) had no reasonable default values if not specified in the VTY / config file. Together with unconditional writing to the config file, this created config files with a persistent setting for important timers as '0'. To make things worse, many of our example cofig files suffered from the same problem. Let's avoid this from happening by * having reasonable defaults if nothing specified in the config file * conditionally savingg timers only if they differ from default * reject any timer values that state zero during start-up (see previous commit) Change-Id: Iaac0bfca423852b61d8b9eb1438157ef00d0d8c8 Closes: OS#2380
2017-07-19bsc_vty: Add VTY command to test CTRL TRAP featureHarald Welte1-0/+16
Using this new command (introduced in OsmoBSC + OsmoNITB), you can simulate the generation of TRAP events for testin purposes. start the control interface monitor as an example client program: ./openbsc/contrib/ -m -d localhost -p 4249 then start OsmoBSC or OsmoNITB, telnet to the VTY and enter 'enable' mode and issue the following (example) command: ctrl-interface generate-trap 2342 As a result, on the you will see: Got message: TRAP 0 2342 Change-Id: Ib1d2ec38290dc94797c1b365d9b733e5215ab7d1
2017-07-16gsm_bts_trx_set_system_infos(): Disable non-existing SIHarald Welte1-6/+17
If we previously had a given SI present/active, we must send a zero-length BCCH FILLING for that SI type to the BTS to stop it from further transmitting this SI. Change-Id: I33e356e2fa3a69efac9080813e3e9ef4e6438ed1 Closes: OS#2368
2017-07-15RSL: Allow disabling of BCCH/SACCH filling for given SI typeHarald Welte1-4/+8
If we want to instruct the BTS to stop sending a given SI, we must be able to send the respective BCCH INFO / SACCH FILLING with a header but without any L3 data IE. This patch enables the related functions to do this whenever their data argument points to NULL. Change-Id: I88b85614951a108574f05db3b706884afe7e87a9
2017-07-15Fix regression causing loss of static system-information messagesHarald Welte1-2/+2
In commit 8b1a2f8cd7a81c6b8c7cdb0963dcf89de7c46100 we started to initialize bts->si_valid to 0. This means we are skipping the manually configured static system information. Instead, we have to initialize bts->si_valid to bts->si_mode_static, i.e. start with those that are static and not to be auto-generated. Found while developing Change-Id: Iab9cc93cf6d54560a72cc393cc3721a8d10e04bf Closes: #2367
2017-07-12check for missing result of rate_ctr_group_alloc()Harald Welte1-0/+4
In case the counter group allocation fails, we must handle this gracefully and fail the allocation of the parent object, too. RelateD: OS#2361 Change-Id: I7dad4a4d52fe05f6b990359841b4408df5990e21