aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2018-05-09rsl: Properly NACK CHAN_ACKT / MODE_MODIFYHarald Welte1-13/+17
Whenever we encounter an error condition during processing of RSL CHAN ACT or RSL MODE MODIFY, it's insufficient to simply send an RSL ERROR INDICATION, but we also must send a proper NACK back to the BSC. Change-Id: I4dd7ff2fd2cdbc6e892cd329c826ac1bc3b16bb9
2018-05-09rsl: Make channel activation fail if encryption algorithm not supportedHarald Welte1-1/+1
The code actually always *wanted* to make lchan activation fail in case we don't support the algorithm, but it failed ot do so. The problem is encr_info2lchan() which uses bts_supports_cipher() to determine if the cipher is supported. However, if bts_supports_cipher() returns 0 (not supported), it uses this value as return value of encr_info2lchan() where '0' means success (standard osmocom convention). This results in channel activation proceeding, which it shouldn't. Change-Id: I46275b8fc2a1a74f68b4cc60e0f64ba226b108cd Related: OS#3254
2018-05-09rsl: log errors when parsing of encryption information failsHarald Welte1-2/+10
... also log a DEBUG message whenever we change the lchan->encr Related: OS#3254 Change-Id: Icda7722eef319f343178b0bb8f79362026948199
2018-05-08add/improve various logging around dyn tsNeels Hofmeyr2-10/+22
This logging turned up while I was debugging dynamic timeslots: - OML Set Channel Attributes logging. - a specific dyn TS pchan error. - show pchan and lchan types on CHAN ACT ACK and REL ACK logging. - on RSL message Rx, log the current pchan kind in detail, using gsm_ts_and_pchan_name(). This logs the underlying pchan as well as the current pchan mode a dyn TS is in. - move 2 dyn TS logging from DL1C to DRSL, where all the other dyn ts logging is. Change-Id: Ia89c134060e85f7065afd5642d1c541c65dd25ea
2018-05-08ip.access dyn ts: properly NACK a PDCH ACT on a still active lchanNeels Hofmeyr1-0/+7
Fixes: BTS_Tests.TC_dyn_ipa_pdch_tchf_act_pdch_act_nack Change-Id: I12816ef9953467decd9f745217135702a544c8fc
2018-05-08fix RSL Chan Activ Nack messagesNeels Hofmeyr1-6/+4
In early rsl_rx_chan_activ(), do not use rsl_tx_chan_act_acknack() to trigger sending a NACK, instead use rsl_tx_chan_act_nack() directly. Rationale: the previously used rsl_tx_chan_act_acknack() may decide to omit the NACK, particularly based on the lchan->rel_act_kind. lchan->rel_act_kind indicates whether the Chan Release or Activation was explicitly requested via RSL, and thus whether an ACK/NACK should go back to RSL or not. This gets set only late in rsl_rx_chan_activ(). We cannot set it on top, because we need to first establish whether the Chan Activ is permitted or not. In case of early rejection of the Chan Activ, we do not want to modify the lchan state, but merely reply with a NACK, unconditionally. Before this patch, NACKs that rsl_rx_chan_activ() wants to trigger would possibly be not be sent out on RSL, because lchan->rel_act_kind is not explicitly initialized until later. Fixes: BTS_Tests.TC_dyn_ipa_pdch_act_tchf_act_nack Change-Id: Ic981f768cc024f0acd3d7ae55846cfbc7bc089ce
2018-05-08ignore RSL RF CHAN REL for inactive lchansNeels Hofmeyr1-9/+29
When an RF CHANnel RELease request is received on an already released lchan, there is no "REL NACK" message or similar, we just ACK the release. When ACKing the release, make sure to reflect the same chan_nr that the release was asked for, since the lchan state may actually reflect a different chan_nr. Factor the actual Rel Ack message sending out of rsl_tx_rf_rel_ack(), which makes all sorts of decisions around normal Rel Ack: add static tx_rf_rel_ack(), with chan_nr argument instead of deriving chan_nr from the lchan. Use this to directly ACK an unusual Chan Rel with the chan_nr that came in with the request. Fixes: BTS_Tests.TC_dyn_osmo_pdch_unsol_deact (after I6b790e866ce4e66d9385b286b727ae41a83d3e67) Change-Id: Iceaa2e87874ced42d664a2a0b01a1c59e46a19b3
2018-05-07send a State Changed Event Report when rf is locked/unlockedStefan Sperling1-1/+10
Make osmo-bts send a State Changed Event Report when RF is locked or unlocked. This behaviour isn't mentioned in the spec as far as we know, but an ipaccess nanobts also produces these messages. Change-Id: I37e44ef4881c41f8835428b610e7863f37397c9f Related: OS#3161
2018-05-05cosmetic: dyn TS: clarify chan_nr compositionNeels Hofmeyr1-4/+14
In gsm_lchan2chan_nr(), use a switch to reflect both dyn TS kinds and enrich with comments. Move GSM_PCHAN_TCH_F_PDCH out of gsm_pchan2chan_nr(), which is now back to pure standard PCHAN values. Rationale: it's easier to figure out what is going on and why. Change-Id: I6a31b44220d97c9173c52d3567a1382541710d10
2018-05-05dyn TS: clear TCH state upon reconnecting as PDCHNeels Hofmeyr1-0/+26
For ip.access style TCH/F_PDCH, this fixes switch-back to PDCH in case the TCH use employed encryption. For Osmocom style TCH/F_TCH/H_PDCH, do the same, purely out of sanity. Roughly the same should already be happening during PDCH Chan Activ, but make sure to clear all these fields, so they are cleared even if IEs are missing. From both dyn TS code paths, call new clear_lchan_for_pdch_activ(), which clears the same fields that are normally overwritten by an RSL Chan Activ. Related: OS#3238 Change-Id: I8451039683b54bee910c97c5a3e6873e0ff1b160
2018-05-05dyn TS: rx_rf_chan_rel: properly mark PDCH rel when no PCU, clarifyNeels Hofmeyr1-4/+7
When the PCU is not connected, we immediately call rsl_tx_rf_rel_ack() because we don't need to wait for a PDCH deactivation. Fix: properly mark rel_act_kind = LCHAN_REL_ACT_PCU to invoke identical behavior as when the PCU were involved. (When the PCU is connected, a PDCH release on an Osmocom style dyn TS causes an actual release of the PDCH TS, and then triggers an rsl_tx_rf_rel_ack() with rel_act_kind == LCHAN_REL_ACT_PCU.) Clarify the code flow: rc == 1 is the special case of no PCU being connected, so have that in a separate if{}. Change-Id: I654b963815b32fcbce050c2e15f3190c97bc259f
2018-05-05dyn TS: fix TCH/F_TCH/H_PDCH: properly record release of PDCH TSNeels Hofmeyr1-0/+2
When a release of PDCH is complete, actually set the dyn.pchan_is to NONE. Failure to do so currently caused errors on activation of an Osmocom style dyn TS as TCH, in the shape of: rsl.c:636 (bts=0,trx=0,ts=2,ss=0) Tx RF CHAN REL ACK rsl.c:164 (bts=0,trx=0,ts=2,pchan=TCH/F_TCH/H_PDCH switching PDCH -> NONE) RSL rx DCHAN: mismatching chan_nr=0x12 rsl.c:2611 Rx RSL CHAN_ACTIV for unknown lchan rsl.c:710 0x12: Sending Channel Activated NACK: cause = 0x64 The Tx RF CHAN REL ACK shows that we're through with PDCH release, but the following line showing "chan=TCH/F_TCH/H_PDCH switching PDCH -> NONE" shows that the state still reflects active switching. Thus the DCHAN code decides that the chan_nr = 0x12 reflecting a TCH/H on TS 2 is a mismatch and NACKs the TCH activation. (For ip.access style TCH/F_PDCH, the ts->flags are cleared in ipacc_dyn_pdch_complete()). Related: OS#3235 Change-Id: Ic06c8f0fe82ae8a06afa5defd93a685010687965
2018-05-05cosmetic: dyn TS: clarify rsl_tx_rf_rel_ack() with a switchNeels Hofmeyr1-9/+41
Use a switch statement and ample comments to clarify what is done and why. Cosmetically prepares for Ic06c8f0fe82ae8a06afa5defd93a685010687965. Related: OS#3235 Change-Id: I8a9953b011a4516972aae468754494f57ebc0a3f
2018-05-03Bump version: 0.7.0.183-c45a-dirty → 0.8.00.8.0Pau Espin Pedrol2-8/+215
Change-Id: I92b7b584beac870d1dccc9d5637fa54154b6db03
2018-04-25scheduler_trx: Fix signed integer overflow in clock calculationsPau Espin Pedrol1-2/+3
Should fix following observed run time errors: osmo-bts-trx/scheduler_trx.c:1627:65: runtime error: signed integer overflow: -1081823 * 4615 cannot be represented in type 'int' osmo-bts-trx/scheduler_trx.c:1627:21: runtime error: signed integer overflow: 1852394502 - -697645849 cannot be represented in type 'int' Related: OS#3213 Change-Id: I36e0d2d0d0c6e35e963f611135453c4a4c00bc99
2018-04-23gsm_data_shared.h: Remove unused enum gsm_paging_eventPau Espin Pedrol1-7/+0
Change-Id: I37c026f0e4d5ed6cbedaa237b259742f44c238b9
2018-04-23return NACK codes instead of errno values from oml_tx_attr_resp()Stefan Sperling1-14/+8
The caller translates errno values back into NACK codes anyway, so lets's return NACK codes directly. Change-Id: I2b1f79e66c778139d64101c89dd6377921807e2d Related: OS#2295
2018-04-19cosmetic: fix typos in src/common/oml.cStefan Sperling1-4/+4
Change-Id: I6789421497182e957341b01a37a2d9b8d367adf9 Related: OS#2295
2018-04-19respond with NACK for non-hopping BTS with multiple ARFCNStefan Sperling1-2/+1
In addition to logging an error, send a NACK if the BSC attempts to set more than one ARFCN in Radio Carrier Attributes for a BTS which does not support frequency hopping. Change-Id: Ia72e23a3f08f825cf9cf0d9a55302d13cfed51d6 Related: OS#2295
2018-04-17common/sysinfo.c: Fix no return on on-void functionPau Espin Pedrol1-0/+1
src/common/sysinfo.c:147:1: warning: control reaches end of non-void function [-Wreturn-type] } The compiler warning is actually a false positive since we call OSMO_ABORT on that path, but let's add a return anyway so the compiler doesn't throw a warning. Change-Id: I9b4e06927489a8bc20ce173279a01415a8c4295a
2018-04-17Include missing headers for osmo_init_logging2Pau Espin Pedrol4-0/+4
Fixes implicit declaration warning messages at compile time. Change-Id: I753ed49cdcbd1301ba7ea38dcea9113d99fecb06
2018-04-17osmo-bts-trx: perform error concealment for FR framesPhilipp Maier2-2/+22
When a bad voice frame is received, it is replaced by a silence frame. This may cause unpleasant audio effects. This change implements a functionality to craft a replacement frame from the last known good frame using ECU implementation from libosmocodec. At the moment, only FR is supported. Depends: libosmocore I06a21f60db01bfe1c2b838f93866fad1d53fdcd1 Change-Id: Iae9e69a9578ae305bca42f834694af96a29084e6
2018-04-09octphy: integrate octasics latest header releasePhilipp Maier4-20/+181
At the moment osmo-bts does not compile with the latest header file release from OCTSDR-2G-02.10.00-B1837-ALPHA as there are struct members removed and new ones added. The changes do not affect actual functionality in the existing code. The only affected parts are vty functions that query status information about the clock sync manager. - Add detection logic in configure.ac to detect if the affected struct members are present - Add conditional compiling to handle the different combinations of available struct members. Change-Id: Ic38d8dc35522205c4ffab583b4e61b5ef03cdba2 Related: SYS#4139 Patch-by: Octasic inc.
2018-04-06contrib: jenkins_bts_model: Fix bashism exprPau Espin Pedrol1-1/+1
In posix shell, = is valid and == is not. Change-Id: I5c027039d12c5e455a8f8a0878f88ab30c168db4
2018-04-05fix activation of osmocom-style dynamic PDCH as TCH/F or TCH/HHarald Welte1-0/+2
in change-id Iebd2571726d1284a7431b3f9b23ad3185e832ed1 we introduced tighter validation on whether the requested channel number matches the underlying physical channel configuration. Unfortunately this broke activation of an osmocom-style dynamic PDCH as TCH/F or TCH/H rsl_lchan_lookup already permitted a chan_nr if the dynamic PDCH was already switched to the given TCH mode, or at least the related switching had already been initiated. However, in the case of the bug, the current type is NONE, which means that the compatibility check of rsl_lchan_lookup will fail Let's relax the checks of rsl_lchan_lookup() slightly to permit matching for "ts->dyn.pchan_is == GSM_PCHAN_NONE" cases. This fixes BTS_Tests.TC_dyn_osmo_pdch_tchh_act and BTS_Tests.TC_dyn_osmo_pdch_tchf_act Change-Id: I14ae4c4ed2aae0966e5cb5116cf024d6bd890237 Related: OS#3134
2018-04-05rsl_tx_dyn_pdch_ack: Add missing FRAME_NR information elementHarald Welte1-4/+7
It seems that the IPA PDCH ACT ACK contains not only the channel number, but also the frame number. Let's make sure we're as close as possible to other implementations to ensure maximum interoperability. Change-Id: Ibe7988e9ef374e8c7d9429777fb32322d90c2024
2018-04-05fox chan_nr_is_dchan() for RSL_CHAN_OSMO_PDCHHarald Welte1-2/+2
When writing chan_nr_is_dchan() in Change-Id: I43a78bec63aeb36dd67043d237b27fe880209349, I apparently only looked at TS 48.058 without considering the osmocom extension to it for PDCH activation. The result is complete breakage for "osmocom style dynamic PDCH" support. This patch fixes the mistake by making the compare more specific. Change-Id: I18e0774fdd48966bc95261e715f798464b8b681f Related: OS#3131, OS#1853
2018-04-04use osmo_init_logging2() with proper talloc ctxNeels Hofmeyr15-40/+23
Completely drop bts_log_init(), call osmo_init_logging2() directly instead: all callers of bts_log_init() passed NULL as category string, so all it ever did was call osmo_init_logging(). The bts_log_info is already declared in the .h. Here and there also define a proper talloc root context instead of using NULL. Change-Id: Ic049f77bef74123b95350bcae182a468e0086b9c
2018-04-03osmo-bts-sysmo eeprom.c Restore ability to read/write EEPROMKeith1-6/+7
This commit restores ability to read write to the SuperFemto EEPROM. Use offsetof() instead of casts to pointers when calculating the address to pass to eeprom_read() and eeprom_write() Fixes: 7cf144b27d75fadfb4ec65019985bb10660a066a Change-Id: Iaa7318387ad7bb248c261b1f428019244039e7d2
2018-03-23cosmetic: remove unused variable in osmo-bts-omldummy/main.cPhilipp Maier1-1/+1
Change-Id: I85d8c77589eae511f47b8b9b7439a2c47fe350d8
2018-03-23cosmetic: remove unused variablePhilipp Maier1-1/+0
Change-Id: Icbec00ec63950b785dcb71e3b9d70541e70be536
2018-03-23cosmetic: remove dead codePhilipp Maier1-8/+0
Patch by Octasic inc. Change-Id: I40ff0b95349308693bec5f4ae56ec7f2f14202e5
2018-03-21l1sap: Avoid assumption that l1sap is at head of msgbPau Espin Pedrol1-11/+15
This assumption used while sending the rx data to gsmtap in l1sap_up was making osmo-bts-virtual crash, since that bts model is allocating the l1sap in the stack rather than inside the msgb. Instead, let's use the assumption that l2h is set correctly in msgb by the bts model lower layer. crash report: Program received signal SIGSEGV, Segmentation fault. 0x00007ffff6234ec3 in __memmove_sse2_unaligned_erms () from /usr/lib/libc.so.6 (gdb) bt 0 0x00007ffff6234ec3 in __memmove_sse2_unaligned_erms () from /usr/lib/libc.so.6 1 0x00007ffff6dbf4c8 in gsmtap_makemsg_ex (type=<optimized out>, arfcn=arfcn@entry=17255, ts=ts@entry=6 '\006', chan_type=<optimized out>, ss=ss@entry=0 '\000', fn=fn@entry=11249, signal_dbm=0 '\000', snr=0 '\000', data=0x5555557d5b50 "", len=4294967263) at libosmocore/src/gsmtap_util.c:179 2 0x00007ffff6dbf6d8 in gsmtap_send_ex (gti=0x555555877f10, type=type@entry=1 '\001', arfcn=arfcn@entry=17255, ts=ts@entry=6 '\006', chan_type=<optimized out>, ss=<optimized out>, fn=11249, signal_dbm=0 '\000', snr=0 '\000', data=0x5555557d5b50 "", len=4294967263) at libosmocore/src/gsmtap_util.c:311 3 0x00007ffff6dbf765 in gsmtap_send (gti=<optimized out>, arfcn=arfcn@entry=17255, ts=ts@entry=6 '\006', chan_type=<optimized out>, ss=<optimized out>, fn=fn@entry=11249, signal_dbm=0 '\000', snr=0 '\000', data=0x5555557d5b50 "", len=4294967263) at libosmocore/src/gsmtap_util.c:330 4 0x0000555555573571 in to_gsmtap (trx=0x7ffff7ef8070, l1sap=0x7fffffffde80) at osmo-bts/src/common/l1sap.c:397 5 0x0000555555573b9c in l1sap_up (trx=0x7ffff7ef8070, l1sap=l1sap@entry=0x7fffffffde80) at osmo-bts/src/common/l1sap.c:1285 6 0x000055555555ec06 in virt_um_rcv_cb (vui=<optimized out>, msg=<optimized out>) at osmo-bts/src/osmo-bts-virtual/l1_if.c:170 7 0x000055555555f5c6 in virt_um_fd_cb (ofd=0x55555587cc30, what=<optimized out>) at osmo-bts/src/osmo-bts-virtual/virtual_um.c:50 8 0x00007ffff6db6991 in osmo_fd_disp_fds (_eset=0x7fffffffe090, _wset=0x7fffffffe010, _rset=0x7fffffffdf90) at libosmocore/src/select.c:216 9 osmo_select_main (polling=polling@entry=0) at libosmocore/src/select.c:256 10 0x0000555555576fbc in bts_main (argc=5, argv=0x7fffffffe288) at osmo-bts/src/common/main.c:364 11 0x00007ffff61b5f4a in __libc_start_main () from /usr/lib/libc.so.6 12 0x000055555555c4ca in _start () In the old code when the sizeof(osmo_phsap_prim) was being substracted it resulted on a negative len which later was casted to unsigned int and became a really big number. Fixes: OS#3092 Change-Id: I51a880328497673a06d153bfb76c428265b8cbb8
2018-03-17debian: Split osmo-bts-virtual from osmo-bts-trxHarald Welte4-1/+24
osmo-bts-virtual also contains osmo-bts-omldummy Change-Id: I1c88ed2f7111a6c061ac5721af8f09d9aca4a156
2018-03-17omldummy: Suppress RSL transmission errorsHarald Welte1-0/+7
In omldummy, we don't have a RSL link and hence any transmission attempts to RSL should silently go to /dev/null rather than printing error messages via libosmo-abis. So check for the OMLDUMMY variant and silently discard any RSL message that the code may want to transmit. Change-Id: I04a9ec7e416822cc1e45c533e6a66628689615ad
2018-03-17fix inverted logic bug in omldummy patchHarald Welte1-1/+1
Change-Id: Ic2e7e78f922cb9634217f03482153950c90848a1
2018-03-17Add 'osmo-bts-omldummy' to bring up only OML without RSLHarald Welte10-4/+294
This is used only in integration testing, where in the TTCN-3 testsuite we currently have no A-bis OML implementation, but only a RSL one. Change-Id: Id8e5f34091e6e32621d8c8673de7ea848dfd252f
2018-03-17virtual: Correctly set+report BTS variant in OML attributesHarald Welte3-0/+3
Change-Id: I76dc47427ec26834859fb737bd319dc379ae8697
2018-03-17Get rid of 'struct gsm_bts_role_bts'Harald Welte36-477/+371
gsm_bts_role_bts was introduced at a time when we still shared gsm_data_shared.[ch] between BSC and BTS, and where we then subsequently needed a BTS-private structure. Since that sharing was abandoned quite some time ago, we can merge gsm_bts_role_bts into gsm_bts and do away with the bts/btsb dualism in a lot of the code. Change-Id: I4fdd601ea873d9697f89a748cc77bcf7c978fa3e
2018-03-17cosmetic: Move agch_queue to sub-structure of gsm_bts_role_btsHarald Welte4-71/+73
Rathert han have 11 direct members of gsm_bts_role_bts, group them into a sub-struct as ew do for other parts like interference, laod, ... Change-Id: Iefecf4b70c1b11c650913f2ae3783718ffb8a36c
2018-03-17gsm_data_shared: Remove unused definitions/members/functionsHarald Welte3-248/+1
What we remove here is a legacy from sharing this header file with openbsc/osmo-bsc-sccplite, which we stopped to do quite some time ago and hence can remove those parts that are only relevant to the BSC but not to the BTS. Change-Id: Icac1656da68f6a006a28c779e3b563bbdd905b3d
2018-03-13common/main.c: track talloc NULL contexts by defaultVadim Yanitskiy1-0/+3
In order to be able to introspect not only the root application context, but also all other contexts, e.g. allocated within libosmocore or other libraries, let's enable tracking the use of NULL contexts using the corresponding talloc API. In order to obserbe all existing contexts, use the following VTY command: OsmoBTS# show talloc-context all ... Example of usage: OsmoBTS# show talloc-context all brief talloc report on 'null_context' (total 1302808 bytes in 5185 blocks) lapd context contains 129 bytes in 5 blocks struct signal_handler contains 40 bytes in 1 blocks struct pcu_sock_state contains 120 bytes in 1 blocks struct lookup_helper contains 24 bytes in 1 blocks struct signal_handler contains 40 bytes in 1 blocks struct signal_handler contains 40 bytes in 1 blocks abis contains 49065 bytes in 19 blocks struct signal_handler contains 40 bytes in 1 blocks struct signal_handler contains 40 bytes in 1 blocks struct signal_handler contains 40 bytes in 1 blocks vty contains 93690 bytes in 5008 blocks logging contains 2862 bytes in 7 blocks OsmoBTS context contains 1156678 bytes in 137 blocks Change-Id: I5e9381902dace7dfd37f98b657e4697b5afcff96
2018-03-13configure: add --enable-werrorNeels Hofmeyr1-0/+21
Provide a sane means of adding the -Werror compiler flag. Currently, some of our jenkins.sh add -Werror by passing 'CFLAGS="-Werror"', but that actually *overwrites* all the other CFLAGS we might want to have set. Maintain these exceptions from -Werror: a) deprecation (allow upstream to mark deprecation without breaking builds); b) "#warning" pragmas (allow to remind ourselves of errors without breaking builds) As a last configure step before generating the output files, print the complete CFLAGS and CPPFLAGS by means of AC_MSG_RESULT. Change-Id: I5b37602a117350159183fb53ac330294b94f4195
2018-03-11sysinfo: Fix scheduling of downlink SACCH informationHarald Welte1-2/+4
The existing algorithm (present since 2012!) failed to work in the sole case that only *one* SACCH filling type was present. So if you had your BTS configured to only broadcast SI5, but not broadcast SI5ter, SI6 or any other SACCH filling, it would send the SI5 message only once on a newly-established channel, and never again. The old code was working for more-than-one SACCH filling, as well as for no SACCH filling at all. Let's also add a NOTICE message if there is no SACCH filling available at all. This is highly unusual and definitely a noticeable event. Change-Id: Ica801f9b9c118f00d9e3dc2780b3123e925f59b4 Closes: OS#3057 Related: OS#2963
2018-03-11cosmetic: Document some SI scheduling related function APIHarald Welte2-1/+17
Change-Id: I7e61639349deda28846810c4f52dbea78dccda38
2018-03-11implement support for 3-digit MNC with leading zerosNeels Hofmeyr3-13/+11
Record the mnc_3_digits flag from SI and pass on via the PCU interface. Instead of changing to e.g. osmo_plmn_id, add the flag separately, and instead of bool use a uint8_t, to not raise any struct packing issues and clarify the flag's size beyond any doubt. Bump the PCU interface version to 9. This is one part of the three identical pcuif_proto.h patches: - I49cd762c3c9d7ee6a82451bdf3ffa2a060767947 (osmo-bts) - I787fed84a7b613158a5618dd5cffafe4e4927234 (osmo-pcu) - I78f30aef7aa224b2e9db54c3a844d8f520b3aee0 (osmo-bsc) Depends: Id2240f7f518494c9df6c8bda52c0d5092f90f221 (libosmocore) Change-Id: I49cd762c3c9d7ee6a82451bdf3ffa2a060767947
2018-03-10sysmobts: Compatibility with older firmware versionsHarald Welte1-1/+12
When using a firmware version < 3.6, the call to l1if_mute_rf() returned an error, which caused an OML CHG ADM STATE NACK. Let's check if the l1if_mute_rf() call is an un-mute for all timeslots (which apparently we do always at start-up). If it is, then acknowledge it even if muting is not supported by earlier firmwares. I suppose the change causing this problem was introduced in: commit b26b8fc77692e851469f3e27b9aeaeff233ffd2e Author: Holger Hans Peter Freyther <zecke@selfish.org> Date: Tue Mar 4 15:03:59 2014 +0100 sysmobts: Do a RF mute at initialization when the RC is locked With the current change applied, we can run the BTS with earlier firmware versions than 3.6.0 again. Tested with 3.1 and 2.4 Change-Id: I1a29c1031d96e65a0111bc812a90f2dbaf2a5aa3
2018-03-09sysinfo.c: SI1 is optional; Send SI2 at TC=0 if no SI1 existsHarald Welte1-1/+3
SI1 is only required if frequency hopping is used or if NCH is used. So it's optional. If OsmoBTS has no SI1 configured, it will transmit the empty SI1 buffer at TC=0, and as a result no valid SI will be broadcast at TC=0. Change-Id: I41ab885c00e943199b2e939e98f30e267ecffbee Closes: OS#3051
2018-03-08fix handover: handle_ph_ra_ind(): evaluate ra_ind before msgb_trim()Neels Hofmeyr3-97/+118
Commit c2b4c668f3510b7b0baace749c5a310959010e90 I3b989580cb38082e3fd8fc50a11fedda13991092 introduces evaluation of ra_ind members below the msgb_trim() call that actually invalidates ra_ind. A symptom is that it breaks detection of Handover RACH, wich always ends up with lchan == NULL and interpreting all RACH as chan_nr == 0x88. Fix: do all evaluation of ra_ind before the msgb_trim(), for osmo-bts-sysmo, litecell-15 and octphy. To guard against similar mistakes in the future, set ra_ind = NULL before the msgb_trim() call. Related: OS#3045 Change-Id: I203021ee57f49cb963679ba8bec5943e2abb67fb
2018-03-06common/vty.c: remove unused variablesVadim Yanitskiy1-2/+0
Change-Id: I289dda64228e81ca4c608121e50146a71e19f1e2
generated by cgit v1.2.3 (git 2.25.1) at 2024-09-24 11:33:53 +0000