Wireshark-bugs: [Wireshark-bugs] [Bug 4353] Large ICMP frame size does not include data
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: bugzilla-daemon@xxxxxxxxxxxxx
Date: Fri, 25 Dec 2009 20:31:42 -0800 (PST)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4353

Jim Young <jyoung@xxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jyoung@xxxxxxx

--- Comment #1 from Jim Young <jyoung@xxxxxxx> 2009-12-25 20:31:39 PST ---
Hello Vaibhav,

I don't believe you have a Wireshark bug here.

If you use the display filter "ip.addr==4.2.2.2" you can better see what is
happening. 

With your "large"[1] ping requests you have source side ping packet
fragmentation occurring.   In frames 54, 107, 185, 214 you will see the first
1376 bytes of the each large ping request.  Frames 55, 108, 186, and 215
respectively are the second fragment of each of the large ping requests (the
final 5 bytes).  The frame's length represents the length of each frame not of
the length of the original ICMP ping request payload.

If you have "Reassemble fragmented IP datagrams:" enabled (Preferences |
Protocols | IP) you should be able to see the reassembled IP payload in the
lower hex window of the last fragments within an extra TAB labeled "Reassembled
IPv4 (1381 bytes)".  (This reassembled length of 1861 is 8 bytes greater than
your original ping request; this reassmebled component includes the 8 byte IP
header and the 1373 ping payload).

Your earlier non-fragmented ping requests (frames 20, 27, 31, and 36) received
replies (in frames 23, 29, 33, and 42 respectively) but your four later "large"
fragmented requests did not result in a reply.  This implies that some
networking component between your two hosts may not allow fragmented IP packets
(or at least not allow fragmented ICMP echo requests and/or replies to flow).

[1] Including overhead for ethernet, and IP headers a ping request of "1373"
normally wouldn't trigger packet fragmentation, but it appears that the MTU for
this particular network interface has been logically reconfigured to a smaller
than standard ethernet sized MTU.

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.