OpenBSC

openbsc@lists.osmocom.org

12 participants
4172 discussions

GSM 04.08 L2 pseudo length in ACCH System Information messages

by Vadim Yanitskiy

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.

7 years, 5 months

Send sms to all subscribers DB

by Sandi Suhendro

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

7 years, 5 months

[PATCH] trxcon/Dockerfile: use 'fixeria/trx' branch

by Vadim Yanitskiy

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

7 years, 5 months

OsmoBsc_Nat with osmux configuration example

by Rafael Diniz

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

7 years, 5 months

MS driver: GSM tester config integration

by Holger Freyther

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

7 years, 5 months

GSM tester scenarios and beyond

by Holger Freyther

Hey neels, pespin, while looking at configuration handling for the MS driver I started to have sone questions about scenarios. I see that we have multiple yaml files and through scenarios can control ciphering, the timeslot configuration, which BTS model to test, and more. What would it take to get this abstraction one step further? When I diff the aoio_sms and sms suite the difference is in setup (and then naming of msc vs. nitb)? Wouldn't this be something we can get into the scenario as well? The requirements for this test are two connected and routable subscribers? low priority thing but what do you think? holger

7 years, 5 months

fsm4 branch and handover_test.c

by Neels Hofmeyr

Hi Philipp, I promised you to look at handover_test.c on the new fsm4 branch. Looking at it now, I immediately ran into FSM events being dropped on the floor because it was in the wrong state. When I initially fix that, the test runs into the MGCP FSM not existing. So at the end of the day, it is all related to the recently added FSMs and how they interact, and it seems to me that you are more familiar with those than me. In other words, I'm playing the ball back into your corner now: Look at osmo-bsc branch neels/fsm4, here are the differences to pmaier/fsm4: - right at the start, I add a patch to properly wrap abis_rsl_sendmsg(). That's just cosmetic, really. It was doing its job well, just I don't trust that implicit linking. It's at the start because I also submitted it to gerrit. 5eaaf6120e21 (I'd link to git.osmocom.org but after 10 minutes the branch still isn't synced there, strange.) - I add the DMSC logging category to handover_test.c. That enables the FSM's error messages to be logged. This only makes sense as long as that FSM is actually logging on DMSC, which doesn't seem a good fit. 8128a49a6c6ce4ae - I kick the gscon into the ACTIVE state when a conn is created. That might be taking a shortcut, since I'm not sure how e.g. the conn->user_plane.fi_bts should be populated... c2f90c36c445b2a38 So, e.g. when running './handover_test 1', my code state enabled the logging for them and uncovered the errors: DMSC handover_logic.c:135 SUBSCR_CONN[0x564f2a1d3b70]{INIT}: Event HO_START not permitted and then DMSC handover_logic.c:135 SUBSCR_CONN[0x564f2a1d3b70]{WAIT_CC}: Event HO_START not permitted These two are fixed, and now I'm stuck at: DMSC handover_logic.c:333 SUBSCR_CONN[0x560525a1cb70]{WAIT_HO_COMPL}: Received Event HO_COMPL DMSC bsc_subscr_conn_fsm.c:710 SUBSCR_CONN[0x560525a1cb70]{WAIT_HO_COMPL}: state_chg to WAIT_MDCX_BTS_HO Assert failed fi ../../../../src/osmo-mgw/src/libosmo-mgcp-client/mgcp_client_fsm.c:603 i.e. the handover_test.c is trying to indicate a 'Handover Complete' to the libbsc machinery by calling handover_test.c:send_ho_complete(), and it runs into a wall of the fake conn having conn->user_plane.fi_bts == NULL. At this point I could start figuring out how to fake the fi_bts, but in fact I assume you're more proficient in that area, so please take over from here. Thanks! ~N -- - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Harald Welte

7 years, 5 months

osmo-trx and limesdr mini

by Cyril

Hello, I wonder if someone has got the limesdr mini (hardware v1.1, gateway 1.24) running with osmo-trx ? I've been able to get it working with the non-mini version (the "big" mimo limesdr) but with the mini version it crashes after a few tenth seconds with apparently something going wrong on the tx side (see attachments) Any feedback is welcomed :) Cyril

7 years, 5 months

osmo-trx commit 3da1f83

by Cyril

Hello, How do you select the log level with the libosmocore logging system introduced in commit 3da1f83 ? What is the equivalent of '-l DEBUG' command line option now ? Thanks ! Cyril

7 years, 5 months

Submissions for OsmoDevCon 2018

by Harald Welte

Dear Osmocom community, it's already end of January and OsmoDevCon 2018 in April is getting closer and closer. As indicated before, I would like to group the topics by days and put together at least a rough framework shcedule, so that people with specific interests don't have to be present for four full days to make sure they don't miss anything. So I'd like to re-invite all attendees to consider adding a topic/porposal to the wiki page at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2018#section-9 so that we can group different topic areas and put together a rough schedule outline. A proposal doesn't mean you have to give a talk. It could be anything, including * a talk that you would want to listen to, and you're looking for somebody to give it * a discussion about a certain topic * a workshop / hands on session * lightning talks? Like any community event, OsmoDevCon lives by its contributors. I can't wait to hear about all the things you've been up to. 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)

7 years, 5 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC