[ On Tuesday, April 20, 1999 at 10:53:39 (-0400), James FitzGibbon wrote: ]
> Subject: Re: SOLVED -- Re: [EXIM] (un)blocking dynamic IP addresses [Was: A way to do this?]
>
> * Malcolm Beattie (mbeattie@???) [990420 08:53]:
>
> > hangs". What's happening is that the client sends larger and larger
> > packets with the "Don't Fragment" bit set so that, when the maximum
> > MTU is reached, it'll get back an "ICMP Frag Needed" packet and thus
> > know the optimum MTU. If some idiot has configured a firewall or
> > router wrongly and drops all ICMP on the floor then the "ICMP Frag
> > Needed" never arrives and the client thinks the packet has just
> > been a random drop and keeps resending.
>
> Using a combination of tcpdump/tcpshow, it should be pretty simple to verify
> if this is the case. Having a copy of "TCP/IP Illustrated Volume 1" would
> also be a great help.
It depends on who's Path-MTU-discovery is failing. If it's the remote
host's, then you can only see the problem on (or past) the upstream
router that would have done the fragmentation if it had been permitted
to. I.e. on or past the router that actually sends the "needs frag"
reply to the host doing Path-MTU-discovery. The problem is *totally*
invisible to the host "behind" the router with the smaller MTU -- the
best you can do is to guess that if ICMP "echo request" (ping) packets
don't get through then all ICMP is being filtered somewhere upstream,
but this isn't always the case.
BTW, if you can actually watch all packets flow between the two hosts
directly on the suspect router then it is immediately obvious what's
wrong -- I think even to someone who doesn't know very many details
about TCP/IP. You'll see small packet arrive from one host and pass
through to the other, but big packets will arrive and be discarded and
ICMP "needs frag" packets will be sent in reply. Of course seeing the
DF flag on the discarded packets, and knowing what it means, is a big
clue too.
This problem can be enormously frustrating to find and fix for at least
one of the parties in the failing connection. My home network sits on
the end of a PPP connection and I often reduce the MTU to improve telnet
response, and thus I often see this problem in real life. Luckily I
have the root password on my upstream router and I can run tcpdump there
to capture traces. Unfortunately those traces don't always convince
firewall operators to correct their broken configurations, even if the
problem is that their own users can't send e-mail or whatever. Some
security officers are quite ignorant of what they're doing while at the
same time being enormously stubborn and refusing of education. Even
using a bigger stick on them often doesn't help much -- they're totally
resistant to clue-by-4s.
BTW, you may remember that I mentioned "redirectors" becoming cheaper
and somewhat more reliable. Well it's this very issue that plagues them
the worst. If you are planning to install a device that does policy
based routing, please test it to ensure that it doesn't screw up
Path-MTU. If it's a true router, it probably won't affect Path-MTU
discovery, but if it's one of those load balancers then it probably will
and you shouldn't use it until it has been 100% verified OK.
--
Greg A. Woods
+1 416 218-0098 VE3TCP <gwoods@???> <robohack!woods>
Planix, Inc. <woods@???>; Secrets of the Weird <woods@???>
--
*** Exim information can be found at
http://www.exim.org/ ***
