OpenBSC March 2018

openbsc@lists.osmocom.org

16 participants
38 discussions

BSC_Tests.ttcn now needs TITAN 6.3.1 to build
by Harald Welte 16 Mar '18

16 Mar '18

Dear all, as I explained in https://osmocom.org/issues/3070 for some reason BSC_Tests.ttcn fails to work under TITAN 6.1.0 anymore. Rather than debugging old TITAN versions, I decided to update to the latest stable release (6.3.1) in the debian-stretch-titan container that we use on jenkins. Please keep this in mind when running tests locally: * for containerized setups, switch to latest docker-playground master and re-build the debain-stretch-titan container before building any of the ttcn3-*-test containers based on it * if you build+run the ttcn-3 code on your native machine/distro, pleaes switch to TITAN 6.3.1. If you run Debian 9, you can use the package from network:osmocom:latest 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

docker-playground to gerrit?
by Neels Hofmeyr 16 Mar '18

16 Mar '18

Do I have permission to move the docker-playground.git to gerrit? I have a bunch of patches already in my various branches. I could just push them onto master, but I guess some code review would be good? Should we also add a gerrit job that tests the changes? Kind of hard to make a failure decision though while when some tests are normally failing, like they still are. ~N

2 1

ttcn3: BSSGP_Types.ttcn MCC-MNC
by Neels Hofmeyr 16 Mar '18

16 Mar '18

In the file BSSGP_Types.ttcn -> ../deps/titan.ProtocolModules.BSSGP_v13.0.0/src/BSSGP_Types.ttcn I notice many PLMN definitions like type record PLMN_Identity { OCT1 iEI, BIT1 ext, LIN2_2a lengthIndicator, HEX1 mccDigit1, HEX1 mccDigit2, HEX1 mccDigit3, HEX1 mncDigit3, HEX1 mncDigit1, HEX1 mncDigit2 } which at first glance looks like they got the MCC-MNC digits ordered wrongly. It is correct as long as the less significant nibble comes first. And using these in PLMN tests gives the expected results. Now I assume that the HEX1 means that it's a nibble, where the less significant nibble comes first, sort of a "network nibble order" if that makes any sense. It is weird, though -- do we need to compose hex strings "reversed" as well?? ~N

2 1

re failing ttcn BTS_Tests / pcuif_proto.h version bump
by Neels Hofmeyr 13 Mar '18

13 Mar '18

I have a trivial patch adding the new data item to the PCUIF_Types.ttcn (see branch neels/pcu in osmo-ttcn3-hacks.git), but I can't get the TC_pcu_act_req() to pass. I have trouble understanding where in that the PCUIF version would take effect, I can't find any place where it is populated. That would need a bump to version 9. Maybe that's not needed at all. All I get is 21:13:27.702570 mtc BTS_Tests.ttcn:1883 setverdict(fail): none -> fail reason: "Timeout waiting for PCU R TS.req", new component reason: "Timeout waiting for PCU RTS.req" and I can't figure out why. It doesn't seem related to the pcuif_proto.h anyway. ~N

2 1

Hardware for 3G
by Bruckner Jan (ETAS-SEC/ECT-Mu) 12 Mar '18

12 Mar '18

Hi all, I'm interested in upgrading my 2G setup to also support 3G. My current setup is: USRP N210, osmo-trx, osmo-bts-trx, osmo-nitb, osmo-pcu, osmo-sgsn, osmo-ggsn. On the software side I understand I'd have to migrate from osmo-nitb to the new split components and add the 3G components. Regarding the hardware it seems most people are using the ip.access nano3G femtocell. Is this the same one that's included in the sysmocom 3.5G starter kit? Are there any alternatives I'm not aware of other than using non-Osmocom projects? Thanks, Jan

5 11

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

Send sms to all subscribers DB
by Sandi Suhendro 12 Mar '18

12 Mar '18

Dear list, anyone know if osmo-nitb can send sms to all subscribers like blast sms? it would be nice if we can implemented it. Thanks -- Best Regards, DUO

2 1

[PATCH] trxcon/Dockerfile: use 'fixeria/trx' branch
by Vadim Yanitskiy 09 Mar '18

09 Mar '18

The 'laforge/trx' branch of OsmocomBB was used to make basic TTCN3 tests, such as the 'max_ta', work ASAP. Now all required changes and some bug fixes have been merged to the 'fixeria/trx'. Change-Id: If86dcd677cd8a8bf62821028e17ebdf99a7a004e --- osmocom-bb-trxcon/Dockerfile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/osmocom-bb-trxcon/Dockerfile b/osmocom-bb-trxcon/Dockerfile index 1d29051..ca8ac2c 100644 --- a/osmocom-bb-trxcon/Dockerfile +++ b/osmocom-bb-trxcon/Dockerfile @@ -2,7 +2,7 @@ FROM laforge/debian-jessie-build MAINTAINER Harald Welte <laforge(a)gnumonks.org> -ARG OSMO_BB_BRANCH="laforge/trx" +ARG OSMO_BB_BRANCH="fixeria/trx" ARG OSMOCOM_REPO="http://download.opensuse.org/repositories/network:/osmocom:/nightly/Debian_…" -- 2.16.2

1 0

OsmoBsc_Nat with osmux configuration example
by Rafael Diniz 07 Mar '18

07 Mar '18

Hi all, Does anyone have a working OsmoBsc_Nat with osmux working example? I just want to take a look in osmux, so it doesn't matter if it's with old NITB-era stack or new split stack. Thanks, Rafael Diniz

3 4

MS driver: GSM tester config integration
by Holger Freyther 07 Mar '18

07 Mar '18

Hey, pespin left a good comment about the question of how the MS driver and the GSM tester could be better integrated. I was about to write some argparse code for the MS driver but I think it is best to make this configurable as a scenario. In terms of scenario knobs I can see: - #MS - CDF function - IMSI generator (start with XXX and count upwards) - virtphy vs. trxcon? The actual test would remain separate (and maybe turn it into a suite at some point in the future). What do you think? What should I obey when parsing/handling config? holger

3 4

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC March 2018