https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4353
--- Comment #2 from Vaibhav <vaibhav.leo@xxxxxxxxx> 2009-12-29 17:05:45 PST ---
(In reply to comment #1)
> 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.
Hi Jim,
Thanks for the explanation. And there doesnt seem to be a bug in calculating
the frame size but display is misleading.
Let me explain it further :
If the option "Reassemble fragmented IP datagrams" is enabled the Frame 54
shows the protocol IP and a fragment of the original packet.
And, Frame 55 shows the data as 1373 bytes in ICMP layer. But the actual data
in this frame is 5 bytes as shown in frame size.
This is shown correctly when the option "Reassemble fragmented IP datagrams" is
disabled . As it shows the first packet as ICMP and the second one as IP with
correct data size.
Please explain why it is designed like this ?
Regards
Vaibhav
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.