MDL-Error in case of OsmocomBB+OpenBTS
alexander.chemeris at gmail.com
Tue Jan 8 17:29:34 UTC 2013
I 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.
>> 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.
CEO, Fairwaves LLC / ООО УмРадио
More information about the baseband-devel