Wireshark

  • Riverbed Technology
  • WinPcap
the world's foremost network protocol analyzer
  • Wireshark
    • About
    • Download
    • Blog
  • Get Help
    • Ask a Question
    • FAQs
    • Documentation
    • Mailing Lists
    • Online Tools
    • Wiki
    • Bug Tracker
  • Develop
    • Get Involved
    • Developer's Guide
    • Browse the Code
    • Latest Builds

Wireshark-dev: Re: [Wireshark-dev] [PATCH] Fix for bug 1136 : tcp-checksum 0xffff

Date Index Thread Index Other Months All Mailing Lists
Date Prev Date Next Thread Prev Thread Next


From: Sebastien Tandel <sebastien@xxxxxxxxx>
Date: Sun, 01 Apr 2007 13:52:39 +0200

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
>   


  • Follow-Ups:
    • Re: [Wireshark-dev] [PATCH] Fix for bug 1136 : tcp-checksum 0xffff
      • From: Sake Blok
  • Prev by Date: Re: [Wireshark-dev] Protocol for DRDA / DB2
  • Next by Date: Re: [Wireshark-dev] [PATCH] Fix for bug 598
  • Previous by thread: Re: [Wireshark-dev] Protocol for DRDA / DB2
  • Next by thread: Re: [Wireshark-dev] [PATCH] Fix for bug 1136 : tcp-checksum 0xffff
  • Index(es):
    • Date
    • Thread

Wireshark and the "fin" logo are registered trademarks of the Wireshark Foundation