aboutsummaryrefslogtreecommitdiffstats
path: root/src
AgeCommit message (Collapse)AuthorFilesLines
2018-07-02Remove unneeded direct libortp dependencyPau Espin Pedrol8-17/+13
All code in osmo-bts goes through APIs in libosmotrau (osmo_ortp.h), hence direct dependency is not needed. Fixes OBS warnings: dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/osmo-bts-trx/usr/bin/osmo-bts-trx was not linked against libortp.so.9 (it uses none of the library's symbols) dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/osmo-bts-virtual/usr/bin/osmo-bts-omldummy debian/osmo-bts-virtual/usr/bin/osmo-bts-virtual were not linked against libortp.so.9 (they use none of the library's symbols) Change-Id: I96a9b5f0678331dcf66c007928866a124d8700de
2018-06-29Add min/max/std-dev measurement reporting for TOA256Harald Welte2-9/+84
This patch adds extended processing of the high-resolution TOA256 measurement values. It adds reporting of the following values for each RSL MEAS REP for uplink measurements: * minimum TOA256 value during reporting period * maximum TOA256 value during reporting period * standard deviation of TOA256 value during reporting period Change-Id: Iea4a4781481f77c6163d82dcd71a844a5be87bf2
2018-06-28octphy: add support for 16x oversampling modePhilipp Maier3-1/+86
The latest octphy firmware release (octsdr-2g-02.11.00-B1927-alpha), introduces a 16X oversampling option which is not yet supported in osmo-bts. - Add oversampling flag in phy_link.h - Add VTY commands to enable/disable oversampling - Add phy messages to enable/disable oversampling - Add conditional compilation to preserve support for legacy header files and firmware Change-Id: Ib78f92bfe03ff20aa0a257763c90844fb7b87cf0 Related: SYS#4257 Patch-by: Octasic inc.
2018-06-25log reception of PCU_IF_MSG_PAG_REQ messages from osmo-pcuStefan Sperling1-8/+22
osmo-pcu currently sends paging requests in PCU_IF_MSG_DATA_REQ messages, rather than PCU_IF_MSG_PAG_REQ. Clarify a comment which already alluded to this, and leave an explicit log entry if a PCU_IF_MSG_PAG_REQ message is received. Change-Id: I75fd8f051f943d876b5614fa088fff7e56b310ab Related: OS#3018
2018-06-22sysmo: calib_file.c: Avoid decl of unused vars and funcs with femtobts_v2.7 ↵Pau Espin Pedrol1-19/+19
build Change-Id: I853ff6d3562c5852bff58a07e7c23d49329d9a4f
2018-06-22sysmo: l1_if.c: Avoid decl of unused vars and funcs with femtobts_v2.7 buildPau Espin Pedrol1-3/+4
Change-Id: I4e6d97114289027fbcff00f77cd42db5277a54ab
2018-06-22sysmo: l1if_mute_rf: Declare vars inside ifdef sectionPau Espin Pedrol1-3/+2
Otherwise sysp variable is unused and compiler triggers a warn. Change-Id: Ie3a3529442a36bb885ef634b8b49ac801bd263da
2018-06-22sysmo: Fix memcmp in RF-MUTE.req for superfemto < 3.6.0Pau Espin Pedrol1-2/+2
Fixes following compilation warning: In file included from l1_if.c:32:0: l1_if.c: In function ‘l1if_mute_rf’: /include/osmocom/core/utils.h:13:30: error: ‘sizeof’ on array function parameter ‘mute’ will return size of ‘uint8_t * {aka unsigned char *}’ [-Werror=sizeof-array-argument] #define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0])) ^ l1_if.c:1405:29: note: in expansion of macro ‘ARRAY_SIZE’ if (!memcmp(mute, unmuted, ARRAY_SIZE(mute))) { ^~~~~~~~~~ l1_if.c:1388:51: note: declared here int l1if_mute_rf(struct femtol1_hdl *hdl, uint8_t mute[8], l1if_compl_cb *cb) ^~~~ In file included from l1_if.c:32:0: /include/osmocom/core/utils.h:13:30: error: ‘sizeof’ on array function parameter ‘mute’ will return size of ‘uint8_t * {aka unsigned char *}’ [-Werror=sizeof-array-argument] #define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0])) ^ l1_if.c:1408:19: note: in expansion of macro ‘ARRAY_SIZE’ for (i = 0; i < ARRAY_SIZE(mute); ++i) ^~~~~~~~~~ l1_if.c:1388:51: note: declared here int l1if_mute_rf(struct femtol1_hdl *hdl, uint8_t mute[8], l1if_compl_cb *cb) ^~~~ Change-Id: Id040aeb35549ddb75072942be0093064a89092a6
2018-06-20sysmo: vty: Add missing include for lchan_deactivatePau Espin Pedrol1-0/+1
Fixes following compilation warning: osmo-bts/src/osmo-bts-sysmo/sysmobts_vty.c:349:3: warning: implicit declaration of function ‘lchan_deactivate’ Change-Id: I1dba0b08fdb2af199f009842c9abf32e25f74be1
2018-06-20l1_if.c: Move decl of vars used in conditional macroPau Espin Pedrol1-3/+3
Nowadays, with latest versions of superfemto, those variables are unused. Change-Id: Iec6c28840745e1bd99406b777ea5db66ca1d6fd9
2018-06-14pcu_sock: Log event pcu_sock createdPau Espin Pedrol1-0/+2
Change-Id: I2aa55e05ac481fee59af5bad87baf707831df088
2018-06-11lc15: Fix incorrect cast of hLayer1Pau Espin Pedrol1-1/+1
Change-Id: I545952d0fd4a3fe3ff7c297ce628400b23cfb824
2018-06-10lc15: Use correct type for hLayer1 fieldPau Espin Pedrol2-10/+11
It also fixes a compilation warning in which a uint32_t is assigned to a void pointer. Change-Id: I21ea42274eabe854f3b236a22aeb70b93a280541
2018-06-09Send DELETE_IND when dropping Imm Assign pending messagePau Espin Pedrol2-1/+3
This way we give the opportunity to the BSC to release the channel quicker, otherwise it has to wait until T3101 expires. Same procedure is already done in rsl.c rsl_rx_imm_ass() when we return an error (hard limit AGCH queue len reached) from bts_agch_enqueue(). Related: OS#2990 Change-Id: Id9927c0789054ce3ecc7b30380585a1ffe05db5a
2018-06-08compact AGCH queue: Drop too msg diff than IMM_ASS_REJPau Espin Pedrol1-5/+0
We saw in a recent prod setup a BSC with saturated channels. Further investigation lead to a AGCH queue of 1000 (previous hard_limit) messages, most of them being regular IMM ASSIGN (non REJ). Hence, we also want to get rid of other messages in the AGCH queue (like regular IMM ASSIGN). Furthermore, In this scenario, sending IMM ASS REJ is as important as other messages given than nowadays we support dynamic wait indicatior (calculated based on chan load), which means if we reach the MS, we can tell it to wait for a long time to reach us again, which is desirable. Change-Id: I022b8948da8be13fb8f4bc36e7c9dab11c35fddb
2018-06-08bts_agch_enqueue: Decrease queue len hard_limit from 1000 to 100Pau Espin Pedrol1-1/+1
In a prod setup, complete channel saturation at the bsc was detected, and Immediate Assignments were not being answered by the MS once sent by the BTS. Further investigation showed that the BTS was all the time printing messages like this: "bts.c:540 AGCH: too many messages in queue, refusing message type 0x3f, length = 1001/10" So it seems the AGCH queue was becoming incredibly full (1000, hard limit triggered the log), while acgch_queue.max_length was set to 10. As a result, most probably the Immediate Assignments being sent to the MS are super old in time, and the MS doesn't known about them anymore once they are receivied, so no answer is sent back. Let's try to avoid that by decreasing the hard limit so we never reach that big queue_len scenario. The number 100 is selected from data gatherered in agch_test.c which prints a table of max_length values based on different setups. Some values can reach around 80 messages, so let's use a slightly bigger hard limit. Related: SYS#2695 Change-Id: I272798c959abec123776d2fa8dad5685ec512fbd
2018-06-08bts.c: Add missing include for gsm48_rr_msg_namePau Espin Pedrol1-0/+1
It seems I somehow mischecked that the required include for gsm48_rr_msg_name was not yet present in the file. Fixes: 44a35902adde70b4e4696640f09f448ba44d51d2 Change-Id: Ia82bc6a5ff7e3989cf0b85ee689d0c3344720eda
2018-06-06bts.c: Log name of RR msg type instead of valuePau Espin Pedrol1-2/+2
Change-Id: Ia35e132e0b6532dfbf09bb33fe9328a9e3e16885
2018-05-25rtp: make port range configurable, assign correct port numbersPhilipp Maier3-2/+67
The current implementation does not allow the user to specify a port range in which the BTS is allowed to allocate a local RTP port. Also the ports the BTS picks do not match the policy described in RFC3550. An RTP Port must be at an even port number and the matching RTCP port must be at the following (odd) port number. The BTS currently picks random port numbers for both. - Add a VTY command to specify a port range in which the BTS may assign local ports. - Pick ports as described in RFC3550. Change-Id: Id75f1dfaf898ed8750d28b1c4840e188f4cfdc87 Related: OS#2825 OS#2635
2018-05-24cosmetic: it's n_r in check_for_first_ciphrd(), not n_sHarald Welte1-3/+3
When we introduced the n_s verification in 2cc37035d73191b71b9ba9c0d559a0da6a5f35e5, the variable name n_s was used for what is actually n_r N(R) read from the LAPDm frame Change-Id: Iaef1648f35ceae9d7f4cd1d9d5409e05115d199a
2018-05-24scheduler_trx: Add reminders to use libosmocore functionsHarald Welte1-0/+3
Let' wait until the just-merged osmo_timerfd_* functions of Change-Id Ibeffba7c997252c003723bcd5d14122c4ded2fe7 have made it into the next tagged release, and then replace the implementation here. Change-Id: Ic0f0a7437b6acb535177e5ad6ac7a6d336654c66
2018-05-15let osmo-bts log a special notice if OML connection is closed earlyStefan Sperling1-1/+18
A frequent configuration file error is that the unit_id settings of osmo-bts and osmo-bsc don't match. The BSC already prints an error in this case. Let the BTS print an error as well. We use a heuristic for this purpose: If the OML link is dropped within 10 seconds after being established, log a special warning which alerts the user and recommend a manual configuration file check. Change-Id: I476ac797458b5a46edea3ae9cfbd491fd7f77f47 Related: OS#3143
2018-05-10dyn TS: be less strict on chan_nr, to allow arbitrary pchan switchesNeels Hofmeyr1-10/+4
To allow switching a dyn TS also between TCH/H <-> TCH/F and anything else, don't thwart RSL messages just because their chan_nr doesn't reflect the current pchan mode. For dyn TS, leave that to message handling. In particular, a TS switch is invoked by a Chan Activ message, in which case the current pchan by definition mismatches the incoming chan_nr's reflected channel type. With this patch, I have tested successful direct TCH/H<->TCH/F switchover on sysmoBTS, with osmo-bsc patch I72d5d833b186b1e1925d513885b405d8c19aa496 (and 'msc'/'codec-list' vty config to change TCH kinds while gprs mode was none). Change-Id: I19e5e509101ec91204de9baff04582d99bc8dcb8
2018-05-09osmo-bts-trx: Enable A5/3 cipher supportHarald Welte1-1/+1
This actually should have been working since 2015, when the following patch was merged to libosmcore: commit f8699ca51eeb4f3d34336501abcaf071b4a95a47 Author: Max <max.suraev@fairwaves.co> Date: Wed Mar 25 17:20:31 2015 +0100 gsm: Add A5/3-4 cipher support however, it seems nobody so far bothered to actually enable A5/3 for osmo-bts-trx! Change-Id: I8192d6d07cdb87783bce997456ead673c600f7c0 Closes: OS#3253
2018-05-09rsl: If CHAN ACT or MODE MODIF fails, send respective NACKHarald Welte1-4/+4
The existign code only sent an ERROR REPORT, but it failed to actually send a proper NACK to the related request. This is confusing, as the operation should always be ACKed or NACKed, and not simply result in no response. Change-Id: Ic374a8e5e239ffe37082a54cdb94cb6ac9723e83 Closes: OS#3254
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-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-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 Pedrol1-0/+1
Fixes implicit declaration warning messages at compile time. Change-Id: I753ed49cdcbd1301ba7ea38dcea9113d99fecb06
2018-04-17osmo-bts-trx: perform error concealment for FR framesPhilipp Maier1-2/+16
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 Maier3-13/+104
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-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 Hofmeyr6-29/+9
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
generated by cgit v1.2.3 (git 2.25.1) at 2024-09-22 08:03:48 +0000