https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7355
Summary: Showing IPv6 Hdr Ext Length instead of the full length
of the extension header
Product: Wireshark
Version: SVN
Platform: All
OS/Version: All
Status: NEW
Severity: Minor
Priority: Low
Component: Dissection engine (libwireshark)
AssignedTo: bugzilla-admin@xxxxxxxxxxxxx
ReportedBy: anwilli5@xxxxxxxx
Created attachment 8580
--> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=8580
Packet capture with several IPv6 extension headers
Build Information:
TShark 1.9.0 (SVN Rev 43187 from /trunk)
Copyright 1998-2012 Gerald Combs <gerald@xxxxxxxxxxxxx> 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 (32-bit) with GLib 2.30.3, with libpcap, with libz 1.2.5, without
POSIX
capabilities, without SMI, without c-ares, without ADNS, without Lua, without
Python, without GnuTLS, without Gcrypt, without Kerberos, without GeoIP.
Running on Linux 3.3.7-1.fc16.i686, with locale en_US.UTF-8, with libpcap
version 1.1.1, with libz 1.2.5.
Built using gcc 4.6.3 20120306 (Red Hat 4.6.3-2).
--
The 'Hdr Ext Len' field present in many of the IPv6 Extension Headers is stated
in RFC 2460 to indicate the length of the header excluding the first 8 octets.
As currently implemented, though, this field is being displayed as a field
named 'Length' that indicates the full length of the header (including the
first 8 octets.) It seems like it should be changed so that it is consistent
with the RFC.
This affects the currently implemented dissection of the Hop-by-Hop Options
Header, Routing Header, Shim6 Control Header (RFC5533) and in the case of an
unrecognized header type.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
