Wireshark-bugs: [Wireshark-bugs] [Bug 9436] New: Mobile IPv6 decoding fails on TLV MHLLA
Date: Fri, 15 Nov 2013 00:08:03 +0000
Bug ID 9436
Summary Mobile IPv6 decoding fails on TLV MHLLA
Classification Unclassified
Product Wireshark
Version 1.11.x (Experimental)
Hardware x86
OS Windows 7
Status UNCONFIRMED
Severity Minor
Priority Low
Component Dissection engine (libwireshark)
Assignee bugzilla-admin@wireshark.org
Reporter fossinater2000@hotmail.com

Created attachment 12092 [details]
Here is an example pcap

Build Information:
Version 1.8.5 (SVN Rev 47350 from /trunk-1.8)

Copyright 1998-2013 Gerald Combs <gerald@wireshark.org> and contributors.
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 (64-bit) with GTK+ 2.24.14, with Cairo 1.10.2, with Pango 1.30.1, with
GLib 2.34.1, with WinPcap (4_1_2), with libz 1.2.5, without POSIX capabilities,
with SMI 0.4.8, with c-ares 1.7.1, with Lua 5.1, without Python, with GnuTLS
2.12.18, with Gcrypt 1.4.6, without Kerberos, with GeoIP, with PortAudio
V19-devel (built Jan 29 2013), with AirPcap.

Running on 64-bit Windows 7 Service Pack 1, build 7601, with WinPcap version
4.1.2 (packet.dll version 4.1.0.2001), based on libpcap version 1.0 branch
1_0_rel0b (20091008), GnuTLS 2.12.18, Gcrypt 1.4.6, without AirPcap.

Built using Microsoft Visual C++ 10.0 build 40219

Wireshark is Open Source Software released under the GNU General Public
License.

Check the man page and http://www.wireshark.org for more information.
--
The mobile ipv6 decoding is failing when it encounters the TLV of type
MIP6_MHLLA (0x07). I took a look at the code and in packet-mip6.c special logic
is being done to treat this type differently:
"/* RFC4068 Section 6.4.4
 *   Length         The size of this option in octets not including the
 *                  Type, Length, and Option-Code fields.
 */
 if (opt == MIP6_MHLLA)
    offset += len + 2 + FMIP6_LLA_OPTCODE_LEN;
 else
    offset += len + 2;"

However RFC4068 was obsoleted by RFC 5268 and in the updated version
http://tools.ietf.org/html/rfc5268#section-6.5.3

It clearly shows that the length includes every thing but the type, and length
fields.

So I think the solution is to remove the special logic that is in the code to
handle MIP6_MHLLA. It has the same form as any other tlv.

I have attached a pcap which is failing right now.


You are receiving this mail because:
  • You are watching all bug changes.