networkmanager-1.8.0 + dhcpcd can no longer connect to a 9000 MTU network, but this was working with networkmanager-1.4.4 + dhcpcd. Reproducible: Always
Created attachment 475130 [details] networkmanager_looping.txt
networkmanager-1.4.4 did not have dhcpcd support enabled. Are you able to reproduce this with dhclient or the built-in dhcp support?
(In reply to Mike Gilbert from comment #2) > networkmanager-1.4.4 did not have dhcpcd support enabled. It did after I patched the ebuild :) > Are you able to reproduce this with dhclient or the built-in dhcp support? I have not tried a recent version of dhclient, but in the past, it did not support changing MTU where dhcpcd did.
I would suggest you work with the upstream developers of NetworkManager and dhcpcd to resolve this.
I have now tried the available DHCP clients. dhclient : ignores MTU option from server dhcpcd : loops internal : loops I think one of the internal timeouts has been shortened in networkmanager-1.8.0, and it gives-up before the MTU change can complete.
(In reply to cyrillic from comment #5) Thanks for testing.
Created attachment 475314 [details, diff] disconnect_delay.patch I am not sure if this is hardware specific, but MTU change takes right around 4 seconds for me, and relaxing this timeout completely fixes the problem I was having. Tested on networkmanager-1.8.0 and networkmanager-9999, Intel 1Gb and 10Gb ethernet.
Same problem here since networkmanager-1.8.0. Intel 82567LM Gigabit Intel 82574L Gigabit The problem appears on all my locally configured machines with a 9000 MTU and autoconnected. In manual connection, this works correctly. The patch works for my case. Thanks Cyrillic
Created attachment 506916 [details, diff] device-carrier-wait-timeout
fixed upstream https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=eb95d6bbbb6982dac78949368fc8b2512aa906bb
Does this mean the timeout can now be changed in a config file somewhere ?