Wireshark-dev: Re: [Wireshark-dev] [PATCH] Fix for bug 1136 : tcp-checksum 0xffff
Hi Sake,
seems good :)
Last doubt anyway, your msg 'maybe caused etc...' seems a lot of
explanation for me at the place you've put it. What do you think of the
same message in the following subtree (sister node of tcp.bad_cksum and
tcp.good_cksum) or in the expert item?
Regards,
Sebastien Tandel
Sake Blok wrote:
> 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@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
