Quick Recap of running the 28C3 network

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.

Holger Hans Peter Freyther holger at freyther.de
Thu Dec 29 21:42:28 UTC 2011


Hi all,

just a quick review of things we saw/learned during the congress

* OsmocomBB LAPDm and nanoBTS LAPDm appear to have some communication issues
leading to timeouts (nanoBTS resends a message with N(R) not incremented as a
response to our I frame with Identity Response (or timeout) but with the old
data). We don't have a fix/clear understanding of this yet... looks a bit like
a bug in the nanoBTS firmware (but then other phones appear to work just fine)

* CHANNEL ACTIVATION NACK on a TS. No idea why (maybe we closed a channel with
our auto-timer but the nanoBTS thinks it is open). IIRC the nanoBTS sends us a
report about open channels, we should cross-check every n-th report with our
view of the channels... on top of that we should block failed channels
(configurable, still to do).

* Open channels... E.g. with a nanoBTS reboot or "drop bts connection ", there
was a bug in libosmo-abis that the e1inp_event was not sent as the link was
already taken out of the list of sign links when close is called (fixed in
libosmo-abis and sharing code between rsl.c and ipaccess.c)

* one OML NACK drops all BTS.. The code is there to deal with a crashed BTS to
not have it connected in a bad state... (fixed in zecke/28c3)

* subscriber queue, thanks to jolly's SMS setup we increased the amount of SMS
and there still appear to be paths in the code that do not properly release
the transaction/subscr_put and the queue got stuck. We should start by merging
jolly's sms rework.. and see how we can move the queue out of process...

* Local End Release for SAPI > 0 should be done in the channel release code,
we need to implement T3109... thanks to jolly reading GSM 08.58/04.08 with me
and discussing the normal/abnormal case. I have some work in progress (only
tested the success case) patches in the zecke/28c3 branch.


* I uploaded our scripts but somehow the core dumping does not work correctly
(core_pattern appears to be right though) for running the network

* Purging subscribers from the VLR, we do it too aggressively (on failed
paging), it should take the periodic updating timer into account.

* Sometimes i miss dates.. e.g. when was the channel opened

probably some more things I forgot now, would be a great opportunity if
someone gives a hand in cleaning things up.

holger

PS: jenkins will be back in january, ZFS crashed, the secret key was on the
ZFS, grep didn't find the backup script...




More information about the baseband-devel mailing list