I am new to Wireshark, and am confused by the content of a recent capture. I am looking at two Ethernet packets, which look like two fragments of a TCP/IP payload. The "Ethernet II" data identifies IPv4 (0x0800), and the IPv4 header for both show the same Identification value, as well as source/destination IPaddr and ports. However, the IPv4 headers in both captured packets: 1) ...have the "Don't Fragment" flag set 2) ...do not have the "More Fragments" flag set 3) ...have "Fragment offset" set to zero ('0') Any help/guidance/look-here is appreciated. A subset of the captured packets has been posted to https://www.cloudshark.org/captures/3c38c54fac99 Clarification: In this particular exchange, all TCP/IP "Push" traffic has a payload that starts with 0x12345678 (see frames #4 and #6). The TCP/IP payload in frame #2 is not the start of a message (i.e., is presumed to be the second IP fragment), as it does not start with this sequence. asked 07 Aug '17, 08:48  lfru553ll edited 07 Aug '17, 13:57 |
2 Answers:
I think you might be mixing up IP fragments with TCP segments. There's no evidence of IP Fragmentation occurring or could even occur, considering that "Don't Fragment" is set, and so I think the IP stack is free to reuse the IP ID if it wishes. I haven't read the entire RFC (you're certainly free to do so), but from RFC 6864:
(MDL is the "maximum datagram lifetime".) EDIT: Further reading of RFC 6864 makes it clear [to me] that IP ID reuse is permissible. In section 6.1:
Since all IP datagrams in this capture file are atomic datagrams, IP ID uniqueness doesn't apply. Atomic datagrams is defined in RFC 6864 as follows: " Regarding frames 2 and 4, this is just an artifact of TCP streaming. There's simply no guarantee that a TCP data segment corresponds in any way with the start of a higher layer PDU. There might be multiple PDUs within a single segment or a partial PDU in one segment followed by the remainder of the PDU in the next or subsequent segments. So, when you wrote, "The TCP/IP payload in frame #2 is not the start of a message (i.e., is presumed to be the second IP fragment), as it does not start with this sequence.", this is not accurate. It's presumed not to be the second IP Fragment but the second TCP segment of an upper layer PDU. answered 07 Aug '17, 16:07  cmaynard ♦♦ edited 07 Aug '17, 16:45 Well, the fact that reuse of IP ID for non-fragmented packets has become legal doesn't change my opinion that in this particular case it was not changed due to a bug, because it did change between the first and second packet of that TCP stream and did not between the second and third :-) (08 Aug '17, 04:42) sindy I don't necessarily disagree with you in that it does seem like a bug in the sense that it doesn't seem like intentional behavior. It would be interesting to see more packets from the stream to see if more insight could be gained into the particular behavior. For example, perhaps the intervening ACK affects the choice of value of the IP ID field in Frame 4. (08 Aug '17, 05:15) cmaynard ♦♦ Thanks for the feedback. I "expected" IP fragmentation, and was concerned when I didn't see it being supported (i.e., the "DF" flag being set)...and was further confused when I saw the same IP ID in close temporal proximity to another usage. The clarification on the validity of IP ID re-use (intentional or otherwise) is also very helpful. (08 Aug '17, 08:20) lfru553ll
Those IP datagrams contain TCP segments; setting DF is standard operating procedure for many TCP implementations, because, with path MTU discovery (RFC 1191), there shouldn't be any fragmentation - TCP segments should be short enough that fragmentation and reassembly isn't necessary. DF is used as part of the path MTU discovery. (15 Aug '17, 00:52) Guy Harris ♦♦ |
To me it seems like a bug in the IP stack sending the packets in question, or in some firewall/NAT in the path between the sending stack and the capturing point. If the second packet with the same IP ID was a fragment of the first one, it would not contain its own TCP header with proper sequence number etc. The good news for you is that the recipient doesn't care about this as it sends appropriate ACKs to both these packets. answered 07 Aug '17, 12:23  sindy That "sort of" sounds right, except for one thing. For clarity and to "keep things in one place", I will add additional explanation to my original post. (07 Aug '17, 13:50) lfru553ll |
Can you share a capture in a publicly accessible spot, e.g. CloudShark, Google Drive, DropBox etc?
I have uploaded a subset of packets to CloudShark, with the same tags as this post. The filename is "IP_Id 4958 Frag_Offset ZERO.pcapng".
The frames I am question are #2 and #4. For what it's worth, I believe that frame #4 contains the first fragment (based on payload).
Can you edit your comment, or question, with a link to the file on CloudShark?
FYI - CloudShark captures now default to private. You can change them to public by clicking on More Info-->Sharing when in the packet viewer.
CloudShark upload at https://www.cloudshark.org/captures/3c38c54fac99 has now been made public, read-only.