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