A few bytes or more less than any advertised. The underlying issue is that I advertise say 1500bytes MTU (when asked or when fragmenting) but only allow say 1496 to actually pass. Usually when I have seen it happen it has been a switch that has an enforced MTU limit set, but it could be any device that advertises the MTU as X but only actually allows X-4 (or smaller). The it10t device does not know it needs to fragment and as such it does not/cannot report that it needs to fragment the packet, it typically simply drops the package that it thinks is too large on the ground and tells no one about it. it might be something about how your network is put together and/or how you are using it that exposes the bug in whatever device it is. I have seen vendors have stuff that simply could not work but no one could understand why anything was working given what was found. Code that should not work often "works" well enough for developers to think it works. What kind of devices do you have between your linux node and the providers network? Ie the modem and any routers. On Sat, Dec 2, 2023 at 7:43 AM Roger Heflin <rogerheflin@xxxxxxxxx> wrote: > > My experience with the MTU being wrong is that often nothing works to > inform the sending end that the MTU is wrong. > > The MTU being wrong (and below 1500) is not an expected/handled > condition for the TCP stack. meaning it will break for anything that > uses a MTU above the size, especially if the wrong MTU is a few > byte(or more) than any advertised MTU in the path. > > So what does your network diagram look like? > > > On Sat, Dec 2, 2023 at 7:28 AM <fedora@xxxxxxxxxxxxxx> wrote: > > > > On 2/12/23 23:01, Markus Schönhaber wrote: > > > 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. > > > > I will double check, though the network worked well until then, so I cannot see > > how my side is the cause. The system was rebooted since and the problem persisted. > > > > >> 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. > > > > I did not do any change to the firewall, which is probably the only place > > I could break things (like dropping ICMP). > > The modem has a feature "IPv4 SPI Firewall" and turning it off did not help here. > > > > Anyway, if icmp if dropped then I expect simple pings will not get though either, right? > > > 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. > > > > No, I actually tried and any higher than 1456 and it fails. > > This is a wireless (4G) internet modem. > > > > >> 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 (fedora@xxxxxxxxxxxxxx) > > -- > > _______________________________________________ > > 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 -- _______________________________________________ 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
