7 Jan
2013
7 Jan
'13
9:04 p.m.
Hi list,
I'm trying to connect my OsmocomBB phone to OpenBTS and I always
got MDL-Error in mobile app log when MS trying to perform LU.
Part of log (full mobile log in attach):
<0001> gsm48_rr.c:355 new state connection pending -> dedicated
<0005> gsm48_mm.c:3911 (ms 1) Received 'RR_EST_CNF' from RR in state wait
for RR connection (location updating) (sapi 0)
<0005> gsm48_mm.c:404 starting T3210 (loc. upd. timeout) with 20.0 seconds
<0005> gsm48_mm.c:924 new state wait for RR connection (location updating)
-> location updating initiated
<0001> gsm48_rr.c:4984 MDL-Error (cause 3) ignoring
<0001> gsm48_rr.c:4987 MDL-Error (cause 3) aborting
<0001> gsm48_rr.c:355 new state dedicated -> idle
In wireshark trace (from OpenBTS, attached) I see that MS sends LURequest
(packet 359) and BTS responds with LUAccept (packet 440) but MS never
receive this message because of error.
As I understand this is "unsolicited UA response" from 08.58 (9.3.22) but I
do not know how to fix that or properly debug.
I'm using latest sylvain/testing and official OpenBTS 2.8. "Usual" (not
with OsmocomBB) phones works with OpenBTS fine and OsmocomBB phones works
fine with "usual" (not OpenBTS) networks.
Thanks,
Pavel
8 Jan
8 Jan
1:01 a.m.
Hi,
In wireshark trace (from OpenBTS, attached) I see that
MS sends LURequest
(packet 359) and BTS responds with LUAccept (packet 440) but MS never
receive this message because of error.
Can you send a gsmtap trace from the mobile side as well ? (using the
-i 127.0.0.1 option).
Cheers,
Sylvain
11:13 a.m.
Hi,
Attached new mobile log + trace from both OpenBTS and OsmocomBB (since I'm
using 1 lo interface for them, packets from/to 127.0.0.1 - OpenBTS, from/to
127.0.0.2 - OsmocomBB). LURequests in packets 278, 380 and following.
Thanks,
Pavel
On Tue, Jan 8, 2013 at 12:01 AM, Sylvain Munaut <246tnt(a)gmail.com> wrote:
Hi,
In wireshark trace (from OpenBTS, attached) I see
that MS sends LURequest
(packet 359) and BTS responds with LUAccept (packet 440) but MS never
receive this message because of error.
Can you send a gsmtap trace from the mobile side as well ? (using the
-i 127.0.0.1 option).
Cheers,
Sylvain
1:47 p.m.
Pavel Baturko wrote:
Hi,
Attached new mobile log + trace from both OpenBTS and OsmocomBB (since
I'm using 1 lo interface for them, packets from/to 127.0.0.1 -
OpenBTS, from/to 127.0.0.2 - OsmocomBB). LURequests in packets 278,
380 and following.
hi pavel,
i can see that openbts did not manage to reply to SABM within the
required time (we use 1 second timeout). this causes a second SABM to be
transmitted by the mobile. the openbts replies with UA twice, because it
assumes that the first UA was not received by mobile. this delay between
mobile and openbts is not nice, but should not cause any link failure.
i just committed a fix to master branch of osmocombb. the "unsoliciated
UA response" is something that must not cause link failure. there are
other causes that may not cause link failures, so they are ignored too.
@holger: please revert your patch in your branch and use my fix.
regards,
andreas
1:58 p.m.
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
2:02 p.m.
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(a)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
3:51 p.m.
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@gmail.com<javascript:_e({},
'cvml', '246tnt(a)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
4:40 p.m.
Hi,
Anything OpenBTS is doing wrong?
Well, kind of.
Seems that when the L2 doesn't have anything "new" to send, it doesn't
send anything, which causes the filler table to repeat the last
message. Now AFAIU, it is the intended behavior, but all in all I'm
not convinced it's a good idea. It can help if the process generating
the burst doesn't send them to transceiver in time (and so they'll be
'replayed' a multiframe later), but that only works IF:
- The message are time independent (eg some messages on CCCH need to
at the right time (longer than 1 multiframe) to be in the good paging
group, each SI message is supposed to be in some specific order, ...)
- No new L1 bursts are generated in the mean time that would
overwrite the non transmitted bursts from the filler table
- The L1FEC was really too late to TX message to the transceiver to
send them in time
I'm kind of wondering how often all those 3 conditions are met and
this filler table actually helps.
If instead of retransmitting the last L2 packet, it would just
transmit a filler, then if the L1FEC was late, the packet would be
lost and the LAPDm recovery would kick-in.
As it is now, it _should_ work since the LAPDm receiver is essentially
supposed to ignore all those redudant packet. But that doesn't mean it
won't trigger weird bugs in the stack.
Cheers,
Sylvain
11:19 p.m.
Sylvain -
There was an unintentional change in filler table behavior between 2.6 and 2.8, probably
as a result of modifications to support multi-ARFCN operation. A known symptom of this
change in normal OpenBTS operation is the occasional failure of an assignment to a TCH for
some MS basebands, most notably Nokia DTC4 series handsets, like the 1600. We are looking
for the bug ourselves now.
-- David
On Jan 8, 2013, at 7:40 AM, Sylvain Munaut wrote:
Hi,
Anything OpenBTS is doing wrong?
Well, kind of.
Seems that when the L2 doesn't have anything "new" to send, it doesn't
send anything, which causes the filler table to repeat the last
message. Now AFAIU, it is the intended behavior, but all in all I'm
not convinced it's a good idea. It can help if the process generating
the burst doesn't send them to transceiver in time (and so they'll be
'replayed' a multiframe later), but that only works IF:
- The message are time independent (eg some messages on CCCH need to
at the right time (longer than 1 multiframe) to be in the good paging
group, each SI message is supposed to be in some specific order, ...)
- No new L1 bursts are generated in the mean time that would
overwrite the non transmitted bursts from the filler table
- The L1FEC was really too late to TX message to the transceiver to
send them in time
I'm kind of wondering how often all those 3 conditions are met and
this filler table actually helps.
If instead of retransmitting the last L2 packet, it would just
transmit a filler, then if the L1FEC was late, the packet would be
lost and the LAPDm recovery would kick-in.
As it is now, it _should_ work since the LAPDm receiver is essentially
supposed to ignore all those redudant packet. But that doesn't mean it
won't trigger weird bugs in the stack.
Cheers,
Sylvain 
6:29 p.m.
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(a)cs.berkeley.edu> wrote:
Anything OpenBTS is doing wrong?
On Tuesday, January 8, 2013, Pavel Baturko wrote:
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru
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(a)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
10:53 a.m.
On Mon, Jan 07, 2013 at 08:04:50PM +0000, Pavel Baturko wrote:
Hi,
<0001> gsm48_rr.c:4984 MDL-Error (cause 3)
ignoring
<0001> gsm48_rr.c:4987 MDL-Error (cause 3) aborting
<0001> gsm48_rr.c:355 new state dedicated -> idle
It is something I experienced recently as well and created this[1] to
improve the warning. In case of the osmo-bts this error was triggered
by a wrong filling frame[2]. Make sure that OpenBTS is sending it as
a command and not as a response.
holger
[1] http://cgit.osmocom.org/cgit/osmocom-bb/commit/?h=zecke/work-with-nitb
[2]
http://cgit.osmocom.org/cgit/osmo-bts/commit/?id=6ae49691afc4dc067f9dfb6c4a…
1:31 p.m.
Hi,
I tried to use OpenBTS 2.6 and OsmocomBB phone works fine with it! Seems
that something wrong with OpenBTS 2.8.. But "usual" phones works with it.
Holger, thanks for your answer, I'll try find problem source.
All, does anyone use OpenBTS 2.8 with OsmocomBB?
Thanks,
Pavel
On Tue, Jan 8, 2013 at 9:53 AM, Holger Hans Peter Freyther <
holger(a)freyther.de> wrote:
On Mon, Jan 07, 2013 at 08:04:50PM +0000, Pavel
Baturko wrote:
Hi,
<0001> gsm48_rr.c:4984 MDL-Error (cause 3)
ignoring
<0001> gsm48_rr.c:4987 MDL-Error (cause 3) aborting
<0001> gsm48_rr.c:355 new state dedicated -> idle
It is something I experienced recently as well and created this[1] to
improve the warning. In case of the osmo-bts this error was triggered
by a wrong filling frame[2]. Make sure that OpenBTS is sending it as
a command and not as a response.
holger
[1] http://cgit.osmocom.org/cgit/osmocom-bb/commit/?h=zecke/work-with-nitb
[2]
http://cgit.osmocom.org/cgit/osmo-bts/commit/?id=6ae49691afc4dc067f9dfb6c4a…
4132
days inactive
4133
days old
baseband-devel@lists.osmocom.org
11 comments
7 participants
participants (7)
-
Alexander Chemeris -
David A. Burgess -
Holger Hans Peter Freyther -
jolly -
Kurtis Heimerl -
Pavel Baturko -
Sylvain Munaut