Hi Michael,
Thanks for the quick response. I am new to the PXE source code and tried
out the below changes for the experimental testing in the netdev_close api
and it works fine.
Why can't we have a new api netdev_reopen() which does the same logic of
netdev_close (except the code below) and calls the netdev_open existing api
and calls the netdev_reopen api only from the "apply_netdev_settings".
Would it have any other side-effects? Please correct me if I am wrong.
*Commented out the below code in netdev_close api *
num_configs = table_num_entries ( NET_DEVICE_CONFIGURATORS );
for ( i = 0 ; i < num_configs ; i++ )
intf_close ( &netdev->configs[i].job, -ECANCELED );
Regards
Mohamed Shah R
On Tue, Mar 14, 2023 at 7:15 PM Michael Brown via ipxe-devel <
ipxe-devel@lists.ipxe.org> wrote:
> 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
>
_______________________________________________
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel
