Revision history [back]

Hi to all, I red in RFC 791 that: * "The internet fragmentation and reassembly procedure needs to be able to break a datagram into an almost arbitrary number of pieces that can be later reassembled. The receiver of the fragments uses the identification field to ensure that fragments of different datagrams are not mixed. The fragment offset field tells the receiver the position of a fragment in the original datagram. The fragment offset and length determine the portion of the original datagram covered by this fragment. The more-fragments flag indicates (by being reset) the last fragment. These fields provide sufficient information to reassemble datagrams."*

But, when I launch a traceroute with byte size of 3000, and so my packets been splitted, I notice a strange behavior in fragmentation flags; Every packet been fragmented in 3 parts:

1480 bytes,

1480 bytes,

and a small one of the remaining 40 bytes (only data, not considering headers etc.).

In this 3 fragments I have, respectively, this Fragmentation Flags:

Flags: 0x20, More fragments 0... .... = Reserved bit: Not set .0.. .... = Don't fragment: Not set ..1. .... = More fragments: Set Fragment Offset: 0

Flags: 0x20, More fragments 0... .... = Reserved bit: Not set .0.. .... = Don't fragment: Not set ..1. .... = More fragments: Set Fragment Offset: 1480

Flags: 0x01 0... .... = Reserved bit: Not set .0.. .... = Don't fragment: Not set ..0. .... = More fragments: Not set Fragment Offset: 2960

My question is: Why, in the last fragment, flag is 0x01 and not 0x00, like in the others, smaller packets that not being fragmented in the path? (Sorry for my bad english).

Thank you to all who can help me understand this

Hi to all, I red read in RFC 791 that: * that:

"The internet fragmentation and reassembly procedure needs to be able to break a datagram into an almost arbitrary number of pieces that can be later reassembled. The receiver of the fragments uses the identification field to ensure that fragments of different datagrams are not mixed. The fragment offset field tells the receiver the position of a fragment in the original datagram. The fragment offset and length determine the portion of the original datagram covered by this fragment. The more-fragments flag indicates (by being reset) the last fragment. These fields provide sufficient information to reassemble datagrams."*datagrams."

But, when I launch a traceroute with byte size of 3000, and so my packets been splitted, I notice a strange behavior in fragmentation flags; Every each packet been is fragmented in 3 parts:

1480 bytes,

1480 bytes,

and a small one of the remaining 40 bytes (only data, not considering headers etc.).

In this 3 fragments I have, respectively, this Fragmentation Flags:

Flags: 0x20, More fragments 0... .... = Reserved bit: Not set .0.. .... = Don't fragment: Not set ..1. .... = More fragments: Set Fragment Offset: 0

Flags: 0x20, More fragments 0... .... = Reserved bit: Not set .0.. .... = Don't fragment: Not set ..1. .... = More fragments: Set Fragment Offset: 1480

Flags: 0x01 0... .... = Reserved bit: Not set .0.. .... = Don't fragment: Not set ..0. .... = More fragments: Not set Fragment Offset: 2960

My question is: Why, in the last fragment, flag is 0x01 and not 0x00, like in the others, smaller packets that not being fragmented in the path? (Sorry for my bad english).

Thank you to all who can help me understand thisthis.

Hi to all, I read in RFC 791 that:

"The internet fragmentation and reassembly procedure needs to be able to break a datagram into an almost arbitrary number of pieces that can be later reassembled. The receiver of the fragments uses the identification field to ensure that fragments of different datagrams are not mixed. The fragment offset field tells the receiver the position of a fragment in the original datagram. The fragment offset and length determine the portion of the original datagram covered by this fragment. The more-fragments flag indicates (by being reset) the last fragment. These fields provide sufficient information to reassemble datagrams."

But, when I launch a traceroute with byte size of 3000, and so my packets been splitted, I notice a strange behavior in fragmentation flags; each packet is fragmented in 3 parts:

1480 bytes,

1480 bytes,

and a small one of the remaining 40 bytes (only data, not considering headers etc.).

In this 3 fragments I have, respectively, this Fragmentation Flags:

Flags: 0x20, More fragments 0... .... = Reserved bit: Not set .0.. .... = Don't fragment: Not set ..1. .... = More fragments: Set Fragment Offset: 0

Flags: 0x20, More fragments 0... .... = Reserved bit: Not set .0.. .... = Don't fragment: Not set ..1. .... = More fragments: Set Fragment Offset: 1480

Flags: 0x01 0... .... = Reserved bit: Not set .0.. .... = Don't fragment: Not set ..0. .... = More fragments: Not set Fragment Offset: 2960

My question is: Why, in the last fragment, flag is 0x01 and not 0x00, like in the others, smaller packets that not being fragmented in the path? (Sorry for my bad english).

Thank you to all who can help me understand this.

Here you can see screenshots of, in order, a small packet not fragmented, first fragment, second fragment, third (and last) fragment of a 3000 byte packet: https://imgur.com/a/d5EF8qF

Hi to all, I read in RFC 791 that:

"The internet fragmentation and reassembly procedure needs to be able to break a datagram into an almost arbitrary number of pieces that can be later reassembled. The receiver of the fragments uses the identification field to ensure that fragments of different datagrams are not mixed. The fragment offset field tells the receiver the position of a fragment in the original datagram. The fragment offset and length determine the portion of the original datagram covered by this fragment. The more-fragments flag indicates (by being reset) the last fragment. These fields provide sufficient information to reassemble datagrams."

But, when I launch a traceroute with byte size of 3000, and so my packets been splitted, I notice a strange behavior in fragmentation flags; each packet is fragmented in 3 parts:

1480 bytes,

1480 bytes,

and a small one of the remaining 40 bytes (only data, not considering headers etc.).

In this 3 fragments I have, respectively, this Fragmentation Flags:

Flags: 0x20, More fragments
 0... .... = Reserved bit: Not set
 .0.. .... = Don't fragment: Not set
 ..1. .... = More fragments: Set
Fragment Offset: 0
 
0

Flags: 0x20, More fragments
    0... .... = Reserved bit: Not set
    .0.. .... = Don't fragment: Not set
    ..1. .... = More fragments: Set
Fragment Offset: 1480
 
1480

Flags: 0x01
    0... .... = Reserved bit: Not set
    .0.. .... = Don't fragment: Not set
    ..0. .... = More fragments: Not set
Fragment Offset: 29602960

Hi to all, I read in RFC 791 that:

"The internet fragmentation and reassembly procedure needs to be able to break a datagram into an almost arbitrary number of pieces that can be later reassembled. The receiver of the fragments uses the identification field to ensure that fragments of different datagrams are not mixed. The fragment offset field tells the receiver the position of a fragment in the original datagram. The fragment offset and length determine the portion of the original datagram covered by this fragment. The more-fragments flag indicates (by being reset) the last fragment. These fields provide sufficient information to reassemble datagrams."

Flags: 0x00
    0... .... = Reserved bit: Not set
    .0.. .... = Don't fragment: Not set
    ..0. .... = More fragments: Not set
Fragment Offset: 0

But, when I launch a traceroute with byte size of 3000, and so my packets been splitted, I notice a strange behavior in fragmentation flags; each packet is fragmented in 3 parts:

1480 bytes,

1480 bytes,

and a small one of the remaining 40 bytes (only data, not considering headers etc.).

In this 3 fragments I have, respectively, this Fragmentation Flags:

Flags: 0x20, More fragments
0... .... = Reserved bit: Not set
.0.. .... = Don't fragment: Not set
..1. .... = More fragments: Set
Fragment Offset: 0

Flags: 0x20, More fragments
    0... .... = Reserved bit: Not set
    .0.. .... = Don't fragment: Not set
    ..1. .... = More fragments: Set
Fragment Offset: 1480

Flags: 0x01
    0... .... = Reserved bit: Not set
    .0.. .... = Don't fragment: Not set
    ..0. .... = More fragments: Not set
Fragment Offset: 2960

My question is: Why, why, in the last fragment, flag is 0x01 and not 0x00, like in the others, smaller packets that are not being fragmented in the path? fragmented? (Sorry for my bad english).

Thank you to all who can help me understand this.

Here you can see screenshots of, in order, a small packet not fragmented, first fragment, second fragment, third (and last) fragment of a 3000 byte packet: https://imgur.com/a/d5EF8qF

Hi to all, I read in RFC 791 that:

"The internet fragmentation and reassembly procedure needs to be able to break a datagram into an almost arbitrary number of pieces that can be later reassembled. The receiver of the fragments uses the identification field to ensure that fragments of different datagrams are not mixed. The fragment offset field tells the receiver the position of a fragment in the original datagram. The fragment offset and length determine the portion of the original datagram covered by this fragment. The more-fragments flag indicates (by being reset) the last fragment. These fields provide sufficient information to reassemble datagrams."

In a non-fragmented packet I have, as expected:

Flags: 0x00
    0... .... = Reserved bit: Not set
    .0.. .... = Don't fragment: Not set
    ..0. .... = More fragments: Not set
Fragment Offset: 0

But, when I launch a traceroute with byte size of 3000, and so my packets been splitted, I notice a strange behavior in fragmentation flags; each packet is fragmented in 3 parts:

1480 bytes,

1480 bytes,

and a small one of the remaining 40 bytes (only data, not considering headers etc.).

In this 3 fragments I have, respectively, this Fragmentation Flags:

Flags: 0x20, More fragments
0... .... = Reserved bit: Not set
.0.. .... = Don't fragment: Not set
..1. .... = More fragments: Set
Fragment Offset: 0

Flags: 0x20, More fragments
    0... .... = Reserved bit: Not set
    .0.. .... = Don't fragment: Not set
    ..1. .... = More fragments: Set
Fragment Offset: 1480

Flags: 0x01
    0... .... = Reserved bit: Not set
    .0.. .... = Don't fragment: Not set
    ..0. .... = More fragments: Not set
Fragment Offset: 2960

My question is: why, in the last fragment, flag is 0x01 and not 0x00, like in the others, smaller packets that are not fragmented? (Sorry for my bad english).

Thank you to all who can help me understand this.

Here you can see screenshots of, in order, a small packet not fragmented, first fragment, second fragment, third (and last) fragment of a 3000 byte packet: https://imgur.com/a/d5EF8qF

Hi to all, I read in RFC 791 that:

"The internet fragmentation and reassembly procedure needs to be able to break a datagram into an almost arbitrary number of pieces that can be later reassembled. The receiver of the fragments uses the identification field to ensure that fragments of different datagrams are not mixed. The fragment offset field tells the receiver the position of a fragment in the original datagram. The fragment offset and length determine the portion of the original datagram covered by this fragment. The more-fragments flag indicates (by being reset) the last fragment. These fields provide sufficient information to reassemble datagrams."

In a non-fragmented packet I have, as expected:

Flags: 0x00
    0... .... = Reserved bit: Not set
    .0.. .... = Don't fragment: Not set
    ..0. .... = More fragments: Not set
Fragment Offset: 0

But, when I launch a traceroute with byte size of 3000, and so my packets been splitted, I notice a strange behavior in fragmentation flags; each packet is fragmented in 3 parts:

1480 bytes,

1480 bytes,

and a small one of the remaining 40 bytes (only data, not considering headers etc.).

In this 3 fragments I have, respectively, this Fragmentation Flags:

Flags: 0x20, More fragments
0... .... = Reserved bit: Not set
.0.. .... = Don't fragment: Not set
..1. .... = More fragments: Set
Fragment Offset: 0

Flags: 0x20, More fragments
    0... .... = Reserved bit: Not set
    .0.. .... = Don't fragment: Not set
    ..1. .... = More fragments: Set
Fragment Offset: 1480

Flags: 0x01
    0... .... = Reserved bit: Not set
    .0.. .... = Don't fragment: Not set
    ..0. .... = More fragments: Not set
Fragment Offset: 2960

My question is: why, in the last fragment, flag is 0x01 and not 0x00, like in the others, smaller packets that are not fragmented? (Sorry for my bad english).

Thank you to all who can help me understand this.

Here you can see screenshots of, in order, a small packet not fragmented, first fragment, second fragment, third (and last) fragment of a 3000 byte packet: https://imgur.com/a/d5EF8qF

Wireshark Version 3.4.10 (Git v3.4.10 packaged as 3.4.10-0+deb11u1)

Running on Linux 5.16.0-12parrot1-amd64