On 13/03/2023 21:31, Michael Brown via ipxe-devel wrote:
There is what looks like a bug when using DHCP to change MTU: the change
of MTU requires the interface to be closed and reopened, but closing the
interface will cause the initiating DHCP transaction itself to be aborted.
This probably requires the code in netdevice.c to be refactored slightly
to allow for a netdev_reopen() call, which skips the intf_close() calls.
This is going to be very messy to support cleanly. The combination of
performing a close and reopen is fairly disruptive. There are several
other side effects from netdev_close() and netdev_open() (e.g. moving
the device to the front of the "opened devices" list), which should
probably be bypassed on an MTU change.
I have a draft change in the "mtureset" branch. However, even with this
added complexity, there is still the problem that on several drivers a
close/reopen will have other disruptive side effects such as restarting
autonegotiation.
I don't see a resolution to this any time soon. Arguably the simplest
workaround would be to remove the
.tag = DHCP_MTU,
from the definition of mtu_setting. This would prevent the MTU from
being changed automatically by DHCP. A script could still set the MTU
explicitly using e.g.
set netX/mtu ${netX.dhcp/26}
Michael
_______________________________________________
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel
