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!