Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: [Wireshark-dev] Problem of packet-per.c on ASN.1 PER Encoding

From: Sean <yunjnz@xxxxxxxxx>
Date: Tue, 14 Jul 2009 18:36:41 -0700 (PDT)
Hi,

We're using the LTE RRC dissector(packet-lte-rrc.c) recently and we find a
problem while parsing the RRC Connection Request,
Following is the definition of the RRC Connection Request:

-- ASN1START

RRCConnectionRequest ::=                        SEQUENCE {
        criticalExtensions                                      CHOICE {
                rrcConnectionRequest-r8                        
RRCConnectionRequest-r8-IEs,
                criticalExtensionsFuture                        SEQUENCE {}
        }
}

RRCConnectionRequest-r8-IEs ::=         SEQUENCE {
        ue-Identity                                                    
InitialUE-Identity,
        establishmentCause                                     
EstablishmentCause,
        spare                                                           BIT
STRING (SIZE (1))
}

InitialUE-Identity ::=                          CHOICE {
        s-TMSI                                                          S-TMSI,
        randomValue                                                     BIT
STRING (SIZE (40))
}

EstablishmentCause ::=                          ENUMERATED {
                                                                               
emergency, highPriorityAccess, mt-Access, mo-Signalling,
                                                                               
mo-Data, spare3, spare2, spare1}

-- ASN1STOP

Totally there are 6 bytes in the encoded packet, but the dissector indicates
"Malformed Packet" even the 6 bytes data is present.
It seems that the packet-per.c wants to read 2 more bytes(line 226 in
packet-per.c "word = tvb_get_ntohs(tvb,boffset+i) << shift1;") for the single
bit "spare" field and thus not enough data available.
Attached is the patch for the file and it works fine for this packet.
Would anyone have a look and confirm if the patch properly corrects the
issue?
Or is there any existing patch on this and/or any other issues?

Thanks,
Sean


      

Attachment: packet-per.c.patch
Description: Binary data