[SOLVED] getting DHCP lease when server requests MTU change

[amk]

Have strange problem with new install of gentoo amd64 in LenovoW510 laptop.

Using dhcpcd 5.2.10-r2, e1000e in 2.6.36-tuxonice-r3, everything works fine
until I attach to a network where DHCP server requests updated MTU.
Once dhcpcd tries to update MTU, carrier is lost momentarily and the
DHCP ACK does not arrive, leading to new DHCP request and no IP address
acquired.

ifconfig eth0 mtu 1430 (value requested by dhcp server) before starting interface
eth0 prevents the change and allows the lease to get accepted.

I know there is option to ignore dhcp option to set MTU but I do not want
to use that as the server has a reason to lower it.

On all other networks including wireless dhcpcd works fine for me, but they
do not ask clients to change MTU.

I am not sure about the root cause and way to address or report this issue.
Is carrier flap upon mtu change an issue with kernel, driver or dhcpcd?
The last one could eventually fix it when allowing a flap upon programming
the interface parameter? I have googled for dhcpcd issues but did not find
anything current and relevant. But it could be also that the flap is unique
to this (Intel) NIC hardware.

On all other networks including wireless dhcpcd works fine. I did not try
other dhcp clients. Initially I wanted to deploy networkmanager but this failed
for me as it cannot pass TKIP to wpa_supplicant.

[UberLord]

Your driver is at fault here.
You can do several things, assuming you cannot change the driver or the interface hardware.
1) Disable MTU in dhcpcd.conf, which you have said you don't want to do
2) Disable carrier support in dhcpcd.conf by using the nolink command for the interface with this problem
_________________
Use dhcpcd for all your automated network configuration needs
Use dhcpcd-ui (GTK+/Qt) as your System Tray Network tool

[amk]

Hi UberLord,

Only today I arrived back to the specific network to test the change suggested.
nolink in /etc/dhcpcd made the lease working: