Letting dhcpcd chaning the MTU ends in an endless loop of DHCP-queries and non-functional network connection. I'm using a MTU of 1492 in my network and distribute this MTU via DHCP. If I let dhcpcd change the MTU it results in the following: -------------------------------------------------- Oct 23 13:38:32 dockstar2 dhcpcd[2625]: version 5.2.7 starting Oct 23 13:38:32 dockstar2 dhcpcd[2625]: eth0: rebinding lease of x.x.x.x Oct 23 13:38:32 dockstar2 dhcpcd[2625]: eth0: acknowledged x.x.x.x from y.y.y.y Oct 23 13:38:32 dockstar2 dhcpcd[2625]: eth0: checking for x.x.x.x Oct 23 13:38:37 dockstar2 dhcpcd[2625]: eth0: leased x.x.x.x for 600 seconds Oct 23 13:38:37 dockstar2 dhcpcd: eth0: MTU set to 1492 Oct 23 13:38:37 dockstar2 dhcpcd[2625]: forked to background, child pid 2661 Oct 23 13:38:37 dockstar2 dhcpcd[2661]: eth0: carrier lost Oct 23 13:38:37 dockstar2 dhcpcd: eth0: MTU restored to 1500 Oct 23 13:38:40 dockstar2 kernel: [ 85.678149] eth0: link up, 1000 Mb/s, full duplex, flow control disabled Oct 23 13:38:40 dockstar2 dhcpcd[2661]: eth0: carrier acquired Oct 23 13:38:40 dockstar2 dhcpcd[2661]: eth0: rebinding lease of x.x.x.x Oct 23 13:38:40 dockstar2 dhcpcd[2661]: eth0: acknowledged x.x.x.x from y.y.y.y Oct 23 13:38:40 dockstar2 dhcpcd[2661]: eth0: checking for x.x.x.x Oct 23 13:38:46 dockstar2 dhcpcd[2661]: eth0: leased x.x.x.x for 600 seconds Oct 23 13:38:46 dockstar2 dhcpcd: eth0: MTU set to 1492 Oct 23 13:38:46 dockstar2 dhcpcd[2661]: eth0: carrier lost Oct 23 13:38:46 dockstar2 dhcpcd: eth0: MTU restored to 1500 Oct 23 13:38:49 dockstar2 kernel: [ 94.233829] eth0: link up, 1000 Mb/s, full duplex, flow control disabled Oct 23 13:38:49 dockstar2 dhcpcd[2661]: eth0: carrier acquired Oct 23 13:38:49 dockstar2 dhcpcd[2661]: eth0: rebinding lease of x.x.x.x Oct 23 13:38:49 dockstar2 dhcpcd[2661]: eth0: acknowledged x.x.x.x from y.y.y.y Oct 23 13:38:49 dockstar2 dhcpcd[2661]: eth0: checking for x.x.x.x Oct 23 13:38:54 dockstar2 dhcpcd[2661]: eth0: leased x.x.x.x for 600 seconds Oct 23 13:38:54 dockstar2 dhcpcd: eth0: MTU set to 1492 Oct 23 13:38:54 dockstar2 dhcpcd[2661]: eth0: carrier lost Oct 23 13:38:55 dockstar2 dhcpcd: eth0: MTU restored to 1500 Oct 23 13:38:57 dockstar2 kernel: [ 102.870805] eth0: link up, 1000 Mb/s, full duplex, flow control disabled Oct 23 13:38:57 dockstar2 dhcpcd[2661]: eth0: carrier acquired Oct 23 13:38:57 dockstar2 dhcpcd[2661]: eth0: rebinding lease of x.x.x.x Oct 23 13:38:58 dockstar2 dhcpcd[2661]: eth0: acknowledged x.x.x.x from y.y.y.y Oct 23 13:38:58 dockstar2 dhcpcd[2661]: eth0: checking for x.x.x.x Oct 23 13:39:02 dockstar2 dhcpcd[2661]: eth0: leased x.x.x.x for 600 seconds Oct 23 13:39:02 dockstar2 dhcpcd: eth0: MTU set to 1492 Oct 23 13:39:02 dockstar2 dhcpcd[2661]: eth0: carrier lost Oct 23 13:39:02 dockstar2 dhcpcd: eth0: MTU restored to 1500 Oct 23 13:39:05 dockstar2 kernel: [ 110.663669] eth0: link up, 1000 Mb/s, full duplex, flow control disabled Oct 23 13:39:05 dockstar2 dhcpcd[2661]: eth0: carrier acquired Oct 23 13:39:05 dockstar2 dhcpcd[2661]: eth0: rebinding lease of x.x.x.x Oct 23 13:39:05 dockstar2 dhcpcd[2661]: eth0: acknowledged x.x.x.x from y.y.y.y Oct 23 13:39:05 dockstar2 dhcpcd[2661]: eth0: checking for x.x.x.x Oct 23 13:39:10 dockstar2 dhcpcd[2661]: eth0: leased x.x.x.x for 600 seconds Oct 23 13:39:10 dockstar2 dhcpcd: eth0: MTU set to 1492 Oct 23 13:39:11 dockstar2 dhcpcd[2661]: eth0: carrier lost Oct 23 13:39:11 dockstar2 dhcpcd: eth0: MTU restored to 1500 Oct 23 13:39:14 dockstar2 kernel: [ 118.957185] eth0: link up, 1000 Mb/s, full duplex, flow control disabled -------------------------------------------------- Two workarounds are working here (other than using another dhcp-client): (1) Setting the MTU to 1492 in /etc/conf.d/net (mtu_eth0="1492") (2) Adding 'nohook mtu' to /etc/dhcpcd.conf The first workaround obviously ignores the reasons to distribute the MTU by DHCP. The second workaround has the problem that the MTU won't get changed to what is distributed by DHCP and the default MTU of 1500 is still used. Haven't looked at why dhcpcd loses the connection when the MTU will be changed by /lib/dhcpcd/dhcpcd-hooks/10-mtu, but this script just calls ifconfig $interface mtu $mtu.
Having a look at the sources I think this is a problem of dhcpcd. When I'm correct, than changing the MTU of an interface disconnects active connetions, which is why dhcpcd looses the connection. So dhcpcd should ignore any up/down of the IF while changing the MTU (and it should redo all done settings to the IF it has done after the if comes up again). Don't know if there is a way to change the MTU of an IF on-the-fly, but I assume not.
I've just discovered a third workaround. In my dhcpcd.conf I've seen the following: --------------------------- # Respect the network MTU. option interface_mtu --------------------------- Disabling this will have the same effect as workaround (2) (nohook mtu), the MTU will not get changed to the one received via DHCP. I will see if I can find out how to change the MTU while setting the other paramters of the IF like netmask, broadcast etc. (when I will find the time). I assume this would be the correct way.
I've just dived a little deeper into the source of dhcpcd and decided I won't do that further. I don't know if there exists a system which really supports changing the MTU on the fly without temporarily deactivating the interface (as currently dhcpcd 5.x seems to assume). So I can't decide if the hook for mtu makes sense somewhere or if it just should be removed completly. I've sent the author an e-mail.
Until this is fixed in dhcpcd, I strongly suggest to remove option interface_mtu and add nohook mtu to /etc/dhcpcd.conf because it's better to live with a wrong mtu instead of having a non-functional network through a broken dhcp-client.
I've got an answer from the author of dhcpcd. He says it's a driver issue. In the used driver (mv643xx) I see the following in eth_change_mtu(): -------------- /* * Stop and then re-open the interface. This will allocate RX * skbs of the new MTU. * There is a possible danger that the open will not succeed, * due to memory being full. */ -------------- But I don't know if this should be considered as a bug in the driver. Another driver here has problems with changing the MTU too: ----------- [ 908.654365] r8169: WARNING! Changing of MTU on this NIC may lead to frame reception errors! ----------- So the down/up during a change of the MTU might be needed for some NICs. Anyway I think it is a bad behaviour of dhcpcd to enter an endless loop when such happens.
Roy, is this behaviour the same in 5.2.8? If so, is there anything you can do to work around it, or should I have the user adjust his configuration as he has already done? Are there enough cards out there that cause this behaviour that we should consider changing the default configuration? Thanks, William
This was been default dhcpcd behaviour for quite some time now and I see no good reason to change it. Based on the number of bug reports I've had regarding this (this one for Linux, one for NetBSD wm(4) driver) I would say that most drivers operate correctly. To work around the buggy driver the user can disable MTU or link checking in /etc/dhcpcd.conf TBH, I personally enforce an MTU of 1492 on my network via DHCP and all of my devices (which is quite a few) have no problem here.
For me it's ok to close this bug it seems to be problem of the driver. Anyway it is not that seldom, that drivers are behaving like mv643xx does it currently. I've come across various posts while searching the web for this problem. Most of them had such an problem when they stayed temporarily in a hotel or somewhere similiar where the DHCP-server sends an unusual MTU. And the solution, if any, was almost always to change the dhcp-client.
A fast solution inside dhcpcd could be to not reset the MTU when the carrier gets lost while the hook to change the MTU will be called.
"to not reset the MTU to the default value of 1500" would be the correct description of my proposed solution inside dhcpcd.
I am closing this bug per comment #8.
