There is nothing wrong with leaving the mtu lower. At worst you need one more packet.
Knowing hardware providers and internet providers. "no one else is reporting this" means we have not noticed that anyone else reported this, and/or there are only 2 others using this and/or we have not put together that others have this same issue. I would just leave the current fix and maybe every so often see if it is still broken. Getting through vendor tech support is typically almost impossible, they asusmping is there are no issues like this and that nobody should be passed on to the next level. And from my experience (debugging this same issue) is even if you get to a 3rd line network engineer they will argue that it is not their problem and you will have to work hard to get it past them (I am known as the troubleshooting expert in my company, and the networking experts argued that my test and results was wrong, it had to be a host problem--"expert" specialist rule #1 if I cannot find any issue then nothing is broken and then it must be someone else's issue, blame someone else and close the ticket). 90+% of the "experts" aren't experts, they are trained monkeys that know process, but don't have the slightest idea what the magic process does, and often have extra useless steps in their process that they don't understand that they think are doing something. On Sat, Dec 2, 2023 at 4:34 AM <fed...@eyal.emu.id.au> wrote: > > For the last few weeks I am trying to pinpoint the source of a network > problem. > > The short story: using the standard mtu of 1500 caused sending to stall (and > fail). > This is seen when uploading a file (e.g. ftp) or when sending email. > With an mtu of 1456 everything works. > > Everything worked unto 02:30 on 7/Nov. At that point some uploads started > hanging. > I have cron scripts that upload small and larger files. The small ones get > though, the larger ones hang. > There is enough space on the target. > > The network is simple: my server connects to a modem (wireless internet over > 4G). > > BTW, is there a more suitable list (or forum) for discussing this issue? > > I want to confirm where the problem lies. I did not change a thing on my > server. > I suspect that the modem updated its fw overnight and the new fw has an issue. > However the ISP says no one else is complaining. > > I did not find a way to downgrade the fw or install the old one. > I was given a new modem (with the old fw) but once connected to the 'net > the fw was updated, something I cannot control. > > Below is an example of the issue. > > $ sudo ifconfig eth1 mtu 1500 # this is the default, which > now fails > $ ifconfig eth1 > eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 > inet 192.168.2.7 netmask 255.255.255.0 broadcast 192.168.2.255 > > $ tracepath -4 -b -l 1500 -m 5 1.1.1.1 > 1: e5.eyal.emu.id.au (192.168.2.5) 1.109ms # > this is the modem > 2: no reply > 3: no reply > 4: no reply > 5: no reply > Too many hops: pmtu 1500 > Resume: pmtu 1500 > > ## Does the above show that the server (.7) can talk to the modem (.5) but > the modem > ## cannot talk to the external net? > ## Can it be an issue with the next hop (the 4G service)? > > $ tracepath -4 -b -l 1456 -m 5 1.1.1.1 > 1: e5.eyal.emu.id.au (192.168.2.5) 0.760ms > 2: 10.155.144.3 (10.155.144.3) 74.809ms > 3: 10.246.20.29 (10.246.20.29) 39.707ms > 4: 101.115.95.250 (101.115.95.250) 38.656ms > 5: 203-220-16-149.tpgi.com.au (203.220.16.149) 35.127ms > Too many hops: pmtu 1456 > Resume: pmtu 1456 > > $ sudo ifconfig eth1 mtu 1456 # with this everything works > well > $ ifconfig eth1 > eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1456 > inet 192.168.2.7 netmask 255.255.255.0 broadcast 192.168.2.255 > > $ tracepath -4 -b -l 1500 -m 5 1.1.1.1 > 1?: [LOCALHOST] pmtu 1456 > 1: e5.eyal.emu.id.au (192.168.2.5) 0.797ms > 1: e5.eyal.emu.id.au (192.168.2.5) 0.614ms > 2: 10.155.144.2 (10.155.144.2) 37.951ms > 3: 10.246.20.29 (10.246.20.29) 36.881ms > 4: 101.115.95.249 (101.115.95.249) 35.653ms > 5: 203-220-16-145.tpgi.com.au (203.220.16.145) 36.673ms > Too many hops: pmtu 1456 > Resume: pmtu 1456 > > $ tracepath -4 -b -l 1456 -m 5 1.1.1.1 > 1: e5.eyal.emu.id.au (192.168.2.5) 0.560ms > 2: 10.155.144.2 (10.155.144.2) 33.008ms > 3: 10.246.20.29 (10.246.20.29) 36.226ms > 4: 101.115.95.250 (101.115.95.250) 36.278ms > 5: 203-220-16-149.tpgi.com.au (203.220.16.149) 36.156ms > Too many hops: pmtu 1456 > Resume: pmtu 1456 > > -- > Eyal at Home (fed...@eyal.emu.id.au) > -- > _______________________________________________ > users mailing list -- users@lists.fedoraproject.org > To unsubscribe send an email to users-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
