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 _______________________________________________ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
