Hi,
It also answers the question why the preference is off by default.
Thanks, Jaap
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
___________________________________________________________________________ Sent via: Wireshark-users mailing list < wireshark-users@xxxxxxxxxxxxx> Archives: https://www.wireshark.org/lists/wireshark-usersUnsubscribe: https://www.wireshark.org/mailman/options/wireshark-users mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
|
