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