Wireshark · Wireshark-users: [Wireshark-users] 6lowpan fragmented packet dissecting(or reassemble) problem

Wireshark-users: [Wireshark-users] 6lowpan fragmented packet dissecting(or reassemble) problem

Date: Thu, 2 Mar 2017 17:29:23 +0900
Hello list.

I'm writing PANA protocol in the ZigBee environment.
When I attempt to analysis protocol, wireshark said fragemented packet
is malformed, but I can't see the why.
(Dissecting unfragmented packet is OK.)

Let's see dissected packet.

<snip - first fragemented packet>
IEEE 802.15.4 Data, Dst: 0x0001, Src: 00:00:00_00:00:01:00:02
    Frame Control Field: 0xd861, Frame Type: Data, Acknowledge
Request, PAN ID Compression, Destination Addressing Mode:
Short/16-bit, Frame Version: IEEE Std 802.15.4-2006, Source Addressing
Mode: Long/64-bit
        .... .... .... .001 = Frame Type: Data (0x1)
        .... .... .... 0... = Security Enabled: False
        .... .... ...0 .... = Frame Pending: False
        .... .... ..1. .... = Acknowledge Request: True
        .... .... .1.. .... = PAN ID Compression: True
        .... ...0 .... .... = Sequence Number Suppression: False
        .... ..0. .... .... = Information Elements Present: False
        .... 10.. .... .... = Destination Addressing Mode: Short/16-bit (0x2)
        ..01 .... .... .... = Frame Version: IEEE Std 802.15.4-2006 (1)
        11.. .... .... .... = Source Addressing Mode: Long/64-bit (0x3)
    Sequence Number: 107
    Destination PAN: 0x2541
    Destination: 0x0001
    Extended Source: 00:00:00_00:00:01:00:02 (00:00:00:00:00:01:00:02)
    Frame Check Sequence (TI CC24xx format): FCS OK
        RSSI: 37 dB
        FCS Valid: True
        LQI Correlation Value: 106
6LoWPAN
    Fragmentation Header
        1100 0... = Pattern: First fragment (0x18)
        Datagram size: 116
        Datagram tag: 0x1d0c
    IPHC Header
        011. .... = Pattern: IP header compression (0x03)
        ...1 1... .... .... = Traffic class and flow label: Version,
traffic class, and flow label compressed (0x3)
        .... .0.. .... .... = Next header: Inline
        .... ..00 .... .... = Hop limit: Inline (0x0)
        .... .... 0... .... = Context identifier extension: False
        .... .... .1.. .... = Source address compression: Stateful
        .... .... ..11 .... = Source address mode: Compressed (0x0003)
        .... .... .... 0... = Multicast address compression: False
        .... .... .... .1.. = Destination address compression: Stateful
        .... .... .... ..11 = Destination address mode: Compressed (0x0003)
    Next header: UDP (0x11)
    Hop limit: 63
    Source: ::200:0:1:2
    Destination: ::2541:ff:fe00:1
[Malformed Packet: 6LoWPAN]
    [Expert Info (Error/Malformed): Malformed Packet (Exception occurred)]
        [Malformed Packet (Exception occurred)]
        [Severity level: Error]
        [Group: Malformed]
Frame (125 bytes):
0000  61 d8 6b 41 25 01 00 02 00 01 00 00 00 00 00 c0   a.kA%...........
0010  74 1d 0c 78 77 11 3f 02 cc 02 cc 00 70 d1 fa 00   t..xw.?.....p...
0020  00 00 68 00 00 00 02 12 f7 16 51 00 00 00 04 00   ..h.......Q.....
0030  02 00 00 00 50 00 00 02 01 00 50 0d 00 16 03 03   ....P.....P.....
0040  00 45 01 00 00 41 03 03 58 b0 01 40 f2 c0 ac b0   .E...A..X..@....
0050  fa 10 2b 12 56 52 81 81 64 3a 51 1b d6 d6 6f 7b   ..+.VR..d:Q...o{
0060  08 2e ea f1 31 f1 cd 69 00 00 02 c0 ae 01 00 00   ....1..i........
0070  16 00 0d 00 04 00 02 04 03 00 0a 25 ea            ...........%.
Decompressed 6LoWPAN IPHC (140 bytes):
0000  60 00 00 00 00 4c 11 3f 00 00 00 00 00 00 00 00   `....L.?........
0010  02 00 00 00 00 01 00 02 00 00 00 00 00 00 00 00   ................
0020  25 41 00 ff fe 00 00 01 02 cc 02 cc 00 70 d1 fa   %A...........p..
0030  00 00 00 68 00 00 00 02 12 f7 16 51 00 00 00 04   ...h.......Q....
0040  00 02 00 00 00 50 00 00 02 01 00 50 0d 00 16 03   .....P.....P....
0050  03 00 45 01 00 00 41 03 03 58 b0 01 40 f2 c0 ac   ..E...A..X..@...
0060  b0 fa 10 2b 12 56 52 81 81 64 3a 51 1b d6 d6 6f   ...+.VR..d:Q...o
0070  7b 08 2e ea f1 31 f1 cd 69 00 00 02 c0 ae 01 00   {....1..i.......
0080  00 16 00 0d 00 04 00 02 04 03 00 0a               ............
</snip>

<snip - next fragemented packet>
IEEE 802.15.4 Data, Dst: 0x0001, Src: 00:00:00_00:00:01:00:02
    Frame Control Field: 0xd861, Frame Type: Data, Acknowledge
Request, PAN ID Compression, Destination Addressing Mode:
Short/16-bit, Frame Version: IEEE Std 802.15.4-2006, Source Addressing
Mode: Long/64-bit
        .... .... .... .001 = Frame Type: Data (0x1)
        .... .... .... 0... = Security Enabled: False
        .... .... ...0 .... = Frame Pending: False
        .... .... ..1. .... = Acknowledge Request: True
        .... .... .1.. .... = PAN ID Compression: True
        .... ...0 .... .... = Sequence Number Suppression: False
        .... ..0. .... .... = Information Elements Present: False
        .... 10.. .... .... = Destination Addressing Mode: Short/16-bit (0x2)
        ..01 .... .... .... = Frame Version: IEEE Std 802.15.4-2006 (1)
        11.. .... .... .... = Source Addressing Mode: Long/64-bit (0x3)
    Sequence Number: 108
    Destination PAN: 0x2541
    Destination: 0x0001
    Extended Source: 00:00:00_00:00:01:00:02 (00:00:00:00:00:01:00:02)
    Frame Check Sequence (TI CC24xx format): FCS OK
        RSSI: 37 dB
        FCS Valid: True
        LQI Correlation Value: 106
6LoWPAN
    Fragmentation Header
        1110 0... = Pattern: Fragment (0x1c)
        Datagram size: 116
        Datagram tag: 0x1d0c
        Datagram offset: 104
Data (12 bytes)
    Data: 000400020017000b00020100
    [Length: 12]
0000  61 d8 6c 41 25 01 00 02 00 01 00 00 00 00 00 e0   a.lA%...........
0010  74 1d 0c 0d 00 04 00 02 00 17 00 0b 00 02 01 00   t...............
0020  25 ea                                             %.
</snip>

UDP packet length is 112 bytes (0x0070). (and datagram size is 116
bytes including IPHC header)
I thought decompressed IP header length will be also 112 bytes but
wireshark said 76 bytes (0x004c).
Where it comes from?
I suspect that's the reason that packet is malformed, but don't know the why.

Compared with rfc4944(5.3) and 6282(3.1), it looks like no problem on
the raw packet.

Could anyone help figure it out?

Thanks in advance.

- H.Jin



In addition, dissecting more fragmented packet is just reported as bad length.
In this case, IP header length is calculated to 784 bytes(0x0310), and
still 36 bytes smaller than UDP length 820 bytes (0x0334).
Every packet is fragemented by 104 bytes, but first fragmented packet
was dissected to 140 bytes length.

<snip - last fragmented packet of another example>
IEEE 802.15.4 Data, Dst: 0x0001, Src: 00:00:00_00:00:01:00:02
    Frame Control Field: 0xd861, Frame Type: Data, Acknowledge
Request, PAN ID Compression, Destination Addressing Mode:
Short/16-bit, Frame Version: IEEE Std 802.15.4-2006, Source Addressing
Mode: Long/64-bit
        .... .... .... .001 = Frame Type: Data (0x1)
        .... .... .... 0... = Security Enabled: False
        .... .... ...0 .... = Frame Pending: False
        .... .... ..1. .... = Acknowledge Request: True
        .... .... .1.. .... = PAN ID Compression: True
        .... ...0 .... .... = Sequence Number Suppression: False
        .... ..0. .... .... = Information Elements Present: False
        .... 10.. .... .... = Destination Addressing Mode: Short/16-bit (0x2)
        ..01 .... .... .... = Frame Version: IEEE Std 802.15.4-2006 (1)
        11.. .... .... .... = Source Addressing Mode: Long/64-bit (0x3)
    Sequence Number: 116
    Destination PAN: 0x2541
    Destination: 0x0001
    Extended Source: 00:00:00_00:00:01:00:02 (00:00:00:00:00:01:00:02)
    Frame Check Sequence (TI CC24xx format): FCS OK
        RSSI: 37 dB
        FCS Valid: True
        LQI Correlation Value: 106
6LoWPAN
    Fragmentation Header
        1110 0... = Pattern: Fragment (0x1c)
        Datagram size: 824
        Datagram tag: 0x1d0d
        Datagram offset: 728
    [8 Message fragments (824 bytes): #41(140), #43(104), #45(104),
#47(104), #49(104), #51(104), #53(104), #55(96)]
        [Frame: 41, payload: 0-139 (140 bytes)]
        [Frame: 43, payload: 104-207 (104 bytes)]
            [Message fragment overlap: True]
            [Message fragment overlapping with conflicting data: True]
        [Frame: 45, payload: 208-311 (104 bytes)]
        [Frame: 47, payload: 312-415 (104 bytes)]
        [Frame: 49, payload: 416-519 (104 bytes)]
        [Frame: 51, payload: 520-623 (104 bytes)]
        [Frame: 53, payload: 624-727 (104 bytes)]
        [Frame: 55, payload: 728-823 (96 bytes)]
        [Message fragment count: 8]
        [Reassembled 6LoWPAN length: 824]
Internet Protocol Version 6, Src: ::200:0:1:2, Dst: ::2541:ff:fe00:1
    0110 .... = Version: 6
    .... 0000 0000 .... .... .... .... .... = Traffic class: 0x00
(DSCP: CS0, ECN: Not-ECT)
        .... 0000 00.. .... .... .... .... .... = Differentiated
Services Codepoint: Default (0)
        .... .... ..00 .... .... .... .... .... = Explicit Congestion
Notification: Not ECN-Capable Transport (0)
    .... .... .... 0000 0000 0000 0000 0000 = Flow label: 0x00000
    Payload length: 784
    Next header: UDP (17)
    Hop limit: 63
    Source: ::200:0:1:2
    Destination: ::2541:ff:fe00:1
    [Source GeoIP: Unknown]
    [Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: 716, Dst Port: 716
    Source Port: 716
    Destination Port: 716
    Length: 820 (bogus, payload length 784)
        [Expert Info (Error/Malformed): Bad length value 820 > IP
payload length]
            [Bad length value 820 > IP payload length]
            [Severity level: Error]
            [Group: Malformed]
    Checksum: 0xc1f9 [unverified]
    [Checksum Status: Unverified]
    [Stream index: 0]
Data (776 bytes)
    Data: 0000032c0000000212f71651000000050002000003130000...
    [Length: 776]
Frame (118 bytes):
0000  61 d8 74 41 25 01 00 02 00 01 00 00 00 00 00 e3   a.tA%...........
0010  38 1d 0d 5b 00 00 00 00 00 00 00 00 00 00 00 00   8..[............
0020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0040  00 00 00 00 00 00 00 00 14 03 03 00 01 01 16 03   ................
0050  03 00 20 80 00 00 00 00 00 00 05 64 4c 11 0d 32   .. ........dL..2
0060  1a d5 25 be 4a 38 2c c7 5a 12 10 e6 e9 03 35 9f   ..%.J8,.Z.....5.
0070  fd 97 c7 00 25 ea                                 ....%.
Reassembled 6LoWPAN (824 bytes):
0000  60 00 00 00 03 10 11 3f 00 00 00 00 00 00 00 00   `......?........
0010  02 00 00 00 00 01 00 02 00 00 00 00 00 00 00 00   ................
0020  25 41 00 ff fe 00 00 01 02 cc 02 cc 03 34 c1 f9   %A...........4..
0030  00 00 03 2c 00 00 00 02 12 f7 16 51 00 00 00 05   ...,.......Q....
0040  00 02 00 00 03 13 00 00 02 02 03 13 0d 00 16 03   ................
0050  03 02 47 0b 00 02 43 00 02 40 00 02 3d 30 82 02   ..G...C..@..=0..
0060  39 30 82 01 e0 a0 03 02 01 02 02 01 02 30 0a 06   90...........0..
0070  08 2a 86 48 ce 3d 04 03 02 30 5f 31 0b 30 09 06   .*.H.=...0_1.0..
0080  03 55 04 06 13 02 4b 52 31 11 30 0f 06 03 55 04   .U....KR1.0...U.
...................
</snip>
Follow-Ups:
- Re: [Wireshark-users] 6lowpan fragmented packet dissecting(or reassemble) problem
  - From: Jaap Keuter
Next by Date: Re: [Wireshark-users] 6lowpan fragmented packet dissecting(or reassemble) problem
Next by thread: Re: [Wireshark-users] 6lowpan fragmented packet dissecting(or reassemble) problem
Index(es):
- Date
- Thread