Wireshark-bugs: [Wireshark-bugs] [Bug 11368] New: 6LoWPAN IPHC IPv6 fragment headers not decompr
| Bug ID |
11368
|
| Summary |
6LoWPAN IPHC IPv6 fragment headers not decompressed correctly
|
| Product |
Wireshark
|
| Version |
1.99.x (Experimental)
|
| Hardware |
All
|
| OS |
All
|
| Status |
UNCONFIRMED
|
| Severity |
Normal
|
| Priority |
Low
|
| Component |
Dissection engine (libwireshark)
|
| Assignee |
bugzilla-admin@wireshark.org
|
| Reporter |
kevin.bracey@arm.com
|
Build Information:
Version 1.99.0ARM-Thread (v1.99.0-rc1-1946-g712d9af from master)
Copyright 1998-2014 Gerald Combs <gerald@wireshark.org> and contributors.
License GPLv2+: GNU GPL version 2 or later
<http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled (32-bit) with GTK+ 2.24.23, with Cairo 1.10.2, with Pango 1.34.0, with
WinPcap (4_1_3), with libz 1.2.5, with GLib 2.38.0, with SMI 0.4.8, with c-ares
1.9.1, with Lua 5.2, with GnuTLS 2.12.18, with Gcrypt 1.4.6, with MIT Kerberos,
with GeoIP, with PortAudio V19-devel (built Sep 26 2014), with AirPcap.
Running on 64-bit Windows 7 Service Pack 1, build 7601, with WinPcap version
4.1.3 (packet.dll version 4.1.0.2980), based on libpcap version 1.0 branch
1_0_rel0b (20091008), with GnuTLS 2.12.18, with Gcrypt 1.4.6, without AirPcap.
Intel(R) Core(TM) i7-4800MQ CPU @ 2.70GHz (with SSE4.2), with 16068MB of
physical memory.
Built using Microsoft Visual C++ 10.0 build 40219
--
The 6LoWPAN dissector treats IPHC-compressed IPv6 Fragment Headers exactly the
same as other compressed extension headers.
Specifically, it acts as if the second byte of the Fragment Header is a
"length" byte, which it is not - it is a reserved byte:
RFC 2460:
Reserved 8-bit reserved field. Initialized to zero for
transmission; ignored on reception.
RFC 6282:
The Length field contained in a compressed IPv6 Extension Header
indicates the number of octets that pertain to the (compressed)
extension header following the Length field. Note that this changes
the Length field definition in [RFC2460] from indicating the header
size in 8-octet units, not including the first 8 octets. Changing
the Length field to be in units of octets removes wasteful internal
fragmentation.
RFC 6282 fails to point out that Fragment Headers don't have a Length field, so
this transformation does not apply to them. (It's possible that the authors of
the RFC didn't realise it either).
If the Reserved field is set to zero, then yes, it does look as if it could be
the Length field for the 8-byte Fragment Header, but it isn't. It's reserved,
and the IPHC compression/decompression cycle should pass through any value in
the field undamaged.
Because Wireshark treats the reserved byte as a length byte, if it's set to
"06" in the compressed form, it is converted to "00" in the decompressed. If
it's set to "00", the fragment header seems to end up 14 bytes long in the
decompressed packet, and the rest of the IPv6 dissection fails.
Correct behaviour is for this byte to be copied into the decompressed packet
unmodified, and IPv6 Fragment Headers to have constant length 8, not have
length based on the value of that byte.
The attached trace of a fragmented ping shows the issue - Wireshark does not
dissect it. Note that the fragments are transmitted in reverse order, and only
the initial (second-transmitted) fragments have their Fragment Header
IPHC-compressed (there is no point compressing a non-initial Fragment Header,
as there are no headers following it).
You are receiving this mail because:
- You are watching all bug changes.
