On Sun, 1 Feb 1998, Jukka Marin wrote:

> I have been whining about this before.. and not it is happening to me
> again.
> 
> Someone is trying to send mail to our machine from a m$ system, it seems.
> The sender uses large IP packets with the DF flag set.  My NetBSD 1.2
> router can't transmit the packets over a PPP line due to MTU of 576 bytes,
> so it responds to the sender like this:
> 
> 13:44:04.878280 mailhost.orion.fi.34036 > kyyhky.jmp.fi.smtp: P 138:1598(1460) ack 373 win 8760 (DF)
> 13:44:04.878446 muikku.jmp.fi > mailhost.orion.fi: icmp: kyyhky.jmp.fi unreachable - need to frag (DF)
> 
> Of course, the sender doesn't care but tries to send the packet all over
> again.  Finally, it opens a new SMTP connection to our system and I end up
> with several sendmail processes just hanging there, getting no data from
> the sender.
> 
> Is there a way to tell the NetBSD 1.2 router to fragment the packets so
> they would get through?  I have mailed to the postmaster of the sender
> system, but if every single m$ driven machine in the world has this problem,
> I will spend the rest of my life trying to convince them to get their TCP/IP
> fixed... :-(
> 
> It should be illegal to connect broken systems to the net!

The problem isn't the system, but rather that some dumb admin has decided
to filter all ICMP.  The same thing can cause problems on any system that
tries to do PMTU discovery.  There are _many_ systems with this problems,
even systems colocated at (insert large NSP's name) that should know
better.

A workaround is to lower the MTU on the end system, since the remote end
shouldn't try sending something that won't fit into your advertised MSS.
Something _directly_ connected to an interface with a low MTU shouldn't
cause problems, only something behind a router that has a low MTU.  

I'm not aware of any systems that do PMTU discovery that try backing down
eventually to overcome cases like this.  Ok, that's not true.  I have
heard of one, but can't remember the name.