On Sat, Mar 31, 2007 at 12:55:55PM +0200, Sebastien Tandel wrote:
> Sake Blok wrote:
> >
> > I did some research to tcp-checksum 0xffff. This checksum should not
> > appear in tcp-headers. RFC 1624 explains that it can be generated
> > by a (not-so-good) algorythm for incremental updates to the tcp-checksum
> > (after NAT for example). The RFC advises systems to validate the
> > checksum according to RFC 1071 (which will treat the checksum as
> > valid). Wireshark indeeds uses the method from RFC 1071.
> >
> > However, some systems just calculate the checksum and then compare
> > it to the checksum in the packet. This results is a bad checksum
> > (0x0000 != 0xffff) and the packet will be dropped.
> >
> > To enhance troubleshooting this situations I wrote a patch that
> > displayes the checksum as follows:
> >
> > Checksum: 0xffff [incorrect, should be 0x0000 (maybe caused by "Incremental update"? See RFC 1624.)]
>
>
> IMO, it would be better to create an expert item associated to this
> specific incorrect checksum.
Hmm... that might make more sense indeed. How about the following:
- use "Checksum: 0xffff [should be 0x0000 (maybe caused by \"Incremental Up
date\"? See RFC 1624)]" in the packet-detail pane
- set tcp.checksum_good to FALSE (just like checksum-offloaed packets)
- set tcp.checksum_bad to FALSE (just like checksum-offloaed packets)
- Generate an expert warning: "TCP Checksum 0xffff instead of 0x0000"
- add "[TCP CHECKSUM 0xFFFF]" instead of "[TCP CHECKSUM BAD]" to COL_INFO
This does indeed look better on my development system. I have resubmitted
a patch to bugzilla, could you please review it again?
Cheers,
Sake
