[Dnsmasq-discuss] About UEFI PXE booting in proxy mode

Doug Brown doug at schmorgal.com
Thu Mar 30 05:13:31 BST 2017


Hi Steven,

If I find some free time, I might try tracing through the code to figure
out why dnsmasq is throwing out the DHCP packets on port 4011 in the EFI
+ PXE configuration without a proxy. In the meantime, here is the
configuration that works for me with dhcp-boot (assuming my dnsmasq
server's IP address is 192.168.1.1):

port=0
log-dhcp
enable-tftp
tftp-root=/tftpboot
dhcp-no-override
dhcp-vendorclass=BIOS,PXEClient:Arch:00000
dhcp-vendorclass=UEFI,PXEClient:Arch:00007
dhcp-vendorclass=UEFI64,PXEClient:Arch:00009
dhcp-boot=pxelinux.0,,192.168.1.1
dhcp-boot=net:UEFI,shim.efi,,192.168.1.1
dhcp-boot=net:UEFI64,shim.efi,,192.168.1.1
dhcp-range=ens33,192.168.1.50,192.168.1.99,10h

In this example, I'm using shim-signed (named as shim.efi) and
grubnetx64.efi.signed (named as grubx64.efi) from Ubuntu, and it should
properly boot a UEFI computer even if it has Secure Boot enabled. Shim
downloads grubx64.efi, which then downloads grub.cfg.

Hope this helps!
Doug


On 3/28/2017 11:46 PM, Steven Shiau wrote:
> Hi Doug,
>
> Thanks for your explanation. Simon also emailed me after my post and
> let me know where the problem is. The conclusion is this issue seems
> not be easily fixed.
> So the patch for grub will be applied after grub 2.02. Before that,
> could you please show me the configuration file you confirmed it will
> work by using dhcp-boot strategy?
> Thank you very much.
>
> Steven
>
>
> On 3/27/2017 AM 11:29, Doug Brown wrote:
>> Hi Simon and Steven,
>>
>> I just found this recent thread while I was Googling for the exact
>> same problem (UEFI clients won't boot in PXE mode, but BIOS clients
>> will) and there was never any conclusion reached. I'm running into
>> the exact same problem, and I can provide a pcap dump, which I have
>> attached to this message. After the initial DHCP exchange, it shows
>> four DHCP packets on port 4011 sent from the client which seem to be
>> ignored by dnsmasq. Here is the configuration I am using with dnsmasq
>> 2.76, based on Steven's original third example:
>>
>> port=0
>> log-dhcp
>> dhcp-no-override
>> enable-tftp
>> tftp-root=/tftpboot
>> dhcp-range=ens33,192.168.7.100,192.168.7.200,10h
>> pxe-service=X86PC, "Boot BIOS PXE", pxelinux.0
>> pxe-service=BC_EFI, "Boot UEFI BC", grubx64.efi
>> pxe-service=X86-64_EFI, "Boot UEFI X86-64", grubx64.efi
>>
>> If I switch to using the dhcp-boot strategy, everything works great
>> on both BIOS and UEFI. But the above configuration using PXE doesn't
>> seem to work properly with UEFI clients for some reason, and it seems
>> to be a dnsmasq issue. It does work fine with BIOS clients though.
>>
>> I think I can answer Steven's earlier question as to why proxy PXE
>> (example config #4) doesn't work with UEFI. The problem in that case
>> is not due to dnsmasq at all -- it's correctly sending grub to the
>> client. The problem is that grub doesn't know how to detect that it
>> was loaded from a DHCP proxy, so it won't know where to download
>> grub.cfg. Shim, which you can use as a first stage bootloader to load
>> grub if you need to support Secure Boot, has the exact same problem.
>> It only knows how to look at the original DHCP ack's boot info. The
>> UEFI environment provides info about the proxy offer, but grub and
>> shim don't look at it. See the following thread where a patch was
>> submitted for grub:
>>
>> https://lists.gnu.org/archive/html/grub-devel/2016-04/msg00051.html
>>
>> I think it's probably possible to work around the proxy problem by
>> using grub-mkstandalone to create a version of grub.efi that has an
>> embedded intermediate grub.cfg that is coded to download the real
>> grub.cfg from your server, as long as you don't need Secure Boot
>> support.
>>
>> Either way, I still think there's something wrong with dnsmasq's PXE
>> support because the example config above (non-proxy) doesn't work
>> with any UEFI clients that I have tested, as shown by the pcap dump
>> attached. Any ideas?
>>
>> Thanks,
>> Doug
>>
>> On 1/26/2017 11:16 AM, Simon Kelley wrote:
>>> There's no DHCP traffic in that capture. It appears to all be ssh.
>>>
>>> Wrong interface?
>>>
>>>
>>> Cheers,
>>>
>>> Simon.
>>>
>>>
>>> On 24/01/17 08:50, Steven Shiau wrote:
>>> > Hi Simon,
>>>
>>> > Attached please find the dump file of the command "tcpdump -s 0 -w
>>> > capturefile". Let me know if you need more info. Thank you very
>>> > much.
>>>
>>> > Steven
>>>
>>>
>>> > On 1/24/2017 AM 05:25, Simon Kelley wrote: Thanks for the reply.
>>> > Please could you repeat the tcpdump using the command
>>>
>>> > tcpdump -s 0 -w capturefile
>>>
>>> > and send me the resulting file? That has far more information than
>>> > tcpdump prints.
>>>
>>>
>>> > Cheers,
>>>
>>> > Simon.
>>>
>>> > On 20/01/17 08:39, Steven Shiau wrote:
>>> >>>> Hi Simon,
>>> >>>>
>>> >>>> Thanks for your reply. I am answering you in the following.
>>> >>>>
>>> >>>> On 2017/01/20 06:47, Simon Kelley wrote:
>>> >>>>> Your example 3 - I'm confused why that shouldn't work - the
>>> >>>>> PXE client seems to be making further requests which are
>>> >>>>> bring ignored. Would it be possible for you to get a packet
>>> >>>>> dump of that exchange using tcpdump?
>>> >>>> $ sudo tcpdump -ni ens38 'udp port 67 and udp port 68'
>>> >>>> tcpdump: verbose output suppressed, use -v or -vv for full
>>> >>>> protocol decode listening on ens38, link-type EN10MB
>>> >>>> (Ethernet), capture size 262144 bytes 16:18:33.208355 IP
>>> >>>> 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from
>>> >>>> 00:0c:29:1d:9a:d1, length 347 16:18:36.205647 IP
>>> >>>> 192.168.22.254.67 > 255.255.255.255.68: BOOTP/DHCP, Reply,
>>> >>>> length 341 16:18:36.385548 IP 0.0.0.0.68 >
>>> >>>> 255.255.255.255.67: BOOTP/DHCP, Request from
>>> >>>> 00:0c:29:1d:9a:d1, length 359 16:18:36.386212 IP
>>> >>>> 192.168.22.254.67 > 255.255.255.255.68: BOOTP/DHCP, Reply,
>>> >>>> length 341 ^C 4 packets captured 4 packets received by filter
>>> >>>> 0 packets dropped by kernel
>>> >>>>
>>> >>>>> Example 4 looks quite hopeful - the client is
>>> >>>>> succerssfully downloading the bootx64.efi file (ignore the
>>> >>>>> error before, that's just testing for the existance of the
>>> >>>>> file.
>>> >>>>>
>>> >>>>> Can you see what's displayed on the client system at this
>>> >>>>> point?
>>> >>>> It's blank screen due to the background_image for grub is
>>> >>>> not downloaded,  and in the end the grub shows no grub.cfg
>>> >>>> error, as attached. That format is from the grub prefix we
>>> >>>> added by: ======================================= set
>>> >>>> prefix=(tftp)/grub-efi.cfg echo "Grub CPU and platform:
>>> >>>> \$grub_cpu, \$grub_platform" echo 'Network status: '
>>> >>>> net_ls_cards net_ls_addr net_ls_routes
>>> >>>>
>>> >>>> tr --set pretty_mac x: x- \$net_default_mac
>>> >>>>
>>> >>>> echo "Loading config file
>>> >>>> \$prefix/grub.cfg-01-\$pretty_mac..." configfile
>>> >>>> \$prefix/grub.cfg-01-\$pretty_mac
>>> >>>>
>>> >>>> echo "Loading config file
>>> >>>> \$prefix/grub.cfg-\$net_default_ip..." configfile
>>> >>>> \$prefix/grub.cfg-\$net_default_ip
>>> >>>>
>>> >>>> echo "Loading config file: \$prefix/grub.cfg" configfile
>>> >>>> \$prefix/grub.cfg
>>> >>>>
>>> >>>> echo "Could not find config file
>>> >>>> \$prefix/grub.cfg-\$pretty_mac,
>>> >>>> \$prefix/grub.cfg-\$net_default_ip or \$prefix/grub.cfg!"
>>> >>>> sleep 15 ======================================= This is
>>> >>>> exactly the same problem as mentioned here:
>>> >>>>
>>> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2016q4/010
>>> 931
>>>
>>> >>>>
>>> .html
>>> >>>>
>>> > i.e., only grub efi is downloaded, while the rest of required files
>>> > are
>>> >>>> not downloaded. As I mentioned for comparison, for non-proxy
>>> >>>> mode with same configuration, it works well.
>>> >>>>
>>> >>>> Thanks again.
>>> >>>>
>>> >>>> Steven
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> Dnsmasq-discuss mailing list
>>> >>>> Dnsmasq-discuss at lists.thekelleys.org.uk
>>> >>>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>>> >>>>
>>> >>
>>> >>
>>> >>>>
>>> _______________________________________________
>>> >> Dnsmasq-discuss mailing list
>>> >> Dnsmasq-discuss at lists.thekelleys.org.uk
>>> >> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>>>
>>>
>>>
>>> > _______________________________________________ Dnsmasq-discuss
>>> > mailing list Dnsmasq-discuss at lists.thekelleys.org.uk
>>> > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>>>
>> > >
>>
>>
>>
>>
>> _______________________________________________
>> Dnsmasq-discuss mailing list
>> Dnsmasq-discuss at lists.thekelleys.org.uk
>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>





More information about the Dnsmasq-discuss mailing list