Ask Your Question
0

icmp fragmentation

asked 2018-11-12 18:29:38 +0000

updated 2018-11-12 19:33:37 +0000

I'm trying to understand IP fragmentation for a network test and the way Wireshark displays the fragmented packets is not making much sense to me.

Here are my assumptions:

  1. Ethernet Type II Frame : 1514 bytes (Wireshark does not show the last 4 bytes of CRC) = 14 Bytes Header + 1500 Bytes Max Payload
  2. IP Packet: 20 Bytes Header + 1480 Bytes Max Payload
  3. ICMP Packet: 8 Bytes Header + 1472 Bytes Max Payload

TOPOLOGY:

HOST (10.0.0.101)------------------ SWITCH (10.0.0.100)

CASE 1:

Host pings Switch: ping 10.0.0.100 -l 1472

On Wireshark, I see no fragmentation as expected.

CASE 2:

Host pings Switch: ping 10.0.0.100 -l 1473

On Wireshark, I see 2 packets:

One of IPv4 Protocol Type of 1514 Byte Size Length + One of ICMP Protocol Type of 35 Byte Size Length, fragmentation is expected since Payload of 1473 is one (1) Byte larger than ICMP Max Payload size. So I'd expect, the second packet being of a size of: 14 (Eth Type II Header) + 20 (IP Header) + 8 (ICMP Header) + 1 (Byte left from Payload) = 43 Bytes

Also, shouldn't a Eth Frame have a Min size of 64 Bytes?

What am I missing?

Thanks in advance

edit retag flag offensive close merge delete

Comments

Providing a link to the capture file on a public share somewhere would be helpful.

grahamb gravatar imagegrahamb ( 2018-11-12 18:37:45 +0000 )edit

Packet capture: ICMP Fragmentation

BabyShark gravatar imageBabyShark ( 2018-11-12 18:56:49 +0000 )edit

1 Answer

Sort by ยป oldest newest most voted
0

answered 2018-11-12 19:14:33 +0000

updated 2018-11-12 19:23:36 +0000

Hi,

You're missing 2 things:

  1. Second fragment doesn't have its own ICMP header, only IP header. It uses IP ID field, and Fragment offset field to correlate with the first fragment.
  2. Probably your NIC is responsible for adding the padding to 60 Bytes + FCS of 4 Bytes. You're capturing before both of these are added. In the received ICMP Echo Reply you see 60-Bytes second fragment as it should be (FCS is not seen usually).
edit flag offensive delete link more

Comments

See comments below:

1. Second fragment doesn't have its own ICMP header, only IP header. It uses IP ID field, and Fragment offset field to correlate with the first fragment.

>> True, I noticed that as well. Is this Normal, I mean, no having the ICMP Header on the 2nd packet? But why the size is 35? and not 43?

2. Probably your NIC is responsible for adding the padding to 60 Bytes + FCS of 4 Bytes. You're capturing before both of these are added. In the received ICMP Echo Reply you see 60-Bytes second fragment as it should be (FCS is not seen usually).

>> Got it.

Thanks

BabyShark gravatar imageBabyShark ( 2018-11-12 19:36:58 +0000 )edit

This is a good question. RFC791 states the next:

To fragment a long internet datagram, an internet protocol module (for example, in a gateway), creates two new internet datagrams and copies the contents of the internet header fields from the long datagram into both new internet headers. The data of the long datagram is divided into two portions on a 8 octet (64 bit) boundary (the second portion might not be an integral multiple of 8 octets, but the first must be). Call the number of 8 octet blocks in the first portion NFB (for Number of Fragment Blocks). The first portion of the data is placed in the first new internet datagram, and the total length field is set to the length of the first datagram. The more-fragments flag is set to one. The second portion of the data is placed in the second new internet datagram, and the ...(more)

Packet_vlad gravatar imagePacket_vlad ( 2018-11-12 19:57:01 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2018-11-12 18:29:38 +0000

Seen: 48 times

Last updated: Nov 12