02.12.23, 11:33 +0100, fedora@xxxxxxxxxxxxxx: > 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. Assuming that the problem's not on your side of the network, the most likely cause I can think of, is that now somewhere along the path ICMP packets signalling the need for fragmentation get dropped, and therefore the sender doesn't learn that it should send smaller packets. You might want to double check that your network doesn't behave that way. > 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. If the update of the modem's FW happened around the same time the problem arose, that would point to the new FW as being the culprit (maybe by dropping those "evil" ICMP packets as I mused above). And as long as you're reasonably sure that the problem isn't caused by some change *you* made, and you can't control the modem's behavior, you could simply accept your fate, lower the interface MTU and move on. BTW: if your modem does PPPoE (as is common on DSL lines) it might not be needed to lower the MTU below 1492 since the PPP header occupies only 8 bytes of the ethernet frame's payload. > 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 -- Regards mks -- _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
