On Tue, 17 Dec 2019 07:15:21 +0100 <to...@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