path: root/src/common/rsl.c
AgeCommit message (Collapse)AuthorFilesLines
5 daysFix common misspellings and typosMartin Hauke1-4/+4
Change-Id: I403b9029f57fec3fdec2c1e2cbeac0f6eab53f24
2019-09-07common/rsl.c: fix possible NULL-pointer dereferenceVadim Yanitskiy1-1/+5
Change-Id: I11a35a8f500fafa7b3c93d2f2244cc4d42f09f1b Fixes: CID#203810
2019-09-06pcu_interface: Forward ETWS Primary Notification to PCUHarald Welte1-0/+5
All MS/UE must be notified of ETWS Primary Notifiations. Depending on their state, the notification goes different paths: * CS dedicated mode: BSC sends it as L3 message over LAPDm / DCCH * CS/PS idle mode: BTS sends paging messages on PCH * PS TBF active: PCU send Packet Application Info This enables the last of the three methods by passing any ETWS Primary Notifications received over RSL via the PCU socket into the PCU. Change-Id: Ic0b3f38b400a0ca7e4089061ceb6548b0695faa6 Related: OS#4047, OS#4048
2019-09-05ETWS Primary Notification via P1 Rest OctetsHarald Welte1-0/+43
The ETWS (Earthquake and Tsunami Warning System) uses a so-called ETWS Primary Notification which is sent * to phones in dedicated mode (via DCCH from the BSC) * to phones in idle mode (via P1 Rest Octets on PCH/CCCH) This patch implements the second part of the functionality, i.e. transmitting the related ETWS Primary Notification via PCH. As 3GPP doesn't specify how this is communicated over Abis, we use a new, vendor-specific RSL message type. Closes: OS#4047 Depends: libosmocore I89c24a81ada6627694a9632e87485a61cbd3e680 Depends: libosmocore I36fc2ffc22728887d1cb8768c7fcd9739a8ec0fc Change-Id: I18c60cdb86b9c19e09f5ec06d66e9b91608880e6
2019-07-18common/rsl.c: fix: properly handle SI3 Rest OctetsVadim Yanitskiy1-1/+3
It was noticed with old Sony Ericsson phones (like W595 and K510i) that the service provided by Osmocom network becomes unreliable from time to time. The RSSI indicator on those phones shows that the signal is lost, so neither CS nor PS services are working. As it then turned out, System Information 3 broadcasted on the Um interface is different than the one received from the BSC. In particular, the content of SI3 Rest Octets IE is different. Among with the 'GPRS Indicator', which is actually expected to indicate whether the PCU is connected or not, SI3 Rest Octets on the Um interface contain both 'Optional Power Offset' and 'Scheduling if and where' IEs, which are not present in the original messages from the BSC. Moreover, as soon as the PCU is connected, 'GPRS Indicator' IE contains different 'GPRS RA Colour' value, and informs the MS that System Information 13 is sent on extended BCCH, which is not even supported by OsmoBTS! The culprit is in rsl_rx_bcch_info(), where we pass a pointer to osmo_gsm48_rest_octets_si3_decode(). Instead of passing a pointer to the beginning of SI3 buffer, we actually need to shift it to the beginning of the SI3 Rest Octets IE. This change makes my Sony Ericsson phones happy ;) Change-Id: Ia962cf21903ba674057cf52746996dd3254bc1c6
2019-07-17fix spelling stuff mentioned by lintianThorsten Alteholz1-1/+1
Change-Id: I3d6cb6fc1b182d8520ba60e431ab9b74e71d5e3c
2019-07-16RSL: Fix fixed MS power control in RSL CHAN ACTIVEric Wild1-0/+8
Dynamic MS power control should only be active if a power parameters IE was supplied. Change-Id: I0bbe171a287b10d71fc853cd721f66e4c84db8c5
2019-06-05Use #define RSL_CHAN_RACH for RSL Channel Number of RACHVadim Yanitskiy1-1/+1
Change-Id: I7f54fccdae6799e5f4d956a101e11c2d6f998546
2019-06-01common/rsl.c: RSL_IE_HANDO_REF is mandatory for handover CHAN ACTVadim Yanitskiy1-3/+7
According to 3GPP TS 48.058, section 8.4.1, the Handover Reference element must be included if channel activation type is 'handover'. Let's properly reject CHANnel ACTivation messages with missing RSL_IE_HANDO_REF. Otherwise such requests are misinterpreted as regular (non-handover) channel requests. Found using TC_ho_rach() TTCN-3 test case. Change-Id: I9c50e1dbeb54c5470560adcdfb2bdf5abbe47993
2019-05-28clear GPRS indicator in SI3 while PCU is disconnectedHarald Welte1-7/+15
osmo-bts cannot provide GPRS service while osmo-pcu is not connected. The BSC has no knowledge of the PCU connection state. Prevent MSs from trying to register for GPRS while the PCU is disconnected by erasing the GPRS Indicator in SI3. Change-Id: I1a6f5c636c0fe098ee31c280d4572a3f8122b44b Depends: I690cf308311f910005a325d50f5d5d825678d2b2 (libosmocore.git) Depends: I08e0ca9a8d13c7aa40b9d90f34f0e13adb87d4e0 (libosmocore.git) Depends: I8b1ee2405f6338507e9dfb5f1f437c4c2db2e330 (libosmocore.git) Related: OS#3075
2019-05-27Fix passing of RR SUSPEND REQ from DCCH to PCU socketHarald Welte1-9/+33
The existing code ssumed that the RR SUSPEND REQ would be a LAPDm/RSL unitdata request. I couldn't find any spec reference that would support this. Rather, the message is sent via the normal main dedicated channel, which is operated in ABM mode. As the somewhat similar check for diverting measurement results is in fact looking for UNITDATA, we have to untangle this slightly. Change-Id: Ic75486f8edaefa9c07bd92515ba1832b1c482fa6 Related: OS#2249 Related: OS#4023
2019-05-26common/rsl.c: fix NULL-pointer dereference in rsl_rx_rll()Vadim Yanitskiy1-2/+2
Change-Id: I07e39e69a42dd09841f5d03608ec0d0b2345139a Fixes: CID#198663 Null pointer dereferences
2019-05-25Add severity to OML FAILURE EVENT REPORTHarald Welte1-4/+4
Example: The fact that the PCU has connected with a given version is not a *failure* in the first place, particularly not a MAJOR one. Let's allow callers of oml_tx_failure_event_rep() specify the serverity of the event that they're reporting to the BSC. Change-Id: I49af04212568892648e0e8704ba1cc6de8c8ae89
2019-05-24rsl: MS POWER COCNTROL isn't (only) about "forcing" power levelsHarald Welte1-1/+1
...so let's have a more neutral error message Change-Id: I1ffa336b18347c2fcedfeb398b255dc517245d7a
2019-05-24rsl: Implement parsing of BS Power Control messageHarald Welte1-0/+44
Change-Id: Id144a7e468f730e3cdaefa4cf2ad51c6106310a2
2019-05-24RSL: Fix logic about fixed/dynamic MS power control in MS POWER COMMANDHarald Welte1-6/+21
The spec is quite clear: If the MS Power Parameters IE is present, then the BTS shall perform autonomous MS power control. If it's absent, then the MS power shall be fied. Let's adjust our code accordingly. Change-Id: Ie43a1fc9cc658677c8c945ae82d03b7bffbe52d5 Related: OS#1622
2019-05-24Use LOGPLCHAN whenever possibleHarald Welte1-143/+101
There's no point in open-coding what LOGPLCHAN was created to do: Log some event while stating the name of the logical channel. Change-Id: I6913ac8fb543811126b85a54118333155c03bc03
2019-05-23cbch: Add counters; queue length limits and CBCH LOAD reportingHarald Welte1-0/+26
This adds the final missing part to full CBCH support: * keep a tab on the current queue length for basic + extended CBCH * keep rate counters about the number of sent / transmitted SMSCB * send CBCH LOAD information via RSL to the BSC Change-Id: I7068c7937a60a900c40439115bb84dc3ee0d061f
2019-05-21cbch: Support Extended CBCHHarald Welte1-2/+8
The logic for Extended CBCH are the same as for the Basic CBCH, we just need to * duplicate our related state * parse the optional RSL_IE_SMSCB_CHAN_INDICATOR IE * start to send data on the Extended CBCH (TB=4..7) Change-Id: If2c6dc7da1e2185ab75fc957f8d305ad8db22429 Closes: OS#3535
2019-05-21cbch: Fix memory leak and send error message on invalid SMSCB commandHarald Welte1-3/+7
Change-Id: I411d1fb3693a2f7cf7bba3d38b1aaf276a4137ba Related: OS#4011
2019-05-21RSL: Fix off-by-one error when parsing SACCH INFO IE in RSL CHAN ACTHarald Welte1-1/+1
This off-by-one error in length verification caused all SACCH INFO IE to be deemed invalid and hence any RSL CHAN ACT with that IE to be rejected. Change-Id: I6436caf5c2caefbf7c089d66e37d8d1babe1c24e Related: OS#3750
2019-05-21RSL: Reject RLL messages for lchans that are not active yetHarald Welte1-0/+8
The Radio Link Layer (RLL) messages only make sense when a given logical channel is active. If it isn't active, let's reject the messages with an RSL ERROR REPORT with cause "Message sequence error", wich according to spec means: "A message with an existing message type which is not possible according to the specification and to the state of the BTS is erroneous." Related: OS#3750 Change-Id: I68dbb622aeaee657471664cdc0b69c2ac316d77e
2019-05-20rsl: Include Channel Nr and Link ID in Error reports whenever possibleHarald Welte1-13/+27
While the CHAN_NR and LINK_ID IEs in ERROR REPORRT are optional, we still should include it whenever possible to help error analysis. Related: OS#3750 Change-Id: I8155e0d37096bd7bf3563e4f7853171ca4b3aa58
2019-05-20rsl: Send RSL Error Report in case of unknown/unsupported msg_typeHarald Welte1-1/+14
Send an RSL Error Report in case of unknown/unsupported msg_type, as describedi in section 7.3 of 3GPP TS 48.058. Related: OS#3750 Change-Id: Ib2918007410e635b144a7535cec30b9f3378c755
2019-04-24common/rsl.c: fix unaligned pointers in rsl_add_rtp_stats()Vadim Yanitskiy1-24/+24
Found using clang-8: rsl.c:1646:7: warning: taking address of packed member 'packets_sent' of class or structure 'ipa_stats' may result in an unaligned pointer value rsl.c:1646:28: warning: taking address of packed member 'octets_sent' of class or structure 'ipa_stats' may result in an unaligned pointer value rsl.c:1647:7: warning: taking address of packed member 'packets_recv' of class or structure 'ipa_stats' may result in an unaligned pointer value rsl.c:1647:28: warning: taking address of packed member 'octets_recv' of class or structure 'ipa_stats' may result in an unaligned pointer value rsl.c:1648:7: warning: taking address of packed member 'packets_lost' of class or structure 'ipa_stats' may result in an unaligned pointer value rsl.c:1648:28: warning: taking address of packed member 'arrival_jitter' of class or structure 'ipa_stats' may result in an unaligned pointer value Change-Id: Ifba33cfd8edeccc99a21c7d076db7119c29d4f40
2019-04-23common/rsl.c: fix size argument in memcmp() callVadim Yanitskiy1-1/+1
Found using clang-8: rsl.c:1607:93: warning: size argument in 'memcmp' call is a comparison [-Wmemsize-comparison] rsl.c:1607:7: note: did you mean to compare the result of 'memcmp' instead? It looks more logical to compare the result of memcmp() against zero instead of passing 'sizeof(sysinfo_buf_t) != 0' as size. Change-Id: Ia8b95b017dbbfeb058d479fbaaf4861930569bb5
2019-03-27Forward GPRS SUSPEND REQ from DCCH to PCU socketHarald Welte1-9/+46
As specified in 3GPP TS 03.60 Section 16.2.1 and 44.018 Section 3.4.15, a Class B MS is sending a "RR GPRS SUSPEND REQ" via a DCCH to the BTS if it wants to suspend GPRS services. The BSS is now responsible to somehow forward this to the SGSN. As the Gs interface between BSC and SGSN is both optional and doesn't have any provision to forward this message, we have to send it over to the PCU so it can use regular BSSGP signaling to inform the SGSN of the SUSPEND REQUEST. This patch requires libosmocore Change-Id I90113044460a6c511ced14f588876c4280d1cac7 for the related definition of struct gsm48_gprs_susp_req. Change-Id: I3c1af662c8f0d3d22da200638480f6ef05c3ed1f Closes: OS#2249
2019-03-27oml: use oml_tx_failure_event_rep() instead of oml_fail_rep()Philipp Maier1-9/+12
The function oml_tx_failure_event_rep() replaces oml_fail_rep(), so lets use only oml_tx_failure_event_rep() and remove oml_fail_rep() Change-Id: I83c4fa9ebd519299fd54b37b5d95d6d7c1da24f6 Related: OS#3843
2019-03-27rsl.c: Add missing #include of gsm0808.hHarald Welte1-0/+1
This fixes the below compile error: rsl.c:900:43: error: ‘gsm0808_chosen_enc_alg_names’ undeclared (first use in this function) Change-Id: I4aed0242737602e61b785862e3c37c963bf48455
2019-02-14Log lchan kind on PCU-related errorMax1-2/+2
Change-Id: Iadb464e7040dd11e4a8cabfc96d6d90f32594109
2018-12-23rsl: Send PDCH ACT NACK if TCH chan is still activePau Espin Pedrol1-0/+6
Fix recent commit which broke TTCN3 BTS_tests TC_dyn_ipa_pdch_tchf_act_pdch_act_nack. Prior to the breaking commit, logic was still not good, because 1- It didn't return after sending the NACK 2- It sent a NACK in all cases, while for PDCH DEACT we want to force its deactivation. Going through tests it can be seen that indeed it can deactivate it in that case: rsl.c:2206 (bts=0,trx=0,ts=3,pchan=TCH/F_PDCH as PDCH) Request to PDCH DEACT, but lchan is still in state ACTIVE ... rsl.c:2103 (bts=0,trx=0,ts=3,ss=0) Tx PDCH DEACT ACK Fixes: 133a3d96dc07ebda4dfc7899dab9c0d0c80c9fea ("rsl: Avoid sending ipa PDCH DEACT NACK followed by ACK") Change-Id: I6d6d12aec10c801fe55012ca6e58d0bc8755b15d
2018-11-26bts_model: Allow TS connect to be processed asynchronouslyPau Espin Pedrol1-10/+22
This commit doesn't change internal logic of any model, only the API to be able to return result of connect TS asyncrhonously since some models (like osmo-bts-trx) require some time to process the result. This way PDCH ACT/DEACT (N)ACK can be sent once the result of this long process is known. For instance, nowadays in osmo-bts-trx we PDCH (DE)ACT ACK before getting the result from SETSLOT on the TRX iface. With this new API, bts_model_ts_connect doesn't return any value synchronously. Instead, it is expected to always end up calling cb_ts_connected with the return code from the TS activation process. 0 is considered a successs, while any other value is considered an error. Change-Id: Ie073a4397dd2f1a691968d12b15b8b42f1e1b0cf
2018-11-26cosmetic: fix whitespacePau Espin Pedrol1-1/+1
Change-Id: Iaa4552844db33fe69da5ed7028dbfa0100c33900
2018-11-23rsl: Avoid sending ipa PDCH DEACT NACK followed by ACKPau Espin Pedrol1-2/+1
It was spotted during osmo-gsm-tester test dynts:trx-sysmocell5000+mod-bts0-dynts67-ipa+cfg-codec-fr-any that osmo-bts-trx was answering to PDCH DEACT from BSC first with a NACK followed immediatelly after by an ACK. That happens after the test does a GPRS pdp ctx act successfuly and then deactivates the ctx and the 2 MS try to place a call between them (and thus channels need to be moved to TCH/F). Most probably the if condition where the lines for this commit are modified need to be fine-grained. Patch before this one should help to understand the steates/situation in this scenario, and then a follow-up patch can be created to improve the logic. Change-Id: I91c65da6b6b7094f32187d3b083153a87c3219fd
2018-11-23rsl: Log lchan state during dynts PDCH->TCHPau Espin Pedrol1-2/+3
Change-Id: Iee5ac0550afda71fce67b0340749c111b364bb4f
2018-10-10rsl_rx_chan-activ: Improve logging informationPau Espin Pedrol1-2/+3
Change-Id: I9b9a666e195ea729503ecd707e1582268c190e09
2018-09-19common/rsl.c: tweak log message in lapdm_rll_tx_cb()Vadim Yanitskiy1-2/+3
During the investigation of OS#3559, it was discovered that the log message, which warns that an RSL message was dropped due to inactive logical channel, has incorrect log level - LOGL_INFO. This is not informative kind of message, so let's increase the log level, and additionally let's print the hexdump of message and it's length. Change-Id: I26eac5e4466c493ffe08dbb89de20f5e1c2bb85d
2018-09-11log: add error log for RSL Chan Mode ModifKeith Whyte1-1/+4
Add log context to chan_mode error in rsl_rx_mode_modif(). Tweaked-by: neels Change-Id: I945cf1ca8660ad5daf097edab1833bbc74b6185f
2018-09-11fix RSL Chan Mode Modif for dyn TSNeels Hofmeyr1-1/+1
Fix the chan mode checking for RSL Chan Mode Modif: do not reject all modes on dyn TS. In rsl_rx_mode_modif(), bts_supports_cm() should never be fed with dynamic pchan kinds (e.g. GSM_PCHAN_TCH_F_TCH_H_PDCH). Feed instead the return value of ts_pchan() that is to say, the actual pchan type (e.g. GSM_PCHAN_TCH_F). Change-Id: I7f0c835b25289931bccf96e982ea5564c8be4192
2018-09-09CBCH: Fix rejecting SMS-CB related RSL messagesHarald Welte1-2/+6
Normally, the "Common Channel" related RSL messages should actually contain such a common channel. However, since cell broadcast is implemented inside what's essentially a downlink SDCCH, we should add some explicit exceptions. Before this patch, any RSL SMS BC CMD would have been discarded and an RSL Error Indiciation returned. Change-Id: I2f7f1dd43505cc27cd33489d8b0e8c981cd93880 Closes: OS#3533
2018-08-20measurement: make sure state is reset on chan act.Philipp Maier1-1/+1
At the moment only lchan_meas_reset is reset on channel activation. All other states are not reset. This may lead to irretations in the first measurement interval if there are still leftover messages from a previous connection. Lets ensure everything is reset to zero by zeroing out the whole .meas struct in struct lchan. - Add a centralized function that does the reset - Call that function from rsl_tx_chan_act_ack() in rsl.c Change-Id: I880ae3030df6dcd60c32b7144c3430528429bdea Related: OS#2975 Related: OS#2987
2018-07-25preserve lchan-specific SI overrides on SACCH FILLStefan Sperling1-4/+10
During SACCH FILL processing, update lchan SI values only for lchans which follow BTS-global default values, keeping lchan-specific overrides in place. Change-Id: I515bbd9983fa894507386b241863a9aa4d279497 Fixes: eee7247ebe0d0a54a54b53b739bdd434dfceb511 Related: OS#3173
2018-07-24update sysinfo copies in all lchans upon SACCH FILLStefan Sperling1-0/+32
When a SACCH FILL is received, loop over all lchans and update their copies of system information data. This change makes BTS_Tests.TC_sacch_multi_chg pass. Change-Id: I3e63eeb5fcf320fb029de16e4d327e153cc34567 Related: OS#3173
2018-07-06rsl: Use value_string to print encryption algo namePau Espin Pedrol1-4/+5
Change-Id: I8303364270e73718e57f8efc2f375817b9496ffc
2018-06-29Add min/max/std-dev measurement reporting for TOA256Harald Welte1-8/+22
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-09Send DELETE_IND when dropping Imm Assign pending messagePau Espin Pedrol1-1/+1
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-05-25rtp: make port range configurable, assign correct port numbersPhilipp Maier1-2/+24
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-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