Re: GSM 04.08 L2 pseudo length in ACCH System Information messages

Hi Vadim, On Thu, Dec 14, 2017 at 01:57:11AM +0700, Vadim Yanitskiy wrote: I think you have to review the matching 04.06 / 44.006 together with it. My suspicion is that earlier, 04.06 might not have specified the B4 frame format for downlink SACCH but simply used a normal B frame format (with length octet at L2). Or specified that the B4 frame format includes the length octet. It looks like what used to be a regular UI frame length octet in L2 has at some point been moved into L3 in order to achieve phase1 compatibility by having a length octet that's shorter than the payload length. Old phones will then only look at the "length" number of bytes, where newer phones will look at the full message. If they kept the length octet in L2, L2 would have automatically calculated the length to the total length of the message, including all phase2 extensions. So I guess that's why they came up with that ugly hack of defining L2 as not having a length (only addr + ctrl on downlink sacch) and the L3 including a length octet. * two octets L1 header (power control, TA loop) * one octet ADDR * one octet CTRL * one octet [either L2 length or L2 pseudo length] * the actual L3 payloda The question is just whether you group ADDR+CTRL+LEN into L2 or you put LEN+L3 into L3. If my line of thinking is correct (see https://osmocom.org/issues/3059) we need to make sure * the L2 pseudo-length is included in all SACCH downlink L3 info on RSL, see https://gerrit.osmocom.org/#/c/7220/ * fix the wireshark dissector for SACCH, see https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14105 * fix the wireshark RSL dissector for RSL (SACCH FILL, SACCH INFO MODIFY, CHAN ACT) Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)