--- Comment #5 from Harald Welte <> ---
Sorry for the late response here.  The issue is rather complicated, but has now
shown up several other places like and

In short:
* The wireshark RSL dissector has been wrong regarding the decoding of the "L3
Info" Information Element of SACCH filling on Abis.  It expects that L3 Info
payload to be _without_ the L2 pseudo-length field at the beginning
* OpenBSC / OsmoBSC introduced a regression in April 2017 which removed the L2
pseudo-length from the RSL side.  It probably was never detected as in
wireshark, it just looked great
* As wireshark decoded RSL correctly, but not the GSMTAP / Um / air interface
traces, the LAPDm dissector was changed in to also remove that one byte

The last change is not without merit, as 3GPP TS 44.006 specifies explicitly
that the B4 frame format is used on downlink SACCH, and that frame format has
no length octet. Rather, the length octet magically appeared in the sytem
information messages themselves.

So from a spec point of view, it seemed that initially, a length octet was part
of the L2 header, but then has subsequently removed from the spec, while that
very same length octet of the same position of the message was later added to
the beginning of the layer 3 information.  That change likely happened around
the GSM phase1 -> phase2 change in the 1990ies and likely predates any
wireshark code.

So my line of thinking is:
* fix OsmoBSC to encode the messages properly again (in progress)
* fix wireshark dissector for RSL
* fix wireshark dissector for LAPDm/RR stacking on SACCH (i.e. keep the 2-byte
B4 frame format introduced in as it is
correct since the late 1990ies but adjust the dissector stacked on top of it

You are receiving this mail because:
You are watching all bug changes.
Sent via:    Wireshark-bugs mailing list <>

Reply via email to