Cellular Network Infrastructure » Radio Access Network » OsmoPCU

After the recent changes [1], it was noticed that one of the unit tests fails:

vector1 = 4913e00850884013a8048b2b2b2b2b2b2b2b2b2b2b2b2b
=========Start DECODE===========
+++++++++Finish DECODE (0)++++++++++
=========Start ENCODE=============
+++++++++Finish ENCODE (0)+++++++++++
vector1 = 49 13 e0 08 50 88 40 13 a8 04 8b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 
vector2 = 49 13 01 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 
vector1 == vector2 : FALSE

The unit test basically decodes a set of RLC/MAC blocks, encodes them back, and compares the results with the original inputs. As can be seen, one of the test vectors does not match after such re-encoding - it is Packet Polling Request. Enabling LOGL_DEBUG for DCSN1 reveals some interesting oddities:

=========Start DECODE===========
<0000> gsm_rlcmac.cpp:4995 csnStreamDecoder (type=4): MESSAGE_TYPE = 4 | PAGE_MODE = 3 |  : ID | : End ID | TYPE_OF_ACK = 1 | Padding = 96|8|80|136|64|19|168|4|139|43|43|43|43|43|43|43|43|43|43|43|43|
+++++++++Finish DECODE (0)++++++++++
=========Start ENCODE=============
<0000> gsm_rlcmac.cpp:5310 csnStreamEncoder (type=4): MESSAGE_TYPE = 4 | PAGE_MODE = 3 |  : ID | u.Global_TFI = 0 |  : u.Global_TFI | u.UPLINK_TFI = 0 | u.UPLINK_TFI = 0 |  : End u.Global_TFI |  : End ID | TYPE_OF_ACK = 1 | Padding = 43|43|43|43|43|43|43|43|43|43|43|43|43|43|43|43|43|43|43|43|
+++++++++Finish ENCODE (0)+++++++++++

In particular, the '| : ID | : End ID |' looks suspicious because it's not supposed to be empty. That's how Wireshark dissects the same packet (the CSN.1 codec implementation in OsmoPCU was taken from there):

    GSM RLC/MAC: PACKET_POLLING_REQUEST (4) (Downlink)
        01.. .... = Payload Type (DL): RLC/MAC block contains an RLC/MAC control block that does not include the optional octets of the RLC/MAC control header (1)
        ..00 .... = RRBP: Reserved Block: (N+13) mod 2715648 (0)
        .... 1... = S/P: RRBP field is valid
        .... .001 = USF: 1
        PACKET_POLLING_REQUEST (4) (downlink)
            0001 00.. = MESSAGE_TYPE (DL): PACKET_POLLING_REQUEST (4)
            .... ..11 = PAGE_MODE: Same as before (3)
            ID  <--- This is wrong!
            1... .... = CONTROL_ACK_TYPE: PACKET CONTROL ACKNOWLEDGEMENT message format shall be an RLC/MAC control block
            Padding Bits
                .110 0000  0000 1000  0101 0000  1000 1000 = Padding: 1611157640
                0100 0000  0001 0011  1010 1000  0000 0100 = Padding: 1075030020
                1000 1011  0010 1011  0010 1011  0010 1011 = Padding: 2334862123
                0010 1011  0010 1011  0010 1011  0010 1011 = Padding: 724249387
                0010 1011  0010 1011  0010 1011  0010 1011 = Padding: 724249387
                0010 1011 = Padding: 43

Clause 11.2.12 of 3GPP TS 44.060 defines the identity part as follows:

{    0   < Global TFI : < Global TFI IE > >
  | 10   < TLLI / G-RNTI : bit (32) >
  | 110  < TQI : bit (16) > } 

so either of the listed information elements must be present. The problem seems to be that the packet contains an unknown identity type - '111'B. Fortunately, another implementation of the CSN.1 parser/codec exists - Pycrate. I did a quick decoding attempt, and it throws an exception! This confirms my assumption that the packet itself is malformed. I believe our code should also stop decoding the bit stream and return a error. Wireshark needs to be fixed too.

[1] https://git.osmocom.org/osmo-pcu/commit/?id=5cb002f0ef6dfd43ae030ffef66a8dc9f8f72ada (Ia0f8cc224a4c38e80699f834fd83d4c0d99322ea)