On 2021-12-17 07:09:52 +0000, Tim Woodall wrote: > On Fri, 17 Dec 2021, Vincent Lefevre wrote: > > > Dan Ritter wrote: > > > ip link set USBNET0 mtu 1450, or something like that. I don't > > > know NetworkManager's syntax for that; random googling suggests > > > that they at least had a historical problem with not being able > > > to set MTU on anything other than a pure ethernet or wifi link, > > > but perhaps they've solved that? > > > > "ip link" works on its side. I can see with wireshark that something > > like "ip link set usb0 mtu 1300" is honored, but this doesn't solve > > the problem (I've tried various values from 1000 to 1450). > > > > Note that I could also see with wireshark that the iptables rules > > with --clamp-mss-to-pmtu did not change the packet lengths. > > > > Does this happen on any connection or just some?
On any IPv4 connection (tested with ssh to 2 remote machines, and with https on various web servers). IPv6 connections seem fine. > You said you could reproduce using ssh? Does that mean you can run > wireshark on both ends and see which packet is getting lost? I haven't tried wireshark on the other end. I wonder whether there is a replacement tool that doesn't need an X11 connection, to just do the capture of the packets. > Did you try setting both mtu on the interface to something smallish > plus --clamp-mss-to-pmtu? I've just tried, and this doesn't solve the problem. > I'm pretty sure all ipv4 over mobile (which I think is what you are > testing) depends on NAT. So my other guess of a dodgy NAT device isn't > impossible. IIRC your ping tests suggested that ipv4 is being tunnelled > in ipv6 Where would be the issue? -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
