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/.
Alexander Chemeris alexander.chemeris at gmail.comI suspect there is an issue with excessive queuing in OpenBTS 2.8. IIRC more queuing was one of changes between OpenBTS 2.6 and 2.8. My guess is that this queuing might lead to missing frames on receive side, but this should be checked. On Tue, Jan 8, 2013 at 6:51 PM, Kurtis Heimerl <kheimerl at cs.berkeley.edu> wrote: > Anything OpenBTS is doing wrong? > > > On Tuesday, January 8, 2013, Pavel Baturko wrote: >> >> Thanks for explanations and fast fix! It seems that now all works as >> should be. >> >> Pavel >> >> On Tue, Jan 8, 2013 at 12:58 PM, Sylvain Munaut <246tnt at gmail.com> wrote: >>> >>> The fix Andreas just pushed is what I suspected: A missing 'return' >>> that made the "ignore" casei, not really ignored. >>> >>> What seems to happen is: >>> - We respond to the assignement a bit fast it seems and OpenBTS >>> doesn't see the first SABM at all (not in the OpenBTS trace at all) >>> - When OpenBTS sees the SABM, it responds with the UA frame >>> - OpenBTS doesn't send a new frame until quite a bit later, which >>> means the UA frame is resent several times by OpenBTS transceiver >>> application using it's filling table (which is why we see only 1 UA >>> frame in OpenBTS trace but multiple of them in the OsmocomBB trace) >>> - OsmocomBB had a bug where it was supposed to ignore the extraneous >>> UA frame but instead was dropping the connection because of a missing >>> "return" inside the switch statement. >>> >>> Cheers, >>> >>> Sylvain >> >> > -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru