ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-users: Re: [Wireshark-users] FW: [Non-DoD Source] Wireshark-users Digest, Vol 136, Issu

From: Ian Riley <ianriley0@xxxxxxxxx>
Date: Tue, 26 Sep 2017 10:17:37 -0400
In people's experience, how do machines handle invalid checksums? Is it discarded by the NIC? Captured by the NIC but not passed to the application? Passed to the application, and the application chooses whether to ignore the bad checksum? 

Ian

Hi,

I see that in the reply packet. for example in packet 12 in the attached pcap (first message in this thread).
I just now tried to  enable checksum with Edit -> Preferences -> Protocols -> IPv4 -> check "Validate the IPv4 checksum if possible".
Now I see the validation marked in red in the same packets. Exactly what I needed then.
I was porting ip packet in the target, but with wrong configuration, I just had to enable checksum calculation in target.
Now icmp works without issus.
I think wireshark better check "Validate the IPv4 checksum if possible" by default. It is difficult to notice such problem without this.

Thank you,
Ran

On Tue, Sep 26, 2017 at 8:42 AM, Jaap Keuter <jaap.keuter@xxxxxxxxx> wrote:
> Hi,
>
> How did you determine that the checksum was 0? Did you capture truly
> ‘off the wire’? Or did you look closely at the shared capture file?
> I did the later and already saw the zero checksum. That’s what
> triggered my initial question on where did you capture.
> Having 0 as IP checksum at the *sending* side is not uncommon, the
> responsibility to calculate and fill in the checksum is then left to
> the network hardware, *after* capture has taken place.
> So again, how did you determine that the checksum was 0 *on the wire*?
>
> In fact Wireshark does add an expert item to incorrect IP checksums,
> iff the IP protocol preference is enabled. Is it in your case?
>
> Thanks,
> Jaap
>
>
> On 26 Sep 2017, at 06:41, Ran Shalit <ranshalit@xxxxxxxxx> wrote:
>
> Hi,
>
> I identified the problem.
> The ip header checksum in the reply was 0.(you can see that in the
> pcap attached in link).
>
> I wander why it is not marked in yellow or somthing similar, so that
> it will be more clear that there might be a problem because of wrong checksum.
>
> Thanks.
> Ran
>
> בתאריך 25 בספט 2017 23:25, "Jaap Keuter" <jaap.keuter@xxxxxxxxx> כתב:
>>
>> HI,
>>
>> Best way is to put a switch with monitor port between the two hosts
>> and capture the traffic there.
>> Then you’ll know what the hosts really see from the other, and can
>> Wireshark be helpful in further checks.
>>
>> Thanks,
>> Jaap
>>
>>
>> > On 25 Sep 2017, at 17:53, Ran Shalit <ranshalit@xxxxxxxxx> wrote:
>> >
>> > Hello Jaap,
>> >
>> > I don't have the capturing in the other side (it is embedded target).
>> > I reolve the issue, it seems to be related to checksum.
>> > Yet, I didn't see in wireshark any warning or yello marking on the
>> > reply checksum.
>> >
>> > Do you know how I could easily detect that there is an ICMP reply
>> > checksum issue with wireshark ?
>> >
>> > Thanks,
>> > Ran
>> >
>> > On Mon, Sep 25, 2017 at 12:30 PM, Jaap Keuter
>> > <jaap.keuter@xxxxxxxxx>
>> > wrote:
>> >> Hi,
>> >>
>> >> This was captured at 192.168.1.100, yes?
>> >> What do you see when capturing at the originator interface
>> >> (192.168.1.110)?
>> >>
>> >> Thanks,
>> >> Jaap
>> >>
>> >>
>> >>> On 25 Sep 2017, at 09:38, Ran Shalit <ranshalit@xxxxxxxxx> wrote:
>> >>>
>> >>> Hello,
>> >>>
>> >>> I would appreciate it if someone can assist in analyzing icmp
>> >>> request/reply :
>> >>>
>> >>>
>> >>> https://drive.google.com/file/d/0B22GsWueReZTZ0hfU2dRdE9rR2s/view
>> >>> ?usp=sharing
>> >>>
>> >>> I ping from pc to another machine, and in wireshark it looks
>> >>> perfect without error, yet I always get "request time out".
>> >>> I tried a lrager timeout (-w paramater), and ping from different
>> >>> machine, firewall disable, but I always get request time out in
>> >>> the PC.
>> >>>
>> >>> Thank you for any suggestion,
>> >>> Ran
>> >>
>
>
>
> ___________________________________________________________________________
> Sent via:    Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
> Archives:    https://www.wireshark.org/lists/wireshark-users
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
>
> mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe