In an attempt to see IP fragmentation in action, I set the MTU of my DSL
router's Internet interface to 1492, while keeping the MTU of the internal
LAN interface at 1500.
To do the tests, I'm using netcat in UDP mode. On a remote Internet host I
have a listening netcat, to which I send some data using a netcat running
on an internal host in my LAN. IP packets have the "don't fragment" flag
set, and I'm using linux to do the tests.

For the first test, I do a

nc -u [remote host address and port] < myfile

where myfile is a 1470-byte file. Running wireshark at the sender, I see
that a 1498-byte IP packet is generated, which is correct for the LAN but
which the router rejects (correctly) with the "fragmentation needed" ICMP
error. Thus, the sender fragments the packet and resends it as two separate
IP packets.

The next step is sending a 6000-byte file to the remote netcat, using the
same command as before.
Now, wireshark shows that the single resulting UDP datagram is fragmented
into 5 IP packets, the first 4 of which contain 1500 bytes of IP data (1480
bytes of IP payload + 20 bytes IP header - the first IP payload also has
the 8-byte UDP header at the beginning). This time, however, the router
does NOT send back the "fragmentation needed" ICMP message, and happily
forwards the packets. Indeed, running a network analyzer on the remote host
shows that the IP packets are not further fragmented, as I was expecting.
Each fragment has the "don't fragment" flag not set, so the router could
further fragment them if needed, but it does not. It seems that full
1500-byte IP packets traverse a link with an MTU of 1492 (albeit
artificial) without problems.

On the other hand, when sending a large file using TCP, everything works
perfectly, and the sender correctly reduces the segment size as soon as
a "fragmentation needed" message is received (and this means, of course,
that the router correctly produces that ICMP message).

Is this possible, is my approach wrong, or is there something else I'm
missing?

Thanks

On Oct 6, 12:39 pm, pk <p...@pk.pk> wrote:

> In an attempt to see IP fragmentation in action, I set the MTU of my DSL
> router's Internet interface to 1492, while keeping the MTU of the internal
> LAN interface at 1500.
> To do the tests, I'm using netcat in UDP mode. On a remote Internet host I
> have a listening netcat, to which I send some data using a netcat running
> on an internal host in my LAN. IP packets have the "don't fragment" flag
> set, and I'm using linux to do the tests.
>
> For the first test, I do a
>
> nc -u [remote host address and port] < myfile
>
> where myfile is a 1470-byte file. Running wireshark at the sender, I see
> that a 1498-byte IP packet is generated, which is correct for the LAN but
> which the router rejects (correctly) with the "fragmentation needed" ICMP
> error. Thus, the sender fragments the packet and resends it as two separate
> IP packets.

Okay, so it appears that with UDP, all works well if you set the
"don't fragment" bit. With that bit set, the ADSL router returns the
ICMP error, kicked off by the artificial limit you set on its WAN
interface.

> The next step is sending a 6000-byte file to the remote netcat, using the
> same command as before.
> Now, wireshark shows that the single resulting UDP datagram is fragmented
> into 5 IP packets, the first 4 of which contain 1500 bytes of IP data (1480
> bytes of IP payload + 20 bytes IP header - the first IP payload also has
> the 8-byte UDP header at the beginning). This time, however, the router
> does NOT send back the "fragmentation needed" ICMP message, and happily
> forwards the packets. Indeed, running a network analyzer on the remote host
> shows that the IP packets are not further fragmented, as I was expecting.
> Each fragment has the "don't fragment" flag **not** set, so the router could
> further fragment them if needed, but it does not. It seems that full
> 1500-byte IP packets traverse a link with an MTU of 1492 (albeit
> artificial) without problems.

Seems like if the don't fragment flag is clear, then the router
doesn't kick off the ICMP error, the source doesn't fragment further,
and the router discovers that the actual MTU on its WAN link works
fine at 1500 bytes.

Could this be just the way your ADSL router is programmed? That
setting the MTU down only really kicks off ICMP errors, but nothing
more than that as long as the actual MTU is at 1500?

> On the other hand, when sending a large file using TCP, everything works
> perfectly, and the sender correctly reduces the segment size as soon as
> a "fragmentation needed" message is received (and this means, of course,
> that the router correctly produces that ICMP message).

And how is the "don't fragment" bit set in that case?

Bert

Albert Manfredi wrote:

> Okay, so it appears that with UDP, all works well if you set the
> "don't fragment" bit. With that bit set, the ADSL router returns the
> ICMP error, kicked off by the artificial limit you set on its WAN
> interface.

Yes, everything works as expected up to this point.

> Seems like if the don't fragment flag is clear, then the router
> doesn't kick off the ICMP error

This is OK (it would kick it off only if the DF bit was set). What is
strange is that the router itself does not fragment further to adapt to the
WAN MTU. If it did, the source would not know, but wireshark at the
receiver would show the additional fragmentation, I suppose, and instead
the capture at the receiver looks exactly like the capture at the sender:
same fragments, same sizes.

> , the source doesn't fragment further,

This is OK also, since the source doesn't get any "fragmentation needed"
error, so it assumes that the size it's using is fine.

> and the router discovers that the actual MTU on its WAN link works
> fine at 1500 bytes.
>
> Could this be just the way your ADSL router is programmed? That
> setting the MTU down only really kicks off ICMP errors, but nothing
> more than that as long as the actual MTU is at 1500?

I cannot check directly (I only have access to the config through a http
interface and cannot capture packets at the WAN interface), but I assume
things are just like you suggest, although this looks a bit strange. What
puzzles me is that sometimes (almost always) the router honors the WAN MTU,
but in this case it seems it does not. Perhaps the router just "tries" to
forward the packets anyway (because it somehow knows that the "real" WAN
MTU is still 1500). Yes, it's a low-end ADSL router, maybe this can account
for odd behavior here and there.

The tracepath program to a remote destination correcty detects that the MTU
becomes 1492 at the WAN interface (it uses UDP with maximum-sized
datagrams - but no IP fragments -, and with wireshark the "fragmentation
needed" message coming from the router can be seen).

>> On the other hand, when sending a large file using TCP, everything works
>> perfectly, and the sender correctly reduces the segment size as soon as
>> a "fragmentation needed" message is received (and this means, of course,
>> that the router correctly produces that ICMP message).
>
> And how is the "don't fragment" bit set in that case?

Since PMTU discovery is on by default, the DF bit is always set unless/until
a "fragmentation needed" is received. Indeed, as I said, with TCP things
work as expected: although proper IP fragmentation does not occur, as soon
as an IP packet becomes larger than 1492 bytes the router does send the
ICMP error message and the source reduces its segment size.

Thanks for your answer!