System Information on SACCH missing L2 Pseudo-Length
Something seems odd about our SI5/SI6 messages.
The message on the downlink SACCH is structured as follows:
- two octets L1 header
- two octets "LAPDm B4" frame format: Address + Control Octet
- 23-4=19 octets of L3 payload (as specified in TS 44.018), consisting of
- one octet L2 pseudo-length
- 18 octets of actual L3 message
It appears that the messages that we send from the Osmocom stack are missing the L2 pseudo-length. This maybe related to https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14105
- wireshark patch for RSL
- wireshark patch for SACCH/LAPDm
- patch for legacy openbsc.git
sysinfo: Fix regression causing missing L2 Pseudo-Length in SI5/SI6
Fixes a regression in the code generating SI5* and SI6 on SACCH,
where the L@ pseudo-length is not part of the 'struct' definition
we have in gsm_04_08.h and hence has to be encoded manually into
the first byte of the SI buffer.
We were doing this correctly until April 2017, when the following
patch was merged:
Author: Max <email@example.com>
Date: Wed Apr 12 15:30:54 2017 +0200
Prepare for extended SI2quater support
This patch cacidentially overwrote the l2_plen that was just enoded,
as the 'struct' was no longer pointing to 'output' (si_buf+1), but
now directly to the start of the si_buf.
NOTE: The Wireshark RSL dissector (and more recently also LAPDm)
contain a similar bug, so the SACCH will not be decoded correctly
after applying this patch. Nevertheless, it's correct.
#3 Updated by laforge over 2 years ago
- Status changed from New to In Progress
- % Done changed from 0 to 10
the interesting question is: how does the format look on Abis? According to my reading of the specs:
- L3 Info TLV length given by TS 48.058 for SACCH FILLING is "22", where 1 byte is tag, and 2 bytes are length, i.e. 19 bytes left for actual payload
- this indicates the full 19 bytes including pseudo-length are to be included
- The actual SI5 / SI6 definitions in TS 44.018 also include the L2 pseodo length as part of the SI message
I also found some old pcap files of a proprietary ip.access BSC, which confirms that assumption.So it seems to me that
- OsmoBSC is lacking the L2 pseudo-length field as first byte of the L3 INFO
- the wireshark packet-rsl.c decoder is broken as it assumes no l2 plen
- we impleemnted our code to comply with wireshark, inheriting the bug
- the wireshark LAPDm decoder was "fixed" by me to also comply with that broken assumption
So now, wiershark RSL, wiershark GSMTAP/LAPDm and OsmoBSC are all broken. yay. :(
#7 Updated by neels over 2 years ago
- Project changed from OsmoBSC to Cellular Network Infrastructure
- Assignee changed from neels to laforge
- % Done changed from 30 to 80
Just tested with this patch as well as https://gerrit.osmocom.org/#/c/7218/ (it's already merged to osmo-bts master, but let me mention that it was used in the test) and: YES! Finally the measurement reports survive a handover! No matter what I do, the neighbor lists are reliably populated. Excellent! Let me add a few percent there.
#8 Updated by fixeria over 2 years ago
this is probably related to:
my plan is to revert the:
because I was referring an outdated spec version and the way of Osmocom stack.
#9 Updated by laforge over 2 years ago
- Checklist item wireshark patch for RSL added
- Checklist item wireshark patch for SACCH/LAPDm added
- Project changed from Cellular Network Infrastructure to OpenBSC
- % Done changed from 80 to 90
ok, have merged the related patch now. Let's abuse this ticket until wireshark patches are written + tested.
#12 Updated by laforge over 2 years ago
On Mon, Mar 12, 2018 at 01:16:53PM +0000, fixeria [REDMINE] wrote:
My question was lost because the 7226 was merged, but anyway,
it wasn't lost, I read it ;)
laforge, what do you think about introducing a new structure with l2_plen?
I don't think it's worth it. Too much confusion?