By changing mtu in any way the link is physically lost for a moment (it is sensed on the other end of the wire, too) This behavior is disruptive when the mtu is changed during dhcp: dhcpcd senses that the carrier is lost and restart the configuration process, thus entering an infinite loop. ISC's dhclient seems tolerant of such small disconnection but changing the default dhcp client of a distro is not easy nor recommended. All means of changing the mtu produce this effect: ifconfig, ip link and directly writing to /sys/class/net/eth0/mtu. The distribution is Archlinux, latest stable kernel, clean installation on a Dell Latitude E6430. I did not save the logs, but the issue is affecting other users, like: https://bbs.archlinux.org/viewtopic.php?id=79923 http://forums.gentoo.org/viewtopic-t-869743.html Proper behavior requires that mtu changes do not break the link. It seems like some kind of shortcut has been taken in the code: reinitialize everything instead of just what is needed.
Is any other information required to check the validity of this bug?