Hi,
I believe the ECN part in packet-ip.c could do with some enhancements.
It's stuck with RFC2481 nomenclature, and does not follow the current
standard RFC3168.
Wireshark (1.5.0 build 34091) currently decodes only the ECT(0)
codepoint as "ECN-capable transport", and incorrectly decodes both
ECT(1) and CE codepoints as "ECN-CE set".
In comparison, tcpdump(3.9.4) correctly decodes the 4 different
codepoints:
109282 IP (tos 0x0, ttl 29, id 0, offset 0, flags [DF], proto: TCP (6),
length: 40) A.58183 > B.http: SWE, cksum 0x0752 (correct),
619384838:619384838(0) win 65535
311189 IP (tos 0x1,ECT(1), ttl 29, id 0, offset 0, flags [DF], proto:
TCP (6), length: 40) A.58183 > B.http: SWE, cksum 0x0752 (correct),
619384838:619384838(0) win 65535
512142 IP (tos 0x2,ECT(0), ttl 29, id 0, offset 0, flags [DF], proto:
TCP (6), length: 40) A.58183 > B.http: SWE, cksum 0x0752 (correct),
619384838:619384838(0) win 65535
714018 IP (tos 0x3,CE, ttl 29, id 0, offset 0, flags [DF], proto: TCP
(6), length: 40) A.58183 > B.http: SWE, cksum 0x0752 (correct),
619384838:619384838(0) win 65535
The RFC3168 defines not 2 bits (as they are currently decoded in
Wireshark, in accordance to obsolete RFC2481), but 4 Codepoints (Section
5, Figure 1):
+-----+-----+
| ECN FIELD |
+-----+-----+
ECT CE [Obsolete] RFC 2481 names for the ECN bits.
0 0 Not-ECT
0 1 ECT(1)
1 0 ECT(0)
1 1 CE
Figure 1: The ECN Field in IP.
Thought I bring it up, now that the full 12 TCP flag bits are also
decoded correctly ;)
But this might be considered a nit-pick.
Richard Scheffenegger