OpenBSC December 2017

openbsc@lists.osmocom.org

20 participants
37 discussions

dynamic traffic channels
by Neels Hofmeyr 20 May '25

20 May '25

On Tue, Jun 28, 2016 at 10:05:28AM +0200, Harald Welte wrote: > [translated from german] > is it certain that we switch a channel to PDCH only when > gprs mode != none? A TS can be GSM_PCHAN_TCH_F_PDCH; those are the only ones for which we send a PDCH ACT message. We send a PDCH ACT message - during init (CHANNEL OML's state changed to enabled -> send PDCH ACT), - and upon channel release ack when pchan == GSM_PCHAN_TCH_F_PDCH. So the question is, when we receive a channel release ack, could that be the PDCH release and we switch PDCH right back on by accident? No, because we only receive a chan rel ack when the *TCH/F* is being released. That is because the PDCH release is initiated "internally" from the PDCH DEACT, and thus this condition in common/rsl.c rsl_tx_rf_rel_ack() catches on, which existed before dyn PDCH: if (lchan->rel_act_kind != LCHAN_REL_ACT_RSL) { LOGP(DRSL, LOGL_NOTICE, "%s not sending REL ACK\n", gsm_lchan_name(lchan)); return 0; } In rsl_rx_rf_chan_rel() the rel_act_kind is set to LCHAN_REL_ACT_RSL, but not in the rsl_rx_dyn_pdch(). This is analogous to the ip.access way -- the ip.access nanobts replies to a PDCH DEACT with a PDCH DEACT ACK and doesn't send a separate channel release ack. Maybe we could set rel_act_kind to some new LCHAN_REL_ACT_IPAC_DYN_PDCH for clarity? (But we shouldn't actually send a release ack, to stay compatible.) Even though it works as-is, we should indeed add another flag check: - We do check the flags that no ACT/DEACT is already pending; - And we do send a PDCH DEACT only if ts->flags & TS_F_PDCH_ACTIVE; - But we would send a PDCH ACT despite ts->flags & TS_F_PDCH_ACTIVE. This should never happen, but it would make sense to ensure that. ~Neels

3 5

GSM 04.08 L2 pseudo length in ACCH System Information messages
by Vadim Yanitskiy 12 Mar '18

12 Mar '18

Hi everyone, I few days ago, during some usual R&D process, I noticed the following messages, appearing in the log output of OsmocomBB/mobile application: "ACCH message type 0xXX unknown." The network, a phone was connected to, was may own and based on more or less recent versions of OsmoNiTB, OsmoBTS, and OsmoTRX. Despite I used to see such messages before, I didn't pay too much attention. But this time I've decided to figure out, what's wrong there... The source of such messages is the gsm48_rr.c / gsm48_rr_rx_acch(): static int gsm48_rr_rx_acch(struct osmocom_ms *ms, struct msgb *msg) { // ... struct gsm48_system_information_type_header *sih = msgb_l3(msg); // ... switch (sih->system_information) { case GSM48_MT_RR_SYSINFO_5: return gsm48_rr_rx_sysinfo5(ms, msg); case GSM48_MT_RR_SYSINFO_5bis: return gsm48_rr_rx_sysinfo5bis(ms, msg); case GSM48_MT_RR_SYSINFO_5ter: return gsm48_rr_rx_sysinfo5ter(ms, msg); case GSM48_MT_RR_SYSINFO_6: return gsm48_rr_rx_sysinfo6(ms, msg); default: LOGP(DRR, LOGL_NOTICE, "ACCH message type 0x%02x unknown.\n", sih->system_information); return -EINVAL; } } To get I bit more details, I modified this function to print the whole L3 payload, and got some interesting results. As it turned out, the payloads were shifted one byte left - there was no 'l2_plen', which is assumed by: /* Section 9.1.3x System information Type header */ struct gsm48_system_information_type_header { uint8_t l2_plen; uint8_t rr_protocol_discriminator :4, skip_indicator:4; uint8_t system_information; } __attribute__ ((packed)); So, my first idea was that this is a bug of OsmocomBB, that would be fairly easy to fix, so after a quick look at the GSM 04.08 specification I wrote (and merged :/) this: https://gerrit.osmocom.org/#/c/5204/ And everything was great, until I connected a 'patched' mobile to a commercial mobile network... And all SI messages during a dedicated connection were false-identified as SI5ter. This seemed strange to me, so I decided to compare a SI message from commercial network with a message captured in my own one: https://habrastorage.org/webt/t8/zs/vv/t8zsvvjjglzfisnjqlnnsy4kgas.png And this confused me even more, then I've expected. Why there is 0x49? Wireshark false-identified this message as something related to SMS... What if this is exactly the 'l2_plen' assumed in OsmocomBB before? I looked at the specifications again, and found out that initially I refered an outdated 5.3.0 version, which was the first link in Google: http://www.etsi.org/deliver/etsi_gts/04/0408/05.03.00_60/gsmts_0408v050300p… while the latest one is 7.21.0: http://www.etsi.org/deliver/etsi_ts/100900_100999/100940/07.21.00_60/ts_100… So, I compared the 9.1.37-40 sections of both versions, and bingo! In the higher version ACCH System Information messages do have the 'L2 Pseudo Length' (10.5.2.19) field. Finally, what I've learned: - OsmocomBB / mobile follows the new version here (with l2_plen); - OsmoNiTB generates the ACCH SI messages without the l2_plen; - Recent Wireshark versions fail to decode the ACCH SI messages with l2_plen, while older ones are able to do that; - I should not merge the changes so quick. My questions are: - Which way of composing the SI messages is correct? - If both are correct, how to parse them correctly? - Should we change OsmoNiTB / OsmoBSC to follow the latest specs? And of course, I have to revert the change I've merged. With best regards, Vadim Yanitskiy.

2 1

osmo-trx with USRP1 - libusrp vs. UHD
by Alexander Huemer 21 Jan '18

21 Jan '18

Hi! I played with osmo-trx today and tried to run it with a USRP1 that I have laying around, though to no avail. osmo-trx supports two kinds of devices, USRP1 via libusrp and UHD. libusrp was last included in gnuradio 3.4.2[1] from Dec 2013, it unsurprisingly does not build on a recent Linux distribution, due to API incompatibilities with boost. The USRP1 would theoretically be supported by UHD, though the device initialization code in osmo-trx explicitly treats it differently, see [2,3]. I found an old ML post[4] from 2015 that pretty much asks the same question but did not get an answer. Supposedly there is a simple reason why USRP1 is not driven via UHD in osmo-trx, but I don't know. Can somebody please enlighten me? Tom, maybe you? I would like to understand whether it is feasible to use an USRP1 with UHD for osmo-trx or one would have to go down the rabbit hole to build libusrp on a modern system. Kind regards, -Alex [1] https://gnuradio.org/releases/gnuradio/ [2] https://git.osmocom.org/osmo-trx/tree/Transceiver52M/UHDDevice.cpp#n512 [3] https://git.osmocom.org/osmo-trx/tree/Transceiver52M/USRPDevice.cpp [4] https://lists.osmocom.org/pipermail/openbsc/2015-January/000058.html

5 14

stricter rate counter group allocation breaks applications
by Neels Hofmeyr 07 Jan '18

07 Jan '18

A recent patch to libosmocore refuses to allocate a rate counter group with an index that already exists. Per se that's a good thing, but it needs fixes in a whole range of callers. Numerous callers wrongly just pass 0 as rate counter group, so as soon as a second <thing> shows up, the application may deny service; that's unacceptable. For example, OsmoSGSN now crashes with the second subscriber showing up! causing patch: https://gerrit.osmocom.org/5418 my proposed change: https://gerrit.osmocom.org/5516 I'd like to request everyone to refrain from submitting patches that are insufficiently tested, in general of course, but in particular until after congress, please ;) ~N

2 2

help !!!
by Liang hengshuo 29 Dec '17

29 Dec '17

When I run pysim ,I cannot read the card ,and always tell me this: lab434@lab434-OptiPlex-7050:~/pysim$ ./pySim-read.py -p0 Reading ... ICCID: Traceback (most recent call last): File "./pySim-read.py", line 99, in <module> print("IMSI: %s" % (dec_imsi(res),)) File "/home/lab434/pysim/pySim/utils.py", line 57, in dec_imsi l = int(ef[0:2]) * 2 # Length of the IMSI string ValueError: invalid literal for int() with base 10: 'ff' Anything you know may help me ,thank you !

2 1

gerrit load
by Neels Hofmeyr 29 Dec '17

29 Dec '17

I noticed that gerrit places constant load on the server. When I first checked, it was between 30 and 60% CPU load, now is more like 10-15%, but still it is constant load. I'm pretty sure we're not all clicking around in gerrit all the time, so what would it be: Gerrit does things in the background, like checking whether unmerged patches have merge conflicts to the current master. I'm not perfectly sure how often this happens, but my guess is that it happens a lot. We have around 150 open patches on gerrit. If not for sanity, maybe the CPU load on the gerrit server could be another reason to reduce that number. Related: I notice that the sync of gerrit's git repositories takes longer than it used to. It would be a minute max, while just now I got >10min, and I remember Pau noting something similar recently. I think we should plain abandon patches that have been idling around for more than 3 months. That would discard about 30, so not that many. Then we have quite a number that are currently in Merge Conflict... Seems that we don't get around looking at each one and deciding to kick it or keep it. ~N

6 6

Use osmocombb and openbsc to do man-in-the-middle attacks
by 西电__张皓 25 Dec '17

25 Dec '17

Hello, I would like to use openbsc to do a fake base station and osmocombb to do an attack cell phone, to implement a man-in-the-middle attack. I have two questions: 1. How do I send location updates and authentication information between openbsc and osmocombb, 2. How to modify the code thank you very much

1 0

Branch cleanup in osmo-mgw.git
by Harald Welte 25 Dec '17

25 Dec '17

Dear all, I'm seeing plenty of branches which I believe were forgotten to clean up: gerrit/lynxis/pre_release gerrit/neels/client_vty gerrit/neels/new_mgw gerrit/neels/osmo-mgw gerrit/neels/pending gerrit/neels/pmaier/mgw2 gerrit/neels/pmaier_mgw gerrit/neels/pmaier_mgw6 gerrit/neels/split gerrit/neels/wip gerrit/pmaier/aoip2 gerrit/pmaier/mgw gerrit/pmaier/mgw2 gerrit/pmaier/mgw3 gerrit/pmaier/mgw4 gerrit/pmaier/mgw5 gerrit/pmaier/mgw6 gerrit/pre_release I would appreciate if the respective authors could have a look and remove them if the respective branch is confirmed to be no longer needed. Thanks! Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

Jenkins integration of OsmoBSC TTCN-3 test suite
by Harald Welte 20 Dec '17

20 Dec '17

Dear all, the last couple of weeks I've been spending a lot of time creating an OsmoBSC test suite. A lot of this was infrastructure work, as e.g. there was no RSL implementation available yet for TTCN-3. The code can be found at http://git.osmocom.org/osmo-ttcn3-hacks/tree/bsc there's a README.txt file included with more details (and further test ideas). I've also found some time for the docker + jenkins integration, whose results can now be seen at http://git.osmocom.org/osmo-ttcn3-hacks/tree/bsc (click on 'expand all' to see details). During the writing of the test suite I discovered a quite large number of bugs in OsmoBSC and some of its dependencies, see the list below. I'll stop working on the test coverage for now and focus on other areas of testing first (as well as fixing some of the now-known bugs). Any help is greatly appreciated. List of bugs uncovered/documented: OsmoBSC user manual doesn't specify how to configure M3UA link (asp/as) https://osmocom.org/issues/2767 OsmoBSC BSSMAP CIPHER MODE REJECT is missing mandatory cause IE https://osmocom.org/issues/2766 OsmoBSC refuses configuration with both FR and HR codecs https://osmocom.org/issues/2763 OsmoBSC: Assignment of "Signalling" channel fails https://osmocom.org/issues/2762 OsmoBSC ASSIGNMENT FAIL doesn't contain useful cause https://osmocom.org/issues/2759 rate_ctr_group_alloc with identical index doesn't return error https://osmocom.org/issues/2757 T3113 default of 60s seems way too large https://osmocom.org/issues/2756 Paging on LAI not working https://osmocom.org/issues/2754 Paging on CI not working https://osmocom.org/issues/2753 Paging on LAC+CI not working https://osmocom.org/issues/2752 Paging on CGI not working https://osmocom.org/issues/2751 OsmoBSC allows COMPLETE L3 INFO for SACCH https://osmocom.org/issues/2750 OsmoBSC allows COMPLETE LAYER3 on SAPI !=0 https://osmocom.org/issues/2749 OsmoBSC continues to page subscribers even after BSSMAP RESET https://osmocom.org/issues/2736 RF channel teradown timers (T3109) way too large https://osmocom.org/issues/2734 T3101 default is way too large at 10s https://osmocom.org/issues/2733 OsmoBSC sends invalid zero-length BSSAP payload in SCCP RLSD https://osmocom.org/issues/2732 OpenBSC doesn't release lchan if MSC does a hard SCCP disconnect https://osmocom.org/issues/2731 BSC doesn't release RF conenction or SCCP connection after main signalling link is closed https://osmocom.org/issues/2730 CTRL "msc_connection_status" reports "disconnected" even ater MSC is connected https://osmocom.org/issues/2729 Align better with 48.103 for AoIP user plane https://osmocom.org/issues/2728 OsmoBSC doesn't release lchan if MSC refuses connection (CR -> CREF) https://osmocom.org/issues/2726 OsmoBSC doesn't release lchan if MSC doesn't answer to CR https://osmocom.org/issues/2725 OsmoBSC doesn't send BCCH filling after RSL connection unless BTS sends unsolicited message https://osmocom.org/issues/2719 ipaccess_bts_handle_ccm() gets ID_REQ/ID_RESP/ID_ACK wrong https://osmocom.org/issues/2718 libosmo-abis doesn't use ipa_ccm_make_id_resp() https://osmocom.org/issues/2717 BSC doesn't terminate OML connection if RSL is never established https://osmocom.org/issues/2716 "show trx" doesn't show missing RSL connection https://osmocom.org/issues/2715 OsmoBSC doesn't refuse/close RSL connections from unknown Unit ID https://osmocom.org/issues/2714 -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

2 2

Re: Build failure of network:osmocom:nightly/openbsc in Debian_9.0/x86_64
by Neels Hofmeyr 20 Dec '17

20 Dec '17

This is most probably related to / fixed by https://gerrit.osmocom.org/5516 : [ 142s] [0;m<001e> rate_ctr.c:195 counter group 'msc' already exists for index 0 [ 142s] [0;m/usr/src/packages/BUILD/openbsc/tests/testsuite.dir/at-groups/1/test-source: line 25: 20213 Segmentation fault $abs_top_builddir/tests/gsm0408/gsm0408_test On Tue, Dec 19, 2017 at 08:14:06PM +0000, OBS Notification wrote: > Visit https://build.opensuse.org/package/live_build_log/network:osmocom:nightly/o…

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC December 2017