Re: [Dnsmasq-discuss] pxe-service entries in dnsmasq conf seem to fail non-proxy EFI boot
> I.e. if pxe-service is not matched due to tags, > to behave in the same way like if it wasn't there at all? What would that involve? Not answering in port 4011 for that client? `ss -nap | grep 4011` shows that when "pxe-service" lines exist, dnsmasq listens in that port, otherwise it doesn't. Shrenik, I wonder, if you use iptables or a firewall to completely ignore packets to 4011, does the NUC client work then even if pxe-service lines exist? (I may be complete off-base there, it's just an idea...) Cheers, Alkis On 10/6/21 8:37 AM, Alkis Georgopoulos wrote: Hi all, I haven't been able to reproduce this issue with the hardware I have access to. I think the key question that Shrenik is asking is: 1) dnsmasq works fine with his NUC when he has no pxe-service lines in his config 2) When he adds pxe-service lines with tags that DO NOT match this client, it fails to boot ==> Is it possible for dnsmasq to behave like (1) when (2) happens? I.e. if pxe-service is not matched due to tags, to behave in the same way like if it wasn't there at all? Thank you, Alkis Georgopoulos On 10/5/21 9:05 PM, Petr Menšík wrote: I could not find any relevant difference between nuc-efi.pcapng and qemu-efi.pcapng responses. They seem very similar. Yet qemu continues with TFTP download and next step. Nuc does not react anyhow to boot offer. It seems to not download or start snponly.efi. It seems to me the answer lies only on its boot rom firmware. I just expect both used matching configuration and dnsmasq version. From dnsmasq side, answer to DHCP discover and request contains expected value in expected format. Critical is any output of NUC when it receives the offer. Does it fail with any error code? Does it print any error? At least screenshot would be useful. It seems to me the problem is somewhere in its PXE implementation, which we cannot solve in dnsmasq. Because it even does not try to download and execute snponly.efi, even iPXE build with debug logs (which I am not sure how to enable btw) would not help. What kind machine it is? Does it have the latest bios firmware available? Would this machine boot at least snponly.efi if pxe-service were commented out? It seems similar to previous intel_nuc_efi_with_ltsp-pxeservice.pcapng file requests, but it does use proxyDHCP requests like the old one. How changed dnsmasq configuration to make this change? How does dnsmasq.conf look like for it? Option 43 suboption PXE discovery control (6) is different now. It seems not well received by PXE firmware this time. Used config file of dnsmasq is not attached this time, I can only guess. HW address is different, not sure how different is used machine. Was it this machine, which returned PXE-E21: Remote boot cancelled.? Returned control to LoadFile control seems suspicious. May it require non-efi image instead? If you can reach support for this machine, I think it might be reported to them. Especially about how PXE menu can specify Local Boot? I am afraid I don't know how to help now. If one machine can boot with the same setup that another cannot, it is up to you to find commonly working configuration. On 9/30/21 12:47, Shrenik Bhura wrote: > > 1. seems to have wrong pcap file or it does not use configuration attached in linked archive. It seems it offers > menu items from 2. archive with custom pxe-services. >> > Apologies, there was definitely some mistake. >> > We have applied the patch and tried with and without dhcp-no-override > but it still fails to boot. Herein are the pcap and the logs for this > case. > https://drive.google.com/file/d/1-GvsId99FC8f8B2I0YaTVuje5385u4LC/view?usp=sharing >> > Additionally, also included is the qemu pcap wherein it does boot > successfully. >> > On Wed, 29 Sept 2021 at 20:29, Petr Menšík wrote: >> > It is somehow hard to guess described results for each > configuration (1. 2. 3.). It is unclear to me, what you saw for > each variant printed by the computer. >> > 1. seems to have wrong pcap file or it does not use configuration > attached in linked archive. It seems it offers menu items from 2. > archive with custom pxe-services. >> > Option 43 Suboption: (9) PXE boot menu > Length: 41 > boot menu: > 8000155058454c494e555820285838362d36345f4546492980010e5058454c494e555820… > Type: Unknown (32768) > Length: 21 > Description: PXELINUX (X86-64_EFI) > Type: Unknown (32769) > Length: 14 > Description: PXELINUX (EFI) >> > Above is not present in config file presented for it, but in 2. > Are you sure you have killed dnsmasq and started it again? >> > I think it might be difference between pxe-service served file > chosen via menuboot. I have noticed there are two way to specify > file to boot in DHCP for IPv4. One is in fixed header and first > try chosen from menu is in that. pxe-service options makes
Re: [Dnsmasq-discuss] pxe-service entries in dnsmasq conf seem to fail non-proxy EFI boot
Hi all, Alkis has highlighted the main question once again. Thanks Alkis. Now trying to provide the answers to Petr's queries - It seems to me the answer lies only on its boot rom firmware. I just expect > both used matching configuration and dnsmasq version. > This is the case with an Intel NUC NUC5CPYH mini PC, Dell Optiplex 3040 desktop PC and an old Thinkpad X1 laptop. So definitely not a unique case with just one boot ROM firmware. But works fine with qemu. It is because qemu "uses iPXE to implement the VM's PXE firmware".[1] So comparison with output from qemu is not an ideal one. Maybe Alkis can help with the pcap and logs from efi hardware that is booting fine in the non-proxy mode. Does it fail with any error code? Does it print any error? At least > screenshot would be useful. It seems to me the problem is somewhere in its > PXE implementation, which we cannot solve in dnsmasq. > This is visible on the screen for a very brief period of time - PXE-E21: Remote boot cancelled. Once again, it doesn't seem to be a very specific problem in only a specific hardware's PXE implementation since I am experiencing it in hardware from several vendors. An extra observation - all my test hardwares' manufacturing is older than 2017. Because it even does not try to download and execute snponly.efi, even iPXE > build with debug logs (which I am not sure how to enable btw) would not > help. > Based on your earlier guidance, we had enabled the iPXE logging as per the instructions on their website but yet got nothing helpful for the failed cases to diagnose this issue. Does it have the latest bios firmware available? Would this machine boot at > least snponly.efi if pxe-service were commented out? > Yes, the Intel NUC has the latest BIOS firmware from 2019. Thereafter, this hardware has reached end-of-life and Intel no longer provides support for it. Yes, this machine boots perfectly fine with pxe-service commented out. It seems similar to previous intel_nuc_efi_with_ltsp-pxeservice.pcapng file > requests, but it does use proxyDHCP requests like the old one. > The nuc-efi.pcapng shared ( https://drive.google.com/file/d/1-GvsId99FC8f8B2I0YaTVuje5385u4LC/view?usp=sharing) in the last email is from a similar model Intel NUC NUC5CPYH machine but not the exact same device. As you had correctly pointed out, the intel_nuc_efi_with_ltsp-pxeservice.pcapng was the wrong file that I had shared earlier via this link - https://drive.google.com/file/d/1-BGnZw4RMAuIbJudVA2D4a1vasNeAd1j/view?usp=sharing on 27th September. > How changed dnsmasq configuration to make this change? How does > dnsmasq.conf look like for it? > Used config file of dnsmasq is not attached this time, I can only guess. HW > address is different, not sure how different is used machine. > The dnsmasq conf that does not work is attached below - ltsp-dnsmasq-default-with-pxe-service.conf The dnsmasq conf that works is also attached below - ltsp-dnsmasq-default-without-pxe-service.conf HW address is different because we used another device of the same model as already stated above. Was it this machine, which returned PXE-E21: Remote boot cancelled.? Returned > control to LoadFile control seems suspicious. May it require non-efi image > instead? If you can reach support for this machine, I think it might be > reported to them. Especially about how PXE menu can specify Local Boot? > Yes, all machines that I have tested booting with EFI booting in non-proxy mode are returning this. All these machines boot fine with BIOS in non-proxy mode i.e. when supplied with undionly.kpxe instead of snponly.efi. Support for any of my test machines is not available any more from the hardware vendors as the models have all reached end-of-life. If one machine can boot with the same setup that another cannot, it is up > to you to find commonly working configuration. > I don't have any machine that boots and I would not count QEMU as a worthy comparison for this case.[1] @Alkis, may I request you to provide the pcap and logs for a case where an efi client boots successfully in non-proxy mode? and / or @Petr is it possible to try simulating the same scenario at your end with the provided conf files? Thanks & regards, Shrenik [1]* As a special case (in a positive sense), when PXE-booting a KVM virtual machine the very first request that the server sees already comes from iPXE, since that's what qemu uses to implement the VM's PXE "firmware".* - from https://backreference.org/2013/11/24/pxe-server-with-dnsmasq-apache-and-ipxe/ ltsp-dnsmasq-default-with-pxe-service.conf Description: Binary data ltsp-dnsmasq-default-without-pxe-service.conf Description: Binary data ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] pxe-service entries in dnsmasq conf seem to fail non-proxy EFI boot
Hi all, I haven't been able to reproduce this issue with the hardware I have access to. I think the key question that Shrenik is asking is: 1) dnsmasq works fine with his NUC when he has no pxe-service lines in his config 2) When he adds pxe-service lines with tags that DO NOT match this client, it fails to boot ==> Is it possible for dnsmasq to behave like (1) when (2) happens? I.e. if pxe-service is not matched due to tags, to behave in the same way like if it wasn't there at all? Thank you, Alkis Georgopoulos On 10/5/21 9:05 PM, Petr Menšík wrote: I could not find any relevant difference between nuc-efi.pcapng and qemu-efi.pcapng responses. They seem very similar. Yet qemu continues with TFTP download and next step. Nuc does not react anyhow to boot offer. It seems to not download or start snponly.efi. It seems to me the answer lies only on its boot rom firmware. I just expect both used matching configuration and dnsmasq version. From dnsmasq side, answer to DHCP discover and request contains expected value in expected format. Critical is any output of NUC when it receives the offer. Does it fail with any error code? Does it print any error? At least screenshot would be useful. It seems to me the problem is somewhere in its PXE implementation, which we cannot solve in dnsmasq. Because it even does not try to download and execute snponly.efi, even iPXE build with debug logs (which I am not sure how to enable btw) would not help. What kind machine it is? Does it have the latest bios firmware available? Would this machine boot at least snponly.efi if pxe-service were commented out? It seems similar to previous intel_nuc_efi_with_ltsp-pxeservice.pcapng file requests, but it does use proxyDHCP requests like the old one. How changed dnsmasq configuration to make this change? How does dnsmasq.conf look like for it? Option 43 suboption PXE discovery control (6) is different now. It seems not well received by PXE firmware this time. Used config file of dnsmasq is not attached this time, I can only guess. HW address is different, not sure how different is used machine. Was it this machine, which returned PXE-E21: Remote boot cancelled.? Returned control to LoadFile control seems suspicious. May it require non-efi image instead? If you can reach support for this machine, I think it might be reported to them. Especially about how PXE menu can specify Local Boot? I am afraid I don't know how to help now. If one machine can boot with the same setup that another cannot, it is up to you to find commonly working configuration. On 9/30/21 12:47, Shrenik Bhura wrote: > > 1. seems to have wrong pcap file or it does not use configuration attached in linked archive. It seems it offers > menu items from 2. archive with custom pxe-services. >> > Apologies, there was definitely some mistake. >> > We have applied the patch and tried with and without dhcp-no-override > but it still fails to boot. Herein are the pcap and the logs for this > case. > https://drive.google.com/file/d/1-GvsId99FC8f8B2I0YaTVuje5385u4LC/view?usp=sharing >> > Additionally, also included is the qemu pcap wherein it does boot > successfully. >> > On Wed, 29 Sept 2021 at 20:29, Petr Menšík wrote: >> > It is somehow hard to guess described results for each > configuration (1. 2. 3.). It is unclear to me, what you saw for > each variant printed by the computer. >> > 1. seems to have wrong pcap file or it does not use configuration > attached in linked archive. It seems it offers menu items from 2. > archive with custom pxe-services. >> > Option 43 Suboption: (9) PXE boot menu > Length: 41 > boot menu: > 8000155058454c494e555820285838362d36345f4546492980010e5058454c494e555820… > Type: Unknown (32768) > Length: 21 > Description: PXELINUX (X86-64_EFI) > Type: Unknown (32769) > Length: 14 > Description: PXELINUX (EFI) >> > Above is not present in config file presented for it, but in 2. > Are you sure you have killed dnsmasq and started it again? >> > I think it might be difference between pxe-service served file > chosen via menuboot. I have noticed there are two way to specify > file to boot in DHCP for IPv4. One is in fixed header and first > try chosen from menu is in that. pxe-service options makes it to > request direct query to DHCP server, marked proxyDHCP in > wireshark. This proxy ACK is followed by TFTP. >> > I used filter in wireshark: "dhcp or (!tftp.destination_file && tftp)" >> > However following DHCP offers boot file path ONLY in option 67 > value. Fixed header boot file is all zeroed. It seems to me this > is the part the snponly.efi firmware does not understand. It does > not try to use path in option, but may insist only on file. Since > option #52 overload is not in packet, I guess dnsmasq should have > used mess->file for path and not option
Re: [Dnsmasq-discuss] pxe-service entries in dnsmasq conf seem to fail non-proxy EFI boot
I could not find any relevant difference between nuc-efi.pcapng and qemu-efi.pcapng responses. They seem very similar. Yet qemu continues with TFTP download and next step. Nuc does not react anyhow to boot offer. It seems to not download or start snponly.efi. It seems to me the answer lies only on its boot rom firmware. I just expect both used matching configuration and dnsmasq version. >From dnsmasq side, answer to DHCP discover and request contains expected value in expected format. Critical is any output of NUC when it receives the offer. Does it fail with any error code? Does it print any error? At least screenshot would be useful. It seems to me the problem is somewhere in its PXE implementation, which we cannot solve in dnsmasq. Because it even does not try to download and execute snponly.efi, even iPXE build with debug logs (which I am not sure how to enable btw) would not help. What kind machine it is? Does it have the latest bios firmware available? Would this machine boot at least snponly.efi if pxe-service were commented out? It seems similar to previous intel_nuc_efi_with_ltsp-pxeservice.pcapng file requests, but it does use proxyDHCP requests like the old one. How changed dnsmasq configuration to make this change? How does dnsmasq.conf look like for it? Option 43 suboption PXE discovery control (6) is different now. It seems not well received by PXE firmware this time. Used config file of dnsmasq is not attached this time, I can only guess. HW address is different, not sure how different is used machine. Was it this machine, which returned PXE-E21: Remote boot cancelled.? Returned control to LoadFile control seems suspicious. May it require non-efi image instead? If you can reach support for this machine, I think it might be reported to them. Especially about how PXE menu can specify Local Boot? I am afraid I don't know how to help now. If one machine can boot with the same setup that another cannot, it is up to you to find commonly working configuration. On 9/30/21 12:47, Shrenik Bhura wrote: > > 1. seems to have wrong pcap file or it does not use configuration attached > > in linked archive. It seems it offers > menu items from 2. archive with custom pxe-services. > > Apologies, there was definitely some mistake. > > We have applied the patch and tried with and without dhcp-no-override > but it still fails to boot. Herein are the pcap and the logs for this > case. > https://drive.google.com/file/d/1-GvsId99FC8f8B2I0YaTVuje5385u4LC/view?usp=sharing > > Additionally, also included is the qemu pcap wherein it does boot > successfully. > > On Wed, 29 Sept 2021 at 20:29, Petr Menšík wrote: > > It is somehow hard to guess described results for each > configuration (1. 2. 3.). It is unclear to me, what you saw for > each variant printed by the computer. > > 1. seems to have wrong pcap file or it does not use configuration > attached in linked archive. It seems it offers menu items from 2. > archive with custom pxe-services. > > Option 43 Suboption: (9) PXE boot menu > Length: 41 > boot menu: > 8000155058454c494e555820285838362d36345f4546492980010e5058454c494e555820… > Type: Unknown (32768) > Length: 21 > Description: PXELINUX (X86-64_EFI) > Type: Unknown (32769) > Length: 14 > Description: PXELINUX (EFI) > > Above is not present in config file presented for it, but in 2. > Are you sure you have killed dnsmasq and started it again? > > I think it might be difference between pxe-service served file > chosen via menuboot. I have noticed there are two way to specify > file to boot in DHCP for IPv4. One is in fixed header and first > try chosen from menu is in that. pxe-service options makes it to > request direct query to DHCP server, marked proxyDHCP in > wireshark. This proxy ACK is followed by TFTP. > > I used filter in wireshark: "dhcp or (!tftp.destination_file && tftp)" > > However following DHCP offers boot file path ONLY in option 67 > value. Fixed header boot file is all zeroed. It seems to me this > is the part the snponly.efi firmware does not understand. It does > not try to use path in option, but may insist only on file. Since > option #52 overload is not in packet, I guess dnsmasq should have > used mess->file for path and not option 67. But rules of > rfc2131.c:2476 are simple. If client have requested option 67, it > should handle it as option 67. I guess it is bug in snponly.efi. > Either it should not include option 67 between requested options > or it should actually handle the option. Dnsmasq would offer boot > path in both cases. > > Interesting enough, dnsmasq is inconsistent with itself. It > behaves a bit different way in PXE proxy mode, where file header > part is always used. In normal mode unless --dhcp-no-override is > used, option is used if requested.
Re: [Dnsmasq-discuss] pxe-service entries in dnsmasq conf seem to fail non-proxy EFI boot
Hi Petr, Is there anything else needed from me on this to diagnose this further? Last I had shared the log and pcap corresponding to the case 1. i.e., pxe-service entries with tag:proxy with dhcp-boot . Regards, Shrenik On Thu, 30 Sep, 2021, 16:17 Shrenik Bhura, wrote: > > 1. seems to have wrong pcap file or it does not use configuration > attached in linked archive. It seems it offers menu items from 2. archive > with custom pxe-services. > > Apologies, there was definitely some mistake. > > We have applied the patch and tried with and without dhcp-no-override but > it still fails to boot. Herein are the pcap and the logs for this case. > > https://drive.google.com/file/d/1-GvsId99FC8f8B2I0YaTVuje5385u4LC/view?usp=sharing > > Additionally, also included is the qemu pcap wherein it does boot > successfully. > > On Wed, 29 Sept 2021 at 20:29, Petr Menšík wrote: > >> It is somehow hard to guess described results for each configuration (1. >> 2. 3.). It is unclear to me, what you saw for each variant printed by the >> computer. >> >> 1. seems to have wrong pcap file or it does not use configuration >> attached in linked archive. It seems it offers menu items from 2. archive >> with custom pxe-services. >> >> Option 43 Suboption: (9) PXE boot menu >> Length: 41 >> boot menu: >> 8000155058454c494e555820285838362d36345f4546492980010e5058454c494e555820… >> Type: Unknown (32768) >> Length: 21 >> Description: PXELINUX (X86-64_EFI) >> Type: Unknown (32769) >> Length: 14 >> Description: PXELINUX (EFI) >> >> Above is not present in config file presented for it, but in 2. Are you >> sure you have killed dnsmasq and started it again? >> >> I think it might be difference between pxe-service served file chosen via >> menuboot. I have noticed there are two way to specify file to boot in DHCP >> for IPv4. One is in fixed header and first try chosen from menu is in that. >> pxe-service options makes it to request direct query to DHCP server, marked >> proxyDHCP in wireshark. This proxy ACK is followed by TFTP. >> >> I used filter in wireshark: "dhcp or (!tftp.destination_file && tftp)" >> >> However following DHCP offers boot file path ONLY in option 67 value. >> Fixed header boot file is all zeroed. It seems to me this is the part the >> snponly.efi firmware does not understand. It does not try to use path in >> option, but may insist only on file. Since option #52 overload is not in >> packet, I guess dnsmasq should have used mess->file for path and not option >> 67. But rules of rfc2131.c:2476 are simple. If client have requested option >> 67, it should handle it as option 67. I guess it is bug in snponly.efi. >> Either it should not include option 67 between requested options or it >> should actually handle the option. Dnsmasq would offer boot path in both >> cases. >> >> Interesting enough, dnsmasq is inconsistent with itself. It behaves a bit >> different way in PXE proxy mode, where file header part is always used. In >> normal mode unless --dhcp-no-override is used, option is used if requested. >> >> Can you please try if dhcp-no-override option would fix your issues? I >> think it should behave the same way in both situations. >> >> I attached patch, which would set boot file on pxe-service the same way >> as dhcp-boot. It may require dhcp-no-override where it did not before. >> Could you please try it? >> On 9/28/21 11:54, Shrenik Bhura wrote: >> >> Hi Petr, >> >> As per your guidance, we have enabled logging (LOG_ALL in >> config/consolle.h) and recompiled the ipxe binaries. Below are the latest >> observations. >> >> Taking down the scenarios from the previous post for ease of reference - >> 1. Default dnsmasq config with default ltsp's pxe-service entries - >> https://drive.google.com/file/d/1-BGnZw4RMAuIbJudVA2D4a1vasNeAd1j/view?usp=sharing >> 2. Custom pxe-service entries (just to prove that pxe-service and >> dhcp-boot do seem to successfully co-exist) - >> https://drive.google.com/file/d/1-CjHXxlKmYw-9aOTD7xK8m5uAdj4qyAB/view?usp=sharing >> 3. Without pxe-service entries - >> https://drive.google.com/file/d/1-6Q_1Fg6zVVNruzQTJjxvmKRRkRnCBmh/view?usp=sharing >> >> I'll try to summarise the understanding and prevailing ambiguities thus >> far to help allot responsibility of multiple things that may be going wrong >> here : >> >> Between scenario (1) and (2), we see that ltsp.ipxe is being served in >> (2) which doesn't happen in (1). >> In (1), the primary issue is that EFI clients do not receive snponly.efi, >> thus they do not advertise option 175 and hence are not sent the ltsp.ipxe. >> Since it has not got to the iPXE stage as yet, there are no logs available >> from ipxe. All that is visible momentarily on the client side is these two >> lines - >> >> *Station IP address is 192.168.67.134 * >> *PXE-E21: Remote boot cancelled.* >> Quoting from an explanation herein [1] for "Remote boot cancelled" - >> *" This message is also displayed when a
Re: [Dnsmasq-discuss] pxe-service entries in dnsmasq conf seem to fail non-proxy EFI boot
> 1. seems to have wrong pcap file or it does not use configuration attached in linked archive. It seems it offers menu items from 2. archive with custom pxe-services. Apologies, there was definitely some mistake. We have applied the patch and tried with and without dhcp-no-override but it still fails to boot. Herein are the pcap and the logs for this case. https://drive.google.com/file/d/1-GvsId99FC8f8B2I0YaTVuje5385u4LC/view?usp=sharing Additionally, also included is the qemu pcap wherein it does boot successfully. On Wed, 29 Sept 2021 at 20:29, Petr Menšík wrote: > It is somehow hard to guess described results for each configuration (1. > 2. 3.). It is unclear to me, what you saw for each variant printed by the > computer. > > 1. seems to have wrong pcap file or it does not use configuration attached > in linked archive. It seems it offers menu items from 2. archive with > custom pxe-services. > > Option 43 Suboption: (9) PXE boot menu > Length: 41 > boot menu: > 8000155058454c494e555820285838362d36345f4546492980010e5058454c494e555820… > Type: Unknown (32768) > Length: 21 > Description: PXELINUX (X86-64_EFI) > Type: Unknown (32769) > Length: 14 > Description: PXELINUX (EFI) > > Above is not present in config file presented for it, but in 2. Are you > sure you have killed dnsmasq and started it again? > > I think it might be difference between pxe-service served file chosen via > menuboot. I have noticed there are two way to specify file to boot in DHCP > for IPv4. One is in fixed header and first try chosen from menu is in that. > pxe-service options makes it to request direct query to DHCP server, marked > proxyDHCP in wireshark. This proxy ACK is followed by TFTP. > > I used filter in wireshark: "dhcp or (!tftp.destination_file && tftp)" > > However following DHCP offers boot file path ONLY in option 67 value. > Fixed header boot file is all zeroed. It seems to me this is the part the > snponly.efi firmware does not understand. It does not try to use path in > option, but may insist only on file. Since option #52 overload is not in > packet, I guess dnsmasq should have used mess->file for path and not option > 67. But rules of rfc2131.c:2476 are simple. If client have requested option > 67, it should handle it as option 67. I guess it is bug in snponly.efi. > Either it should not include option 67 between requested options or it > should actually handle the option. Dnsmasq would offer boot path in both > cases. > > Interesting enough, dnsmasq is inconsistent with itself. It behaves a bit > different way in PXE proxy mode, where file header part is always used. In > normal mode unless --dhcp-no-override is used, option is used if requested. > > Can you please try if dhcp-no-override option would fix your issues? I > think it should behave the same way in both situations. > > I attached patch, which would set boot file on pxe-service the same way as > dhcp-boot. It may require dhcp-no-override where it did not before. Could > you please try it? > On 9/28/21 11:54, Shrenik Bhura wrote: > > Hi Petr, > > As per your guidance, we have enabled logging (LOG_ALL in > config/consolle.h) and recompiled the ipxe binaries. Below are the latest > observations. > > Taking down the scenarios from the previous post for ease of reference - > 1. Default dnsmasq config with default ltsp's pxe-service entries - > https://drive.google.com/file/d/1-BGnZw4RMAuIbJudVA2D4a1vasNeAd1j/view?usp=sharing > 2. Custom pxe-service entries (just to prove that pxe-service and > dhcp-boot do seem to successfully co-exist) - > https://drive.google.com/file/d/1-CjHXxlKmYw-9aOTD7xK8m5uAdj4qyAB/view?usp=sharing > 3. Without pxe-service entries - > https://drive.google.com/file/d/1-6Q_1Fg6zVVNruzQTJjxvmKRRkRnCBmh/view?usp=sharing > > I'll try to summarise the understanding and prevailing ambiguities thus > far to help allot responsibility of multiple things that may be going wrong > here : > > Between scenario (1) and (2), we see that ltsp.ipxe is being served in (2) > which doesn't happen in (1). > In (1), the primary issue is that EFI clients do not receive snponly.efi, > thus they do not advertise option 175 and hence are not sent the ltsp.ipxe. > Since it has not got to the iPXE stage as yet, there are no logs available > from ipxe. All that is visible momentarily on the client side is these two > lines - > > *Station IP address is 192.168.67.134 * > *PXE-E21: Remote boot cancelled.* > Quoting from an explanation herein [1] for "Remote boot cancelled" - > *" This message is also displayed when a DHCP/proxyDHCP server sends a > menu that auto-selects Local Boot and when a bootserver sends a bootstrap > program that returns control to the PXE LoadFile protocol. "* > > In scenario (2), PXE boot menu is displayed as defined in the pxe-service > lines, option 175 is received back from the client, ltsp.ipxe is sent but > is not "downloaded" by the client. There is nothing reported
Re: [Dnsmasq-discuss] pxe-service entries in dnsmasq conf seem to fail non-proxy EFI boot
It is somehow hard to guess described results for each configuration (1. 2. 3.). It is unclear to me, what you saw for each variant printed by the computer. 1. seems to have wrong pcap file or it does not use configuration attached in linked archive. It seems it offers menu items from 2. archive with custom pxe-services. Option 43 Suboption: (9) PXE boot menu Length: 41 boot menu: 8000155058454c494e555820285838362d36345f4546492980010e5058454c494e555820… Type: Unknown (32768) Length: 21 Description: PXELINUX (X86-64_EFI) Type: Unknown (32769) Length: 14 Description: PXELINUX (EFI) Above is not present in config file presented for it, but in 2. Are you sure you have killed dnsmasq and started it again? I think it might be difference between pxe-service served file chosen via menuboot. I have noticed there are two way to specify file to boot in DHCP for IPv4. One is in fixed header and first try chosen from menu is in that. pxe-service options makes it to request direct query to DHCP server, marked proxyDHCP in wireshark. This proxy ACK is followed by TFTP. I used filter in wireshark: "dhcp or (!tftp.destination_file && tftp)" However following DHCP offers boot file path ONLY in option 67 value. Fixed header boot file is all zeroed. It seems to me this is the part the snponly.efi firmware does not understand. It does not try to use path in option, but may insist only on file. Since option #52 overload is not in packet, I guess dnsmasq should have used mess->file for path and not option 67. But rules of rfc2131.c:2476 are simple. If client have requested option 67, it should handle it as option 67. I guess it is bug in snponly.efi. Either it should not include option 67 between requested options or it should actually handle the option. Dnsmasq would offer boot path in both cases. Interesting enough, dnsmasq is inconsistent with itself. It behaves a bit different way in PXE proxy mode, where file header part is always used. In normal mode unless --dhcp-no-override is used, option is used if requested. Can you please try if dhcp-no-override option would fix your issues? I think it should behave the same way in both situations. I attached patch, which would set boot file on pxe-service the same way as dhcp-boot. It may require dhcp-no-override where it did not before. Could you please try it? On 9/28/21 11:54, Shrenik Bhura wrote: > Hi Petr, > > As per your guidance, we have enabled logging (LOG_ALL in > config/consolle.h) and recompiled the ipxe binaries. Below are the > latest observations. > > Taking down the scenarios from the previous post for ease of reference - > 1. Default dnsmasq config with default ltsp's pxe-service entries - > https://drive.google.com/file/d/1-BGnZw4RMAuIbJudVA2D4a1vasNeAd1j/view?usp=sharing > 2. Custom pxe-service entries (just to prove that pxe-service and > dhcp-boot do seem to successfully co-exist) - > https://drive.google.com/file/d/1-CjHXxlKmYw-9aOTD7xK8m5uAdj4qyAB/view?usp=sharing > 3. Without pxe-service entries - > https://drive.google.com/file/d/1-6Q_1Fg6zVVNruzQTJjxvmKRRkRnCBmh/view?usp=sharing > > > I'll try to summarise the understanding and prevailing ambiguities > thus far to help allot responsibility of multiple things that may be > going wrong here : > > Between scenario (1) and (2), we see that ltsp.ipxe is being served in > (2) which doesn't happen in (1). > In (1), the primary issue is that EFI clients do not receive > snponly.efi, thus they do not advertise option 175 and hence are not > sent the ltsp.ipxe. Since it has not got to the iPXE stage as yet, > there are no logs available from ipxe. All that is visible > momentarily on the client side is these two lines - > *Station IP address is 192.168.67.134 > * > *PXE-E21: Remote boot cancelled.* > Quoting from an explanation herein [1] for "Remote boot cancelled" - > /" This message is also displayed when a DHCP/proxyDHCP server sends a > menu that auto-selects *Local Boot* and when a bootserver sends a > bootstrap program that returns control to the PXE LoadFile protocol. "/* > * > * > * > In scenario (2), PXE boot menu is displayed as defined in the > pxe-service lines, option 175 is received back from the client, > ltsp.ipxe is sent but is not "downloaded" by the client. There is > nothing reported in the ipxe logs. On the client, the last line says - > No more network devices.* > * > * > * > But, above all, if we simply comment out all the pxe-service lines, as > in scenario (3), including the one with tag:rpi, the EFI clients boot > up perfectly. iPXE log has - > ipxe: Downloaded "ltsp.ipxe" > ipxe: Executing "ltsp.ipxe" > ipxe: Downloaded "vmlinuz" > ipxe: Downloaded "ltsp.img" > ipxe: Downloaded "initrd.img" > ipxe: Executing "vmlinuz" > > The question thus arises that why does dnsmasq not ignore the > pxe-service lines which have an unmatched "tag:proxy" or "tag:rpi" > when dnsmasq is operating in non-proxy mode? Or does it ignore and yet
Re: [Dnsmasq-discuss] pxe-service entries in dnsmasq conf seem to fail non-proxy EFI boot
Hi Petr, As per your guidance, we have enabled logging (LOG_ALL in config/consolle.h) and recompiled the ipxe binaries. Below are the latest observations. Taking down the scenarios from the previous post for ease of reference - 1. Default dnsmasq config with default ltsp's pxe-service entries - https://drive.google.com/file/d/1-BGnZw4RMAuIbJudVA2D4a1vasNeAd1j/view?usp=sharing 2. Custom pxe-service entries (just to prove that pxe-service and dhcp-boot do seem to successfully co-exist) - https://drive.google.com/file/d/1-CjHXxlKmYw-9aOTD7xK8m5uAdj4qyAB/view?usp=sharing 3. Without pxe-service entries - https://drive.google.com/file/d/1-6Q_1Fg6zVVNruzQTJjxvmKRRkRnCBmh/view?usp=sharing I'll try to summarise the understanding and prevailing ambiguities thus far to help allot responsibility of multiple things that may be going wrong here : Between scenario (1) and (2), we see that ltsp.ipxe is being served in (2) which doesn't happen in (1). In (1), the primary issue is that EFI clients do not receive snponly.efi, thus they do not advertise option 175 and hence are not sent the ltsp.ipxe. Since it has not got to the iPXE stage as yet, there are no logs available from ipxe. All that is visible momentarily on the client side is these two lines - *Station IP address is 192.168.67.134* *PXE-E21: Remote boot cancelled.* Quoting from an explanation herein [1] for "Remote boot cancelled" - *" This message is also displayed when a DHCP/proxyDHCP server sends a menu that auto-selects Local Boot and when a bootserver sends a bootstrap program that returns control to the PXE LoadFile protocol. "* In scenario (2), PXE boot menu is displayed as defined in the pxe-service lines, option 175 is received back from the client, ltsp.ipxe is sent but is not "downloaded" by the client. There is nothing reported in the ipxe logs. On the client, the last line says - No more network devices. But, above all, if we simply comment out all the pxe-service lines, as in scenario (3), including the one with tag:rpi, the EFI clients boot up perfectly. iPXE log has - ipxe: Downloaded "ltsp.ipxe" ipxe: Executing "ltsp.ipxe" ipxe: Downloaded "vmlinuz" ipxe: Downloaded "ltsp.img" ipxe: Downloaded "initrd.img" ipxe: Executing "vmlinuz" The question thus arises that why does dnsmasq not ignore the pxe-service lines which have an unmatched "tag:proxy" or "tag:rpi" when dnsmasq is operating in non-proxy mode? Or does it ignore and yet there is a problem outside dnsmasq? With respect to scenario (1), there could be a problem in the UEFI implementation, with respect to (2), there could be an issue with iPXE but what we can immediately control within dnsmasq is to ignore lines of pxe-service with tags that have not been set. Your thoughts? [1] https://techpubs.jurassic.nl/manuals/hdwr/enduser/SG750_UG/sgi_html/ch04.html On Mon, 27 Sept 2021 at 22:56, Petr Menšík wrote: > Hello, > > I made a mistake when reading the code. You are right. The part I > mentioned is only affected on vendor-class information option 43, only in > DHCPREQUEST or DHCPINFORM. Which is not in request in pcap you have sent. > > It seems to me problem is somewhere on IPXE side in decoding reply dnsmasq > sent to it. I took a look at the second offer of both without-pxe and > default-ltsp. It seems the only difference is in vendorclass information > containing PXE menu. Without pxe continues to TFTP, where default is stuck. > The answer is on its decoding side. Assignment got the same boot file > successfully in both configurations. I am afraid it would be problem at PXE > decoding client, which may not understand menu dnsmasq tried to send. > > According to option 43 decoding in wireshark, pxe suboptions look well. > Except suboption 9 boot menu. Type unknown 0x8000 does seem weird, but > should be just Vendor use according to IBM docs [1]. Why it did not do > anything else should be answered by ipxe people. It should continue after 2 > seconds even without any action. Did it display at least boot menu on that > station? Did it show anything? Are those machines with normal VGA output? > Perhaps LOG_LEVEL in PXE [2] might reveal true reason. > > Cheers, > Petr > > 1. > https://www.ibm.com/docs/en/aix/7.2?topic=daemon-pxe-vendor-container-suboptions > 2. https://ipxe.org/buildcfg/log_level > On 9/27/21 16:04, Shrenik Bhura wrote: > > Hello Petr, > > Thanks for your guidance. > > It does seem that dhcp-boot is being reached even when pxe-service is > successfully executed. Taking a hint from this discussion on UEFI and PXE ( > https://bbs.archlinux.org/viewtopic.php?id=237655), we tried this custom > configuration - > > pxe-prompt="Press any key for boot menu",2 > pxe-service=X86-64_EFI,"PXELINUX (X86-64_EFI)",ltsp/snponly.efi > pxe-service=7,"PXELINUX (EFI)",ltsp/snponly.efi > dhcp-boot=tag:!iPXE,tag:X86PC,ltsp/undionly.kpxe > dhcp-boot=tag:!iPXE,tag:X86-64_EFI,ltsp/snponly.efi > dhcp-boot=tag:iPXE,ltsp/ltsp.ipxe > > (full file attached below) > > Server does proceed to
Re: [Dnsmasq-discuss] pxe-service entries in dnsmasq conf seem to fail non-proxy EFI boot
Hello, I made a mistake when reading the code. You are right. The part I mentioned is only affected on vendor-class information option 43, only in DHCPREQUEST or DHCPINFORM. Which is not in request in pcap you have sent. It seems to me problem is somewhere on IPXE side in decoding reply dnsmasq sent to it. I took a look at the second offer of both without-pxe and default-ltsp. It seems the only difference is in vendorclass information containing PXE menu. Without pxe continues to TFTP, where default is stuck. The answer is on its decoding side. Assignment got the same boot file successfully in both configurations. I am afraid it would be problem at PXE decoding client, which may not understand menu dnsmasq tried to send. According to option 43 decoding in wireshark, pxe suboptions look well. Except suboption 9 boot menu. Type unknown 0x8000 does seem weird, but should be just Vendor use according to IBM docs [1]. Why it did not do anything else should be answered by ipxe people. It should continue after 2 seconds even without any action. Did it display at least boot menu on that station? Did it show anything? Are those machines with normal VGA output? Perhaps LOG_LEVEL in PXE [2] might reveal true reason. Cheers, Petr 1. https://www.ibm.com/docs/en/aix/7.2?topic=daemon-pxe-vendor-container-suboptions 2. https://ipxe.org/buildcfg/log_level On 9/27/21 16:04, Shrenik Bhura wrote: > Hello Petr, > > Thanks for your guidance. > > It does seem that dhcp-boot is being reached even when pxe-service is > successfully executed. Taking a hint from this discussion on UEFI and > PXE (https://bbs.archlinux.org/viewtopic.php?id=237655), we tried this > custom configuration - > > pxe-prompt="Press any key for boot menu",2 > pxe-service=X86-64_EFI,"PXELINUX (X86-64_EFI)",ltsp/snponly.efi > pxe-service=7,"PXELINUX (EFI)",ltsp/snponly.efi > dhcp-boot=tag:!iPXE,tag:X86PC,ltsp/undionly.kpxe > dhcp-boot=tag:!iPXE,tag:X86-64_EFI,ltsp/snponly.efi > dhcp-boot=tag:iPXE,ltsp/ltsp.ipxe > > (full file attached below) > > Server does proceed to offering ltsp.ipxe to the client via dhcp but > is eventually not being transferred via tftp. > > Have attached logs, pcap and dnsmasq configuration of three scenarios - > 1. Default dnsmasq config with default ltsp's pxe-service entries > 2. Custom pxe-service entries > 3. Without pxe-service entries > > We have tested these with two systems - Intel NUC and Dell Optiplex > 3040 with their updated firmware and have found the same results. > > I hope this helps to zoom further into the problem area. > > Best regards, > Shrenik > > > > > On Mon, 27 Sept 2021 at 17:00, Petr Menšík wrote: > > Hi Alkis, > > It would be helpful, if you could record pcap with those lines > commented > out and enabled. It seems suspicious dhcp-boot option is present > at the > same time with pxe-service. From what I undestood, pxe-service should > offer boot options only to PXEClient vendor string. I think it > saves you > the need to dhcp-match=set:X86PC,option:client-arch,0 > > then matched in > dhcp-boot=tag:!iPXE,tag:X86PC,ltsp/undionly.kpxe > dhcp-boot=tag:iPXE,tag:X86PC,ltsp/ltsp.ipxe > > I just checked my Raspberry 3. I guess architecture of RPi in DHCP > request is clearly wrong. Unfortunately it reports it wrong also in > vendorclass ARCH:. > > Anyway, it might not handle tags correctly. Around > src/rfc2131.c:891, it > searches for pxe service without using tags. It is not used to find > correct service, just to find correct context. > > Also it seems if any pxe-service is defined and incoming DHCP packet > contains PXEClient in VendorClass option, it MUST be handled by > pxe-service. If no correct service & context is found, reply is not > handled for it. It cannot fall back to normal DHCP reply in that case, > which can be fixed. But current situation seems to me clear. If any > pxe-service is present, all PXEClient packets has to be handled by it. > It seems to me you define tags per arch anyway, so I guess you can > avoid > pxe-service just fine. > > I made an attempt to respond to PXE request only when correct service > matches. But I have no setup prepared for it, I tested just it > compiles. > Could you try it would help? > > Cheers, > Petr > > On 3/19/21 10:05, Alkis Georgopoulos wrote: > > Hi all, > > > > I'm one of the LTSP developers; I asked Shrenik to contact the > dnsmasq > > mailing list because I feel this might be a dnsmasq issue. > > > > Specifically, success or failure depends on whether these five lines > > are commented out or not: > > > > > #pxe-service=tag:proxy,tag:!iPXE,X86PC,"undionly.kpxe",ltsp/undionly.kpxe > > > #pxe-service=tag:proxy,tag:!iPXE,X86-64_EFI,"snponly.efi",ltsp/snponly.efi > > > > #pxe-service=tag:proxy,tag:iPXE,X86PC,"ltsp.ipxe",ltsp/ltsp.ipxe > > >
Re: [Dnsmasq-discuss] pxe-service entries in dnsmasq conf seem to fail non-proxy EFI boot
My bad. Just realised that my previous post with logs and pcap dumps has been held for moderator approval. Herein is the post again with links to the files - It does seem that dhcp-boot is being reached even when pxe-service is successfully executed. Taking a hint from this discussion on UEFI and PXE ( https://bbs.archlinux.org/viewtopic.php?id=237655), we tried this custom configuration - pxe-prompt="Press any key for boot menu",2 pxe-service=X86-64_EFI,"PXELINUX (X86-64_EFI)",ltsp/snponly.efi pxe-service=7,"PXELINUX (EFI)",ltsp/snponly.efi dhcp-boot=tag:!iPXE,tag:X86PC,ltsp/undionly.kpxe dhcp-boot=tag:!iPXE,tag:X86-64_EFI,ltsp/snponly.efi dhcp-boot=tag:iPXE,ltsp/ltsp.ipxe (full file included in the link below) Server does proceed to offering ltsp.ipxe to the client via dhcp but is eventually not being transferred via tftp. Have attached logs, pcap and dnsmasq configuration of three scenarios - 1. Default dnsmasq config with default ltsp's pxe-service entries - https://drive.google.com/file/d/1-BGnZw4RMAuIbJudVA2D4a1vasNeAd1j/view?usp=sharing 2. Custom pxe-service entries - https://drive.google.com/file/d/1-CjHXxlKmYw-9aOTD7xK8m5uAdj4qyAB/view?usp=sharing 3. Without pxe-service entries - https://drive.google.com/file/d/1-6Q_1Fg6zVVNruzQTJjxvmKRRkRnCBmh/view?usp=sharing We have tested these with two systems - Intel NUC and Dell Optiplex 3040 with their updated firmware and have found the same results. I hope this helps to zoom further into the problem area. Best regards, Shrenik On Mon, 27 Sept 2021 at 20:56, Shrenik Bhura wrote: > > Hi Petr, > > The proposed config (also given below) doesn't work in non-proxy mode. I > tested it with a RPi 4B and Intel NUC in non-proxy mode. > > > > > *pxe-service=tag:!iPXE,X86PC,ltsp/undionly.kpxe > pxe-service=tag:!iPXE,X86-64_EFI,ltsp/snponly.efi > pxe-service=tag:iPXE,X86PC,ltsp/ltsp.ipxe > pxe-service=tag:iPXE,X86-64_EFI,ltsp/ltsp.ipxe* > *# fallback for BIOS-only clients without PXE support* > * dhcp-boot=tag:!iPXE,ltsp/undionly.kpxe* > > On NUC*, *we get this after fetching IP - > PXE-E77: Bad or missing discovery server list > > On RPi it endlessly loops at - > [43:9]: 'ltsp/undionly.kpxe ' > > However, your proposed config works fine in proxy mode with just one > addition for RPi - > pxe-service=tag:rpi,X86PC,unused > > But this is already known and that's why tag:proxy was introduced to bring > into play pxe-service only when using in proxy mode. > > I have this more precise finding and at the risk of repeating myself - > With the below configuration in non-proxy mode, RPi and Intel NUC boot > BIOS boot fine but Intel NUC in UEFI mode doesn't. > pxe-service=tag:rpi,X86PC,"Raspberry Pi Boot",unused > dhcp-boot=tag:!iPXE,tag:X86PC,ltsp/undionly.kpxe > dhcp-boot=tag:!iPXE,tag:X86-64_EFI,ltsp/snponly.efi > dhcp-boot=tag:iPXE,ltsp/ltsp.ipxe > > However, if I just comment out the pxe-service line, all works fine for > Intel NUC in BIOS and UEFI mode but now RPi won't boot. This is exactly > what I had started this thread with. Hence I shared the pcap dump and logs > in the previous post. > > Best regards, > Shrenik > > > On Mon, 27 Sept 2021 at 19:40, Petr Menšík wrote: > >> I think this should have been: >> >> pxe-service=tag:!iPXE,X86PC,ltsp/undionly.kpxe >> pxe-service=tag:!iPXE,X86-64_EFI,ltsp/snponly.efi >> pxe-service=tag:iPXE,X86PC,ltsp/ltsp.ipxe >> pxe-service=tag:iPXE,X86-64_EFI,ltsp/ltsp.ipxe >> # fallback for BIOS-only clients without PXE support >> dhcp-boot=tag:!iPXE,ltsp/undionly.kpxe >> >> Does LTSP still support booting outside PXE standard? Does it need to be >> supported? I think only non-PXE capable clients should fall back to to >> dhcp-boot parameters. All others should have some pxe-service entry. >> Current code does not allow different configuration I think. Even without >> iPXE, PXEClient will get boot parameter ONLY from pxe-service. It would get >> dhcp-boot parameter only if there is no pxe-service used at all. >> >> It seems pxe-service is IPv4 only at the moment. Any device trying to >> boot over IPv6 would probably boot only using: >> >> dhcp-option=option6:bootfile-url,ltsp/ltsp.ipxe >> >> Which is a bit sad. I guess only input parameters and output options are >> somehow different. But it should offer similar paths also on IPv6. Maybe >> time would be found sometime to implement also IPv6 support. >> >> Cheers, >> Petr >> On 9/25/21 13:14, Shrenik Bhura wrote: >> >> Hi Geert, >> >> Your advice doesn't seem to work. Gives an error on the very first line >> that has been changed. >> tag:!iPXE,X86PC,ltsp/undionly.kpxe >> >> Thanks, >> Shrenik >> >> On Fri, 19 Mar, 2021, 15:54 Geert Stappers via Dnsmasq-discuss, < >> dnsmasq-discuss@lists.thekelleys.org.uk> wrote: >> >>> On Fri, Mar 19, 2021 at 11:05:05AM +0200, Alkis Georgopoulos wrote: >>> > Hi all, >>> >>> ;-) >>> >>> >>> > I'm one of the LTSP developers; I asked Shrenik to contact the dnsmasq >>> > mailing list because I feel this might be a dnsmasq issue. >>> >
Re: [Dnsmasq-discuss] pxe-service entries in dnsmasq conf seem to fail non-proxy EFI boot
Hi Petr, The proposed config (also given below) doesn't work in non-proxy mode. I tested it with a RPi 4B and Intel NUC in non-proxy mode. *pxe-service=tag:!iPXE,X86PC,ltsp/undionly.kpxe pxe-service=tag:!iPXE,X86-64_EFI,ltsp/snponly.efi pxe-service=tag:iPXE,X86PC,ltsp/ltsp.ipxe pxe-service=tag:iPXE,X86-64_EFI,ltsp/ltsp.ipxe* *# fallback for BIOS-only clients without PXE support* * dhcp-boot=tag:!iPXE,ltsp/undionly.kpxe* On NUC*, *we get this after fetching IP - PXE-E77: Bad or missing discovery server list On RPi it endlessly loops at - [43:9]: 'ltsp/undionly.kpxe ' However, your proposed config works fine in proxy mode with just one addition for RPi - pxe-service=tag:rpi,X86PC,unused But this is already known and that's why tag:proxy was introduced to bring into play pxe-service only when using in proxy mode. I have this more precise finding and at the risk of repeating myself - With the below configuration in non-proxy mode, RPi and Intel NUC boot BIOS boot fine but Intel NUC in UEFI mode doesn't. pxe-service=tag:rpi,X86PC,"Raspberry Pi Boot",unused dhcp-boot=tag:!iPXE,tag:X86PC,ltsp/undionly.kpxe dhcp-boot=tag:!iPXE,tag:X86-64_EFI,ltsp/snponly.efi dhcp-boot=tag:iPXE,ltsp/ltsp.ipxe However, if I just comment out the pxe-service line, all works fine for Intel NUC in BIOS and UEFI mode but now RPi won't boot. This is exactly what I had started this thread with. Hence I shared the pcap dump and logs in the previous post. Best regards, Shrenik On Mon, 27 Sept 2021 at 19:40, Petr Menšík wrote: > I think this should have been: > > pxe-service=tag:!iPXE,X86PC,ltsp/undionly.kpxe > pxe-service=tag:!iPXE,X86-64_EFI,ltsp/snponly.efi > pxe-service=tag:iPXE,X86PC,ltsp/ltsp.ipxe > pxe-service=tag:iPXE,X86-64_EFI,ltsp/ltsp.ipxe > # fallback for BIOS-only clients without PXE support > dhcp-boot=tag:!iPXE,ltsp/undionly.kpxe > > Does LTSP still support booting outside PXE standard? Does it need to be > supported? I think only non-PXE capable clients should fall back to to > dhcp-boot parameters. All others should have some pxe-service entry. > Current code does not allow different configuration I think. Even without > iPXE, PXEClient will get boot parameter ONLY from pxe-service. It would get > dhcp-boot parameter only if there is no pxe-service used at all. > > It seems pxe-service is IPv4 only at the moment. Any device trying to boot > over IPv6 would probably boot only using: > > dhcp-option=option6:bootfile-url,ltsp/ltsp.ipxe > > Which is a bit sad. I guess only input parameters and output options are > somehow different. But it should offer similar paths also on IPv6. Maybe > time would be found sometime to implement also IPv6 support. > > Cheers, > Petr > On 9/25/21 13:14, Shrenik Bhura wrote: > > Hi Geert, > > Your advice doesn't seem to work. Gives an error on the very first line > that has been changed. > tag:!iPXE,X86PC,ltsp/undionly.kpxe > > Thanks, > Shrenik > > On Fri, 19 Mar, 2021, 15:54 Geert Stappers via Dnsmasq-discuss, < > dnsmasq-discuss@lists.thekelleys.org.uk> wrote: > >> On Fri, Mar 19, 2021 at 11:05:05AM +0200, Alkis Georgopoulos wrote: >> > Hi all, >> >> ;-) >> >> >> > I'm one of the LTSP developers; I asked Shrenik to contact the dnsmasq >> > mailing list because I feel this might be a dnsmasq issue. >> > >> > Specifically, success or failure depends on whether these five lines are >> > commented out or not: >> > >> > >> #pxe-service=tag:proxy,tag:!iPXE,X86PC,"undionly.kpxe",ltsp/undionly.kpxe >> > >> #pxe-service=tag:proxy,tag:!iPXE,X86-64_EFI,"snponly.efi",ltsp/snponly.efi >> > #pxe-service=tag:proxy,tag:iPXE,X86PC,"ltsp.ipxe",ltsp/ltsp.ipxe >> > #pxe-service=tag:proxy,tag:iPXE,X86-64_EFI,"ltsp.ipxe",ltsp/ltsp.ipxe >> > #pxe-service=tag:rpi,X86PC,"Raspberry Pi Boot ",unused >> > >> > You may find the full configuration files and logs at: >> > https://github.com/ltsp/ltsp/pull/417 >> > >> > The reason I feel it might be a dnsmasq issue, is that these tags are >> NOT >> > matched in Shrenik's use case. He's not using proxy mode and he's not >> > booting a Raspberry Pi. >> > >> > So, "pxe-service" lines that are NOT matched, cause the problem, >> > yet if they're commented out, the problem is gone... >> > >> > Would that be an issue with dnsmasq, or with the UEFI PXE stack? >> >> I go for something inbetween: >> UEFI PXE stack insisting on something that dnsmasq **configuration** >> doesn't yet provide. Or server side **configuration** is something >> that the client can't handle. >> >> >> Advice: >> Leave out `pxe-service`, skip "PXE". Yes, do iPXE;-) [1] >> >> Transform >> | >> #pxe-service=tag:proxy,tag:!iPXE,X86PC,"undionly.kpxe",ltsp/undionly.kpxe >> | >> #pxe-service=tag:proxy,tag:!iPXE,X86-64_EFI,"snponly.efi",ltsp/snponly.efi >> | #pxe-service=tag:proxy,tag:iPXE,X86PC,"ltsp.ipxe",ltsp/ltsp.ipxe >> | #pxe-service=tag:proxy,tag:iPXE,X86-64_EFI,"ltsp.ipxe",ltsp/ltsp.ipxe >> | #pxe-service=tag:rpi,X86PC,"Raspberry Pi Boot ",unused >> into something
Re: [Dnsmasq-discuss] pxe-service entries in dnsmasq conf seem to fail non-proxy EFI boot
I think this should have been: pxe-service=tag:!iPXE,X86PC,ltsp/undionly.kpxe pxe-service=tag:!iPXE,X86-64_EFI,ltsp/snponly.efi pxe-service=tag:iPXE,X86PC,ltsp/ltsp.ipxe pxe-service=tag:iPXE,X86-64_EFI,ltsp/ltsp.ipxe # fallback for BIOS-only clients without PXE support dhcp-boot=tag:!iPXE,ltsp/undionly.kpxe Does LTSP still support booting outside PXE standard? Does it need to be supported? I think only non-PXE capable clients should fall back to to dhcp-boot parameters. All others should have some pxe-service entry. Current code does not allow different configuration I think. Even without iPXE, PXEClient will get boot parameter ONLY from pxe-service. It would get dhcp-boot parameter only if there is no pxe-service used at all. It seems pxe-service is IPv4 only at the moment. Any device trying to boot over IPv6 would probably boot only using: dhcp-option=option6:bootfile-url,ltsp/ltsp.ipxe Which is a bit sad. I guess only input parameters and output options are somehow different. But it should offer similar paths also on IPv6. Maybe time would be found sometime to implement also IPv6 support. Cheers, Petr On 9/25/21 13:14, Shrenik Bhura wrote: > Hi Geert, > > Your advice doesn't seem to work. Gives an error on the very first > line that has been changed. > tag:!iPXE,X86PC,ltsp/undionly.kpxe > > Thanks, > Shrenik > > On Fri, 19 Mar, 2021, 15:54 Geert Stappers via Dnsmasq-discuss, > wrote: > > On Fri, Mar 19, 2021 at 11:05:05AM +0200, Alkis Georgopoulos wrote: > > Hi all, > > ;-) > > > > I'm one of the LTSP developers; I asked Shrenik to contact the > dnsmasq > > mailing list because I feel this might be a dnsmasq issue. > > > > Specifically, success or failure depends on whether these five > lines are > > commented out or not: > > > > > #pxe-service=tag:proxy,tag:!iPXE,X86PC,"undionly.kpxe",ltsp/undionly.kpxe > > > #pxe-service=tag:proxy,tag:!iPXE,X86-64_EFI,"snponly.efi",ltsp/snponly.efi > > #pxe-service=tag:proxy,tag:iPXE,X86PC,"ltsp.ipxe",ltsp/ltsp.ipxe > > > #pxe-service=tag:proxy,tag:iPXE,X86-64_EFI,"ltsp.ipxe",ltsp/ltsp.ipxe > > #pxe-service=tag:rpi,X86PC,"Raspberry Pi Boot ",unused > > > > You may find the full configuration files and logs at: > > https://github.com/ltsp/ltsp/pull/417 > > > > The reason I feel it might be a dnsmasq issue, is that these > tags are NOT > > matched in Shrenik's use case. He's not using proxy mode and > he's not > > booting a Raspberry Pi. > > > > So, "pxe-service" lines that are NOT matched, cause the problem, > > yet if they're commented out, the problem is gone... > > > > Would that be an issue with dnsmasq, or with the UEFI PXE stack? > > I go for something inbetween: > UEFI PXE stack insisting on something that dnsmasq **configuration** > doesn't yet provide. Or server side **configuration** is something > that the client can't handle. > > > Advice: > Leave out `pxe-service`, skip "PXE". Yes, do iPXE ;-) [1] > > Transform > | > #pxe-service=tag:proxy,tag:!iPXE,X86PC,"undionly.kpxe",ltsp/undionly.kpxe > | > #pxe-service=tag:proxy,tag:!iPXE,X86-64_EFI,"snponly.efi",ltsp/snponly.efi > | #pxe-service=tag:proxy,tag:iPXE,X86PC,"ltsp.ipxe",ltsp/ltsp.ipxe > | > #pxe-service=tag:proxy,tag:iPXE,X86-64_EFI,"ltsp.ipxe",ltsp/ltsp.ipxe > | #pxe-service=tag:rpi,X86PC,"Raspberry Pi Boot ",unused > into something like[2]: > | tag:!iPXE,X86PC,ltsp/undionly.kpxe > | tag:!iPXE,X86-64_EFI,ltsp/snponly.efi > | tag:iPXE,X86PC,ltsp/ltsp.ipxe > | tag:iPXE,X86-64_EFI,ltsp/ltsp.ipxe > | tag:rpi,X86PC,unused > > > Request: > Report back > > > > Groeten > Geert Stappers > Voetnoten: > [1] iPXE stands for "It doesn't do PXE" > [2] actual syntax not verified > -- > Silence is hard to parse > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss > > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] pxe-service entries in dnsmasq conf seem to fail non-proxy EFI boot
Hi Alkis,
It would be helpful, if you could record pcap with those lines commented
out and enabled. It seems suspicious dhcp-boot option is present at the
same time with pxe-service. From what I undestood, pxe-service should
offer boot options only to PXEClient vendor string. I think it saves you
the need to dhcp-match=set:X86PC,option:client-arch,0
then matched in
dhcp-boot=tag:!iPXE,tag:X86PC,ltsp/undionly.kpxe
dhcp-boot=tag:iPXE,tag:X86PC,ltsp/ltsp.ipxe
I just checked my Raspberry 3. I guess architecture of RPi in DHCP
request is clearly wrong. Unfortunately it reports it wrong also in
vendorclass ARCH:.
Anyway, it might not handle tags correctly. Around src/rfc2131.c:891, it
searches for pxe service without using tags. It is not used to find
correct service, just to find correct context.
Also it seems if any pxe-service is defined and incoming DHCP packet
contains PXEClient in VendorClass option, it MUST be handled by
pxe-service. If no correct service & context is found, reply is not
handled for it. It cannot fall back to normal DHCP reply in that case,
which can be fixed. But current situation seems to me clear. If any
pxe-service is present, all PXEClient packets has to be handled by it.
It seems to me you define tags per arch anyway, so I guess you can avoid
pxe-service just fine.
I made an attempt to respond to PXE request only when correct service
matches. But I have no setup prepared for it, I tested just it compiles.
Could you try it would help?
Cheers,
Petr
On 3/19/21 10:05, Alkis Georgopoulos wrote:
> Hi all,
>
> I'm one of the LTSP developers; I asked Shrenik to contact the dnsmasq
> mailing list because I feel this might be a dnsmasq issue.
>
> Specifically, success or failure depends on whether these five lines
> are commented out or not:
>
> #pxe-service=tag:proxy,tag:!iPXE,X86PC,"undionly.kpxe",ltsp/undionly.kpxe
> #pxe-service=tag:proxy,tag:!iPXE,X86-64_EFI,"snponly.efi",ltsp/snponly.efi
>
> #pxe-service=tag:proxy,tag:iPXE,X86PC,"ltsp.ipxe",ltsp/ltsp.ipxe
> #pxe-service=tag:proxy,tag:iPXE,X86-64_EFI,"ltsp.ipxe",ltsp/ltsp.ipxe
> #pxe-service=tag:rpi,X86PC,"Raspberry Pi Boot ",unused
>
> You may find the full configuration files and logs at:
> https://github.com/ltsp/ltsp/pull/417
>
> The reason I feel it might be a dnsmasq issue, is that these tags are
> NOT matched in Shrenik's use case. He's not using proxy mode and he's
> not booting a Raspberry Pi.
>
> So, "pxe-service" lines that are NOT matched, cause the problem,
> yet if they're commented out, the problem is gone...
>
> Would that be an issue with dnsmasq, or with the UEFI PXE stack?
>
> Thanks,
> Alkis Georgopoulos
>
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
>
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
From fd0be885056b29c7e005e29862ce38300a8590da Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20Men=C5=A1=C3=ADk?=
Date: Mon, 27 Sep 2021 12:39:24 +0200
Subject: [PATCH] Allow fallback to normal DHCP for PXE enabled clients
PXE clients may not have defined matching pxe-service for their tags
combination. Allow such clients to fall back to non-PXE DHCP responses.
Move pxe response to separate function called only when records for both
context and service matches.
---
src/rfc2131.c | 121 +-
1 file changed, 70 insertions(+), 51 deletions(-)
diff --git a/src/rfc2131.c b/src/rfc2131.c
index c902eb7..3122dcc 100644
--- a/src/rfc2131.c
+++ b/src/rfc2131.c
@@ -68,6 +68,68 @@ static int pxe_uefi_workaround(int pxe_arch, struct dhcp_netid *netid, struct dh
static void apply_delay(u32 xid, time_t recvtime, struct dhcp_netid *netid);
static int is_pxe_client(struct dhcp_packet *mess, size_t sz, const char **pxe_vendor);
+static int pxe_reply(struct dhcp_context *context, char *iface_name,
+ size_t sz, struct pxe_service *service,
+ struct dhcp_packet *mess, unsigned char *end, unsigned char *real_end,
+ time_t now, unsigned char *opt, const char *pxevendor,
+ struct dhcp_netid *tagif_netid, unsigned char *agent_id,
+ unsigned char *emac, int emac_len)
+{
+ unsigned char save71[4];
+ unsigned char pxe_uuid[17];
+ struct dhcp_opt opt71;
+ unsigned char *uuid = NULL;
+ int layer = option_uint(opt, 2, 2);
+
+ if (layer & 0x8000)
+{
+ my_syslog(MS_DHCP | LOG_ERR, _("PXE BIS not supported"));
+ return 0;
+}
+
+ if ((opt = option_find(mess, sz, OPTION_PXE_UUID, 17)))
+{
+ memcpy(pxe_uuid, option_ptr(opt, 0), 17);
+ uuid = pxe_uuid;
+}
+
+ memcpy(save71, option_ptr(opt, 0), 4);
+ clear_packet(mess, end);
+
+ mess->yiaddr = mess->ciaddr;
+ mess->ciaddr.s_addr = 0;
+ if (service->sname)
+mess->siaddr = a_record_from_hosts(service->sname, now);
+ else if
Re: [Dnsmasq-discuss] pxe-service entries in dnsmasq conf seem to fail non-proxy EFI boot
Hi Geert, Your advice doesn't seem to work. Gives an error on the very first line that has been changed. tag:!iPXE,X86PC,ltsp/undionly.kpxe Thanks, Shrenik On Fri, 19 Mar, 2021, 15:54 Geert Stappers via Dnsmasq-discuss, < dnsmasq-discuss@lists.thekelleys.org.uk> wrote: > On Fri, Mar 19, 2021 at 11:05:05AM +0200, Alkis Georgopoulos wrote: > > Hi all, > > ;-) > > > > I'm one of the LTSP developers; I asked Shrenik to contact the dnsmasq > > mailing list because I feel this might be a dnsmasq issue. > > > > Specifically, success or failure depends on whether these five lines are > > commented out or not: > > > > #pxe-service=tag:proxy,tag:!iPXE,X86PC,"undionly.kpxe",ltsp/undionly.kpxe > > > #pxe-service=tag:proxy,tag:!iPXE,X86-64_EFI,"snponly.efi",ltsp/snponly.efi > > #pxe-service=tag:proxy,tag:iPXE,X86PC,"ltsp.ipxe",ltsp/ltsp.ipxe > > #pxe-service=tag:proxy,tag:iPXE,X86-64_EFI,"ltsp.ipxe",ltsp/ltsp.ipxe > > #pxe-service=tag:rpi,X86PC,"Raspberry Pi Boot ",unused > > > > You may find the full configuration files and logs at: > > https://github.com/ltsp/ltsp/pull/417 > > > > The reason I feel it might be a dnsmasq issue, is that these tags are NOT > > matched in Shrenik's use case. He's not using proxy mode and he's not > > booting a Raspberry Pi. > > > > So, "pxe-service" lines that are NOT matched, cause the problem, > > yet if they're commented out, the problem is gone... > > > > Would that be an issue with dnsmasq, or with the UEFI PXE stack? > > I go for something inbetween: > UEFI PXE stack insisting on something that dnsmasq **configuration** > doesn't yet provide. Or server side **configuration** is something > that the client can't handle. > > > Advice: > Leave out `pxe-service`, skip "PXE". Yes, do iPXE;-) [1] > > Transform > | #pxe-service=tag:proxy,tag:!iPXE,X86PC,"undionly.kpxe",ltsp/undionly.kpxe > | > #pxe-service=tag:proxy,tag:!iPXE,X86-64_EFI,"snponly.efi",ltsp/snponly.efi > | #pxe-service=tag:proxy,tag:iPXE,X86PC,"ltsp.ipxe",ltsp/ltsp.ipxe > | #pxe-service=tag:proxy,tag:iPXE,X86-64_EFI,"ltsp.ipxe",ltsp/ltsp.ipxe > | #pxe-service=tag:rpi,X86PC,"Raspberry Pi Boot ",unused > into something like[2]: > | tag:!iPXE,X86PC,ltsp/undionly.kpxe > | tag:!iPXE,X86-64_EFI,ltsp/snponly.efi > | tag:iPXE,X86PC,ltsp/ltsp.ipxe > | tag:iPXE,X86-64_EFI,ltsp/ltsp.ipxe > | tag:rpi,X86PC,unused > > > Request: > Report back > > > > Groeten > Geert Stappers > Voetnoten: > [1] iPXE stands for "It doesn't do PXE" > [2] actual syntax not verified > -- > Silence is hard to parse > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss > ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] pxe-service entries in dnsmasq conf seem to fail non-proxy EFI boot
On Fri, Mar 19, 2021 at 11:05:05AM +0200, Alkis Georgopoulos wrote: > Hi all, ;-) > I'm one of the LTSP developers; I asked Shrenik to contact the dnsmasq > mailing list because I feel this might be a dnsmasq issue. > > Specifically, success or failure depends on whether these five lines are > commented out or not: > > #pxe-service=tag:proxy,tag:!iPXE,X86PC,"undionly.kpxe",ltsp/undionly.kpxe > #pxe-service=tag:proxy,tag:!iPXE,X86-64_EFI,"snponly.efi",ltsp/snponly.efi > #pxe-service=tag:proxy,tag:iPXE,X86PC,"ltsp.ipxe",ltsp/ltsp.ipxe > #pxe-service=tag:proxy,tag:iPXE,X86-64_EFI,"ltsp.ipxe",ltsp/ltsp.ipxe > #pxe-service=tag:rpi,X86PC,"Raspberry Pi Boot ",unused > > You may find the full configuration files and logs at: > https://github.com/ltsp/ltsp/pull/417 > > The reason I feel it might be a dnsmasq issue, is that these tags are NOT > matched in Shrenik's use case. He's not using proxy mode and he's not > booting a Raspberry Pi. > > So, "pxe-service" lines that are NOT matched, cause the problem, > yet if they're commented out, the problem is gone... > > Would that be an issue with dnsmasq, or with the UEFI PXE stack? I go for something inbetween: UEFI PXE stack insisting on something that dnsmasq **configuration** doesn't yet provide. Or server side **configuration** is something that the client can't handle. Advice: Leave out `pxe-service`, skip "PXE". Yes, do iPXE;-) [1] Transform | #pxe-service=tag:proxy,tag:!iPXE,X86PC,"undionly.kpxe",ltsp/undionly.kpxe | #pxe-service=tag:proxy,tag:!iPXE,X86-64_EFI,"snponly.efi",ltsp/snponly.efi | #pxe-service=tag:proxy,tag:iPXE,X86PC,"ltsp.ipxe",ltsp/ltsp.ipxe | #pxe-service=tag:proxy,tag:iPXE,X86-64_EFI,"ltsp.ipxe",ltsp/ltsp.ipxe | #pxe-service=tag:rpi,X86PC,"Raspberry Pi Boot ",unused into something like[2]: | tag:!iPXE,X86PC,ltsp/undionly.kpxe | tag:!iPXE,X86-64_EFI,ltsp/snponly.efi | tag:iPXE,X86PC,ltsp/ltsp.ipxe | tag:iPXE,X86-64_EFI,ltsp/ltsp.ipxe | tag:rpi,X86PC,unused Request: Report back Groeten Geert Stappers Voetnoten: [1] iPXE stands for "It doesn't do PXE" [2] actual syntax not verified -- Silence is hard to parse ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] pxe-service entries in dnsmasq conf seem to fail non-proxy EFI boot
Hello! Am trying to boot UEFI clients over iPXE via dnsmasq setup in no proxy mode. When pxe-service entries are commented out and dnsmasq restarted, the boot process proceeds fine else the client shows "PXE-E21: Remote boot cancelled" after getting the IP. Related LTSP PR - https://github.com/ltsp/ltsp/pull/417 Therein are attached the success and failure configurations as well as the corresponding logs. Do note that this scenario is specific to UEFI clients as Legacy BIOS clients boot fine even without commenting out the pxe-service entries. Have tried this with two different clients from different vendors (Intel NUC and Dell Optiplex). Thanks, Shrenik ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] pxe-service entries in dnsmasq conf seem to fail non-proxy EFI boot
Hi all, I'm one of the LTSP developers; I asked Shrenik to contact the dnsmasq mailing list because I feel this might be a dnsmasq issue. Specifically, success or failure depends on whether these five lines are commented out or not: #pxe-service=tag:proxy,tag:!iPXE,X86PC,"undionly.kpxe",ltsp/undionly.kpxe #pxe-service=tag:proxy,tag:!iPXE,X86-64_EFI,"snponly.efi",ltsp/snponly.efi #pxe-service=tag:proxy,tag:iPXE,X86PC,"ltsp.ipxe",ltsp/ltsp.ipxe #pxe-service=tag:proxy,tag:iPXE,X86-64_EFI,"ltsp.ipxe",ltsp/ltsp.ipxe #pxe-service=tag:rpi,X86PC,"Raspberry Pi Boot ",unused You may find the full configuration files and logs at: https://github.com/ltsp/ltsp/pull/417 The reason I feel it might be a dnsmasq issue, is that these tags are NOT matched in Shrenik's use case. He's not using proxy mode and he's not booting a Raspberry Pi. So, "pxe-service" lines that are NOT matched, cause the problem, yet if they're commented out, the problem is gone... Would that be an issue with dnsmasq, or with the UEFI PXE stack? Thanks, Alkis Georgopoulos ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
