[Nan Xiao <xiaonan830818@xxxxxxxxx>]

Hi Guy,

Got it, thanks very much for your time and detailed explanation!

Best Regards

Nan Xiao

On Thu, Jun 9, 2022 at 3:16 PM Guy Harris <gharris@xxxxxxxxx> wrote:

On Jun 8, 2022, at 11:29 PM, Nan Xiao <xiaonan830818@xxxxxxxxx> wrote:

> I am trying to understand the meaning of "ip.fragment" and "ip.fragments" display filters, but unfortunately it seems I can't find answers from user manual (https://www.wireshark.org/docs/wsug_html_chunked/index.html). E.g., the attachment pcap file includes 2 fragment packets, and both  "ip.fragment" and "ip.fragments" filters will make the 2nd packet display, and this makes me confused the differences between  "ip.fragment" and "ip.fragments" display filters.

"ip.fragment" and "ip.fragments" are both the names of fields that show up when IPv4 packets are dissected.  A field name can be used as a display filter, and that filter would match all packets that include that field.

If you're unfamiliar with "IP fragmentation":

Link-layer networks have different "maximum transmission unit" (MTU) sizes that limit how large a link-layer packet can be on that network.  For example, the MTU of an Ethernet network is usually 1500 bytes.

IP packets can go over multiple link-layer networks to get from the host that sends it to the host that receives it.  The host that sends it, and the TCP/IP software on that host, will probably know the MTU of the link-layer network onto which it will send the packet.  However, there may be one or more link-layer networks between that link-layer network and the link-layer network from which the host that receives it, and some of them might have a smaller MTU.

This means, for example, that the host that sends the packet might send a 1500-byte IP packet on one of its Ethernets, but that packet might not fit on one of those intermediate link-layer networks or the link-layer network from which the host that receives the packet will receive it.

IPv4 and IPv6 handle this by supporting "IP fragmentation".  This means that a single IP packet is divided into multiple fragments, each of which will fit on the link-layer network on which the packet will be sent; those are sent separately.  The data in the single IP packet is cut into pieces small enough that, when the IPv4 header from that packet is added to the front of each piece, the piece+IPv4 header is small enough to fit on the link-layer network onto which it will be sent. The host that receives it must then wait for all the fragments to arrive, and must then reassemble them to get the original packet.

Wireshark will *also* attempt to reassemble fragments before dissecting the packet, unless it's been configured not to do so.

If you look at the first packet in your capture, the "Flags" field (ip.flags) in its IPv4 header has the "More fragments" bit (ip.flags.mf) set, and has the "Fragment offset" (ip.frag_offset) set to 0.  A fragment offset of 0 means that this is the beginning of an IPv4 packet, and the "more fragments" bit being set means that this is not the *end* of the same packet - there is at least one more fragment after that packet.  The "Total length" (ip.len) field of the packet is set to 1244, meaning that the packet has 1244 bytes of IPv4 header plus data; the IPv4 header has no options, so it's 20 bytes long, meaning that the data is 1244-20 = 1224 bytes.

If you look at the second packet in your capture, the "Flags" field in its IPv4 header has the "More fragments" bit (ip.flags.mf) clear, and has the "Fragment offset" (ip.frag_offset) set to 1224.  A non-zero fragment offset means that this is not the beginning of an IPv4 packet, and thus that there is at least one fragment before that packet, and the "more fragments" bit means that this *is* the end of a packet, because there are no more fragments after it.  The "Total length" (ip.len) field of the packet is set to 96, meaning that the packet has 96 bytes of IPv4 header plus data; the IPv4 header has no options, so it's 20 bytes long, meaning that the data is 96-20 = 76 bytes.

Both packets have an "Identification" field (ip.id) of 0x3416.  As they don't have the same fragment offset, this means that they are likely to be two fragments of the same fragmented IP packet.  Given that the fragment offset of the second packet is equal to the data length of the first packet, this means that the two chunks of packet data fit together as a single chunk of reassembled data.

When Wireshark reassembles the packet, it shows information about the reassembly in a field whose name is "ip.fragments" and that contains various bits of information.  That information includes the data from each of the packets that were reassembled; each of those chunks of data are in a field named "ip.fragment".  In this case, there are two "ip.fragment" fields, one for the data in the first packet and one for the data in the second packet.

"ip.fragment" fields always appear as part of an "ip.fragments" field, and "ip.fragments" fields always contain multiple "ip.fragment fields.  Therefore, any packet that has an "ip.fragment" field has an "ip.fragments" field, and any packet that has an "ip.fragments" field has multiple "ip.fragment" fields.  That's why a display filter of "ip.fragments" and a display of "ip.fragment" will show the same packets.
___________________________________________________________________________
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