https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3320
Summary: wireshark gets DSCP and ECN backwards in the Diff Svcs
IP Header field
Product: Wireshark
Version: 1.0.6
Platform: x86
OS/Version: Windows XP
Status: NEW
Severity: Minor
Priority: Low
Component: Wireshark
AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
ReportedBy: nschley@xxxxxxx
Nate Schley <nschley@xxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #2840| |review_for_checkin?
Flag| |
Created an attachment (id=2840)
--> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=2840)
picture of the Wireshark GUI interpretation of the Diff Svcs Field
Build Information:
Version 1.0.6 (SVN Rev 27387)
Copyright 1998-2009 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 with GTK+ 2.12.8, with GLib 2.14.6, with WinPcap (version unknown),
with libz 1.2.3, without POSIX capabilities, with libpcre 7.0, with SMI 0.4.8,
with ADNS, with Lua 5.1, with GnuTLS 2.6.3, with Gcrypt 1.4.3, with MIT
Kerberos, with PortAudio V19-devel, with AirPcap.
Running on Windows XP Service Pack 2, build 2600, with WinPcap version 4.0.2
(packet.dll version 4.0.0.1040), based on libpcap version 0.9.5, without
AirPcap.
Built using Microsoft Visual C++ 6.0 build 8804
--
Per rfc2474 (http://tools.ietf.org/html/rfc2474), the differentiated services
field is comprised as follows:
/
| 0 1 2 3 4 5 6 7
| +---+---+---+---+---+---+---+---+
| | DSCP | CU |
| +---+---+---+---+---+---+---+---+
|
| DSCP: differentiated services codepoint
| CU: currently unused
|
|
| In a DSCP value notation 'xxxxxx' (where 'x' may equal '0' or '1')
| used in this document, the left-most bit signifies bit 0 of the DS
| field (as shown above), and the right-most bit signifies bit 5.
/
However, I find Wireshark taking a DS field with value of 0x80 and presenting
it as "DSCP 0x20: Class Selector 4; ECN: 0x00." This would be correct if the
endian-ness of the DS field were reversed, e.g.
/
| 7 6 5 4 3 2 1 0
| +---+---+---+---+---+---+---+---+
| | DSCP | CU |
| +---+---+---+---+---+---+---+---+
/
but that's clearly not what the RFC says.
RFC3168 ("The Addition of ECN to IP") (http://tools.ietf.org/html/rfc3168)
corroborates this:
/
| 0 1 2 3 4 5 6 7
| +-----+-----+-----+-----+-----+-----+-----+-----+
| | DS FIELD, DSCP | ECN FIELD |
| +-----+-----+-----+-----+-----+-----+-----+-----+
|
| DSCP: differentiated services codepoint
| ECN: Explicit Congestion Notification
|
| Figure 2: The Differentiated Services and ECN Fields in IP.
|
| Bits 6 and 7 in the IPv4 TOS octet are designated as the ECN field.
| The IPv4 TOS octet corresponds to the Traffic Class octet in IPv6,
| and the ECN field is defined identically in both cases. The
| definitions for the IPv4 TOS octet [RFC791] and the IPv6 Traffic
| Class octet have been superseded by the six-bit DS (Differentiated
| Services) Field [RFC2474, RFC2780]. Bits 6 and 7 are listed in
| [RFC2474] as Currently Unused, and are specified in RFC 2780 as
| approved for experimental use for ECN. Section 22 gives a brief
| history of the TOS octet.
/
(Link: http://tools.ietf.org/html/rfc3168#section-22)
Wireshark should take the 6 LSb as DSCP and the 2 MSb as ECN FIELD.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
