Re: Broken PMTUD / ICMP blackhole?
On Tue, 17 Dec 2019 07:15:21 +0100
<tomas@tuxteam.de> wrote:
> On Mon, Dec 16, 2019 at 10:37:12PM -0500, Celejar wrote:
> > Hi,
> >
> > I have a Debian Sid system with generally working networking. Recently,
> > I experienced some strange connectivity problems with a particular
> > network connection [...]
>
> > PING 1.1.1.1 (1.1.1.1) 1492(1520) bytes of data.
> > ping: local error: message too long, mtu=1500
>
> I don't know the error message by heart, but here, it seems
> the message size is too big for your local MTU...
Yes, I think this is pretty clear. The local wifi interface has the
standard MTU of 1500, so it rejects packets larger than that.
> > With nnnn = 1472, I get, at least sometimes:
> >
> > >From 192.168.43.245 icmp_seq=2 Frag needed and DF set (mtu = 1472)
>
> This is definitely an ICMP message you receive from some upstream
Yes, except that I don't see this message consistently. I assume that's
some sort of upstream flakiness.
> > followed by (for various values of nnnn):
> >
> > ping: local error: message too long, mtu=1472
> >
> > until I drop below 1444, at which point I once again get no reply,
> > until nnnn <= 1412, at which point I once again get normal ping replies.
>
> Someone upstream is dropping the packets, perhaps sending an ICMP
> back (possibly "fragmentation needed"), perhaps someone else is
Yes, that's what's supposed to happen, according to everything I've
read, but overly aggressive blocking of ICMP is apparently a common
problem.
> dropping that ICMP (your firewall, perhaps?)
Not running one on the local machine, and I'm pretty sure that my
gateway firewall, an OpenWrt installation in a fairly standard
configuration, isn't configuring to do that (and don't
forget that I do get some "Frag needed" messages, as above).
> > For comparison purposes, on a normal, properly behaving network
> > connection, I get normal ping replies for nnnn <= 1472, and "message
> > too long" for nnnn > 1472.
> >
> > Am I understanding this correctly, that there's some kind of PMTUD /
> > ICMP blackhole problem here?
>
> This would be my interpretation too.
>
> > If so, what can I do about it? My
> > understanding is that I can either set the MTU lower on the client, or
> > do MSS clamping. Any suggestions? Is this something Mint / T-Mobile, or
> > someone upstream, is just messing up?
>
> Since you're not getting the ICMPs back, your only choice seems to be
> to reduce your MTU, manually yes.
Okay. Since the largest packets that get through consistently are
1440 bytes:
$ ping -M do 1.1.1.1 -s 1412
PING 1.1.1.1 (1.1.1.1) 1412(1440) bytes of data.
1420 bytes from 1.1.1.1: icmp_seq=1 ttl=55 time=103 ms
I tried (manually) setting the MTU to 1440. So far I have indeed seen
no further problems.
Now I just have have to figure out the best place to configure this.
I'm using dhcp via /etc/network/interfaces, but the 'dhcp' method
doesn't seem to support manual MTU setting. I could use a 'supersede
interface-mtu' line in dhclient.conf, but AFAICT, options there apply to
all dhcp connections, and I can't make out a simple way to set them on
a per connection basis. I suppose I could always just put 'ip link set
wlan0 mtu 1440' in a script and hook it in to the appropriate
'iface' stanza in e/n/i with a 'post-up' line.
Thanks for the help,
Celejar
Reply to: