<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-2">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Hi Luiz,</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
I will try a remote debuger. I have never used it before.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Usually, I use Wireshark. So, I'm pretty sure what is going on from the "external" point of view.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
But this issue is "internal" - about the state inside dnsmasq.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Last week, I prepared a Python script with scapy library to send iPXE Discovery as a first discovery (without one is sent by BIOS in first stage).</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
I played a bit with a different Options setups - those specific for iPXE and general ones as well.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Besically, the content of Discovery packet has no influence on issue. </div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Dnsmasq always hang up/freezes after sending second Discovery packet in proxyDHCP mode.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Kind regards,</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Pawel</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>Od:</b> Luiz Angelo Daros de Luca <luizluca@gmail.com><br>
<b>Wysłane:</b> piątek, 7 sierpnia 2026 17:19<br>
<b>Do:</b> Pawel K <pawelk_ol@outlook.com><br>
<b>DW:</b> dnsmasq-discuss@lists.thekelleys.org.uk <dnsmasq-discuss@lists.thekelleys.org.uk><br>
<b>Temat:</b> Re: [Dnsmasq-discuss] dnsmasq-full: proxyDHCP chainloading does not work in OpenWRT since ver. 2.91</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">Hi Pawel,<br>
<br>
> Basically, the first stage of chainloading works OK. iPXE is delivered to a client and is up and running. Then, for the next stage - a script delivery, client timeout occures.<br>
> From OpenWRT side, in Processes tab I can see that dnsmasq processing is about ~90%.<br>
> No proxyDHCP communication from the device is visble in Wireshark anymore. Dnsmasq is dead till the next device bootup.<br>
> This week I tested this with dnsmasq's tftp and external tftp (on another server).<br>
> The results are the same. So, tftp service is not a rootcause.<br>
> It appears that the DHCP Discovery command sent via iPXE causes dnsmasq to hang.<br>
><br>
> Could you be so kind and support this issue.<br>
<br>
Yes, it does look like a bug. My suggestion is to plug a remote<br>
debugger to your openwrt device and trace what it is going on.<br>
Alternatively, you can just add a bunch of prints. And wireshark is<br>
always your friend.<br>
<br>
> BTW. Although there are multiple tutors how to use dnsmasq for PXE based on pxe-boot configuration, so OpenWRT Luci interface as well, I have never managed to run dnsmasq this way. For me only pxe-serivce in /etc/dnsmasq.conf file worked.<br>
<br>
I never used Luci for that but it is possible to run PXE using openwrt<br>
configuration, even with IPv6 support. The only missing part is PXE<br>
IPv6 HTTP, which requires this patch<br>
<a href="https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2026q2/018491.html">https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2026q2/018491.html</a>.<br>
It was merged into dnsmasq but I did not check if it landed in<br>
OpenWrt. The patch follow-up message shows a dnsmasq configuration<br>
that was generated from OpenWrt config. I'm using an external tftp<br>
server but local (provided by the router) ipxe config. I never used<br>
the proxyDHCP but you can temporarily not use it to rule it out. This<br>
is my openwrt config:<br>
<br>
config vendorclass<br>
option networkid 'pxebios'<br>
option vendorclass 'PXEClient:Arch:00000'<br>
<br>
config vendorclass<br>
option networkid 'pxeefi'<br>
option vendorclass 'PXEClient:Arch:00006'<br>
<br>
config vendorclass<br>
option networkid 'httpefi'<br>
option vendorclass 'HTTPClient:Arch:00016'<br>
<br>
config vendorclass<br>
option networkid 'pxeefi'<br>
option vendorclass 'PXEClient:Arch:00007'<br>
<br>
config vendorclass<br>
option networkid 'pxeefi'<br>
option vendorclass 'PXEClient:Arch:00009'<br>
<br>
config match<br>
option networkid 'pxeefi'<br>
option match 'option6:61,00:07'<br>
<br>
config match<br>
option networkid 'pxeefi'<br>
option match 'option6:61,00:09'<br>
<br>
config match<br>
option networkid 'httpefi'<br>
option match 'option6:61,00:10'<br>
<br>
config userclass<br>
option networkid 'ipxe'<br>
option userclass 'iPXE'<br>
<br>
config boot<br>
option networkid 'pxebios'<br>
option filename 'ipxe/ipxe.pxe'<br>
option serveraddress 'x.x.x.x'<br>
option servername 'netboot.mydomain'<br>
<br>
config boot<br>
option networkid 'httpefi'<br>
option filename '<a href="http://x.x.x.x/ipxe/ipxe.efi">http://x.x.x.x/ipxe/ipxe.efi</a>'<br>
option servername 'netboot.mydomain'<br>
list dhcp_option '60,HTTPClient'<br>
# This one requires the patch I mentioned<br>
list dhcp_option 'option6:vendor-class,343,HTTPClient'<br>
list dhcp_option 'option6:59,http://[xxxx:xxxx:xxxx::xxxx]/ipxe/ipxe.efi'<br>
<br>
config boot<br>
option networkid 'pxeefi'<br>
option filename 'ipxe/ipxe.efi'<br>
option serveraddress 'x.x.x.x'<br>
option servername 'netboot.mydomain.com'<br>
list dhcp_option 'option6:59,tftp://xxxx:xxxx:xxxx::xxxx/ipxe/ipxe.efi'<br>
<br>
config boot<br>
option networkid 'ipxe'<br>
option filename '/ipxe/ipxe.cfg/init.ipxe'<br>
list dhcp_option<br>
'option6:59,http://[xxxx:xxxx:xxxx::xxxx]/tftpboot/ipxe/ipxe.cfg/init.ipxe'<br>
<br>
I hope it will help you<br>
<br>
Best regards,<br>
<br>
Luiz<br>
</div>
</span></font></div>
</body>
</html>