Wireshark-bugs: [Wireshark-bugs] [Bug 10687] Feature Request: Bad Checksum 0x00000000
Comment # 7
on bug 10687
from Chris Maynard
(In reply to Sam from comment #0)
> Why is it in this day and age that wireshark is still telling me that an
> Ethernet/TCP/UDP checksum of 0x00000000 is an error?
Regarding Ethernet, are you suggesting that an Ethernet FCS of 0x00000000
should be treated special?
Regarding UDP 0x0000 checksums: UDP 0x0000 checksums are already categorized
as separate Expert Infos if not carried by IPv4. Note that a UDP checksum
value of 0x0000, when carried by IPv4, only means that the transmitter didn't
generate a checksum, and Wireshark indicates "none" in this case with neither
udp.checksum_bad nor udp.checksum_good set to TRUE and no Expert Info generated
at all.
>From http://tools.ietf.org/html/rfc768:
An all zero transmitted
checksum value means that the transmitter generated no checksum (for
debugging or for higher level protocols that don't care).
For UDP 0x0000 checksums carried by IPv6 (for example), you would get:
Packet Details: Checksum: 0x0000 (Illegal)
Expert Info: Illegal Checksum value (0)
as opposed to an invalid checksum other than zero:
Packet Details: Checksum: 0xXXXX [incorrect, should be 0xYYYY
(maybe caused by "UDP checksum offload"?)]
Expert Info: Bad checksum
(In reply to Sam from comment #3)
> I know that a checksum of 0 is valid, although highly unlikely. I just wish
> it was categorized differently by the expert infos so I can easily see the
> difference between a 0 checksum and one that was calculated to something
> non-zero and wrong. Does that make sense?
So presumably you're really only referring to TCP 0x0000 checksums and not
Ethernet 0x00000000 or UDP 0x0000 checksums? Assuming so, why are TCP 0x0000
checksums less likely to occur than any other checksum value?
Some things you could do:
If you like using coloring rules and don't want to disable them, but you don't
like the TCP packets with a checksum of 0x0000 being colorized like the rest of
the packets categorized as checksum errors, then you could, at the risk of not
identifying by color truly invalid checksums, modify the "Checksum Errors"
coloring rule to be,
"... || ((tcp.checksum_bad == 1) && !(tcp.checksum == 0x0000)) || ..."
You could also create a saved "Bad non-0 TCP checksums" display filter rule for
convenience, then access it easily as a button on the toolbar.
(In reply to Alexis La Goutte from comment #5)
> What the next ? add pref ? close this bug ?
I'd recommend closing this bug as NOTABUG.
You are receiving this mail because:
- You are watching all bug changes.
