<div dir="ltr"><div dir="ltr"><div><br></div><div>Hi Michael,</div><div><br></div><div>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. <br></div><div>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 "<span id="gmail-scope_id_a35315ec" class="gmail-scope-head">apply_netdev_settings".</span></div><div>Would it have any other side-effects? Please correct me if I am wrong.<br></div><div><br></div><div><b>Commented out the below code in netdev_close api </b><br></div><div><table class="gmail-highlight gmail-tab-size gmail-js-file-line-container gmail-js-code-nav-container gmail-js-tagsearch-file"><tbody><tr><td id="gmail-LC866" class="gmail-blob-code gmail-blob-code-inner gmail-js-file-line"> num_configs = <span class="gmail-pl-c1">table_num_entries</span> ( NET_DEVICE_CONFIGURATORS );</td>
</tr>
<tr>
</tr></tbody></table><table class="gmail-highlight gmail-tab-size gmail-js-file-line-container gmail-js-code-nav-container gmail-js-tagsearch-file"><tbody><tr><td id="gmail-LC867" class="gmail-blob-code gmail-blob-code-inner gmail-js-file-line"> <span class="gmail-pl-k">for</span> ( i = <span class="gmail-pl-c1">0</span> ; i < num_configs ; i++ )</td>
</tr>
<tr>
</tr></tbody></table> <span class="gmail-pl-c1">intf_close</span> ( &netdev-><span class="gmail-pl-smi">configs</span>[i].<span class="gmail-pl-smi">job</span>, -ECANCELED );</div></div><div><br></div><div>Regards</div><div>Mohamed Shah R<br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 14, 2023 at 7:15 PM Michael Brown via ipxe-devel <<a href="mailto:ipxe-devel@lists.ipxe.org">ipxe-devel@lists.ipxe.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 13/03/2023 21:31, Michael Brown via ipxe-devel wrote:<br>
> There is what looks like a bug when using DHCP to change MTU: the change <br>
> of MTU requires the interface to be closed and reopened, but closing the <br>
> interface will cause the initiating DHCP transaction itself to be aborted.<br>
> <br>
> This probably requires the code in netdevice.c to be refactored slightly <br>
> to allow for a netdev_reopen() call, which skips the intf_close() calls.<br>
<br>
This is going to be very messy to support cleanly. The combination of <br>
performing a close and reopen is fairly disruptive. There are several <br>
other side effects from netdev_close() and netdev_open() (e.g. moving <br>
the device to the front of the "opened devices" list), which should <br>
probably be bypassed on an MTU change.<br>
<br>
I have a draft change in the "mtureset" branch. However, even with this <br>
added complexity, there is still the problem that on several drivers a <br>
close/reopen will have other disruptive side effects such as restarting <br>
autonegotiation.<br>
<br>
I don't see a resolution to this any time soon. Arguably the simplest <br>
workaround would be to remove the<br>
<br>
.tag = DHCP_MTU,<br>
<br>
from the definition of mtu_setting. This would prevent the MTU from <br>
being changed automatically by DHCP. A script could still set the MTU <br>
explicitly using e.g.<br>
<br>
set netX/mtu ${netX.dhcp/26}<br>
<br>
Michael<br>
<br>
_______________________________________________<br>
ipxe-devel mailing list<br>
<a href="mailto:ipxe-devel@lists.ipxe.org" target="_blank">ipxe-devel@lists.ipxe.org</a><br>
<a href="https://lists.ipxe.org/mailman/listinfo/ipxe-devel" rel="noreferrer" target="_blank">https://lists.ipxe.org/mailman/listinfo/ipxe-devel</a><br>
</blockquote></div></div>