Dnsmasq bios and uefi

[george1421]

In an effort to see if I could get a proper configuration for dnsmasq to offer both bios (legacy) and uefi iPXE kernels to the booting target I came up with this after reading many (many) configuration docs.

# Don't function as a DNS server:
port=0

# Log lots of extra information about DHCP transactions.
log-dhcp

# Set the root directory for files available via FTP.
tftp-root=/tftpboot

# The boot filename, Server name, Server Ip Address
# dhcp-boot=undionly.kpxe,,192.168.112.24

# Disable re-use of the DHCP servername and filename fields as extra
# option space. That's to avoid confusing some old or broken DHCP clients.
# dhcp-no-override

dhcp-vendorclass=BIOS,PXEClient:Arch:00000
dhcp-vendorclass=UEFI32,PXEClient:Arch:00006
dhcp-vendorclass=UEFI,PXEClient:Arch:00007
dhcp-vendorclass=UEFI64,PXEClient:Arch:00009

dhcp-boot=net:UEFI32,i386-efi/ipxe.efi,,192.168.112.24
dhcp-boot=net:UEFI,ipxe.efi,,192.168.112.24
dhcp-boot=net:UEFI64,ipxe.efi,,192.168.112.24
dhcp-boot=net:BIOS,undionly.kpxe,,192.168.112.24

# PXE menu.  The first part is the text displayed to the user.  The second is the timeout, in seconds.
pxe-prompt="Press F8 for boot menu", 10

# The known types are x86PC, PC98, IA64_EFI, Alpha, Arc_x86,
# Intel_Lean_Client, IA32_EFI, BC_EFI, Xscale_EFI and X86-64_EFI
# This option is first and will be the default if there is no input from the user.
# PXEClient:Arch:00000
pxe-service=X86PC, "Boot BIOS PXE", undionly
# PXEClient:Arch:00007
pxe-service=BC_EFI, "Boot UEFI PXE-BC", ipxe.efi
# PXEClient:Arch:00009
pxe-service=X86-64_EFI, "Boot UEFI PXE-64", ipxe.efi

dhcp-range=192.168.112.24,proxy

Running wireshark with the above configuration actually sent the right dhcp options to the target computer, but alas the target computer would not boot. Looking at the packet capture I can see the target send out the dhcp discover and both my home router and the dnsmasq device (fog server) respond. But the target never sent a dhcp request, it only started the process again sending a dhcp discover again.

For clarity the FOG server and dnsmasq is running on my FOG-Pi server running raspbian jessie. Dnsmasq version is 2.72. The target computer is a Dell e6230 switched into uefi mode. In the above configuration file 192.168.112.24 is my dnsmasq/FOG-Pi server and my dhcp server is a home router running factory stock firmware.

[george1421]

Being the daring person I am,. I downloaded the source code for dnsmasq 2.76 to the Raspberry Pi. I checked and gcc was installed so I “thought” I was good to go. I compiled and installed dnsmasq 2.76. Everything went great until I tried to restart the dnsmasq service. The start command responded with an illegal command switch was used to launch the application. There was not indication to what or why just it wasn’t going to start.

After doing a bunch of digging and reverse engineering I found that a few options needed to be defined in the src/config.h file. More precisely.

#define HAVE_DBUS
#define HAVE_IDN
#define HAVE_CONNTRACK
#define HAVE_DNSSEC

As well as some required libraries:

sudo apt-get update
sudo apt-get install -y libdbus-1-dev libnetfilter-conntrack-dev libidn11-dev nettle-dev libval-dev dnssec-tools

Once everything was in place I ran the following command again:
sudo make install

then
sudo service dnsmasq restart

I started wireshark again and pxe booted the target laptop. This time I saw the dhcp discover, offer from both the router and the dnsmasq server, then dhcp request and finally the dhcp ack from the router. !! On the client it had booted to the point the iPXE kernel was initializing devices. (!!)

The rest of the settings didn’t change all I did for this pass is upgrade dnsmasq from 2.72 to 2.76 (the version reported to work with uefi firmware).

[george1421]

Here is a pcap of the proper UEFI PXE boot. This was captured from the FOG-Pi server perspective.

0_1475453397643_uefi_pxe_boot.pcap

While I haven’t been able to get into the iPXE boot menu as of now, I can say that the dnsmasq part appears to be working since the iPXE kernel makes it to the target. But right now the iPXE kernel tries to initialize the devices for about 5 minutes then reboots the computer. I still need to dig into that but so far its taken me 4 hours to get this far so enough for tonight.

[Sebastian Roth]

@george1421 Great work so far! The only problem I see is that your other DHCP server (which hands out the IP) also offers the next-server option (pointing to a different IP!). This does not seem to be a problem in the first round of DHCP as the iPXE binary is being loaded via TFTP properly but I am pretty sure you will run into this as soon as you get past the initializing devices… part of iPXE.

That said I am really wondering why it hangs. Have you tried the exact same ipxe.efi binary supplied to the client with a different DHCP server? From what I remember I never had different results when offering ipxe.efi with isc-dhcp vs. dnsmasq.

[george1421]

@Sebastian-Roth I also saw that too (dhcp server sending out the next-server). The main dhcp server (Linksys WRT54GS, yes I know its old but it is a nice friend) is sending out the next-server pointing to itself. I thought this was strange since there is no option to change/set this in the wrt54’s firmware. I could reflash it with DD-WRT but it hasn’t been a problem until now.

As for the 6230 hanging. If I remember right that series was the first to fully support network pxe booting in uefi mode. I need to check to see if there is a firmware update for that. I also plan on building an ipxe usb boot disk to check to see if its the ipxe kernel or something else. The last bit is I might try the old ipxe kernel that Tom added back into fog, the one for getting the Surface Pros to boot. I think my issue is with ipxe and not dhcp/dnsmasq at this time since the ipxe kernel is making it to the target computer.

[Sebastian Roth]

@george1421 said:

The main dhcp server (Linksys WRT54GS, yes I know its old but it is a nice friend) is sending out the next-server pointing to itself. I thought this was strange since there is no option to change/set this in the wrt54’s firmware.

Unfortunately a lot of home router devices seem to do this stupid thing. I still have no idea why! We have spent a couple of days helping people to make things work with those kind of router. It’s just a pain in the ass - sorry for that.

Keeping my fingers crossed that you can make it work. Just let me know if you need some more advice.

[george1421]

I started doing a bit more reverse engineering on what these bits of the dnsmasq configuration was actually doing.

If you turn off this section of the dnsmasq config, that also disabled udp port 4011 (dhcpProxy).

# PXE menu.  The first part is the text displayed to the user.  The second is the timeout, in seconds.
pxe-prompt="Press F8 for boot menu", 10

# The known types are x86PC, PC98, IA64_EFI, Alpha, Arc_x86,
# Intel_Lean_Client, IA32_EFI, BC_EFI, Xscale_EFI and X86-64_EFI
# This option is first and will be the default if there is no input from the user.
# PXEClient:Arch:00000
pxe-service=X86PC, "Boot BIOS PXE", undionly
# PXEClient:Arch:00007
pxe-service=BC_EFI, "Boot UEFI PXE-BC", ipxe.efi
# PXEClient:Arch:00009
pxe-service=X86-64_EFI, "Boot UEFI PXE-64", ipxe.efi

This causes the dhcp proxy function to fail and the device won’t boot.

If you turn off this section

dhcp-vendorclass=BIOS,PXEClient:Arch:00000
dhcp-vendorclass=UEFI32,PXEClient:Arch:00006
dhcp-vendorclass=UEFI,PXEClient:Arch:00007
dhcp-vendorclass=UEFI64,PXEClient:Arch:00009

dhcp-boot=net:UEFI32,i386-efi/ipxe.efi,,192.168.112.24
dhcp-boot=net:UEFI,ipxe.efi,,192.168.112.24
dhcp-boot=net:UEFI64,ipxe.efi,,192.168.112.24
dhcp-boot=net:BIOS,undionly.kpxe,,192.168.112.24

The dnsmasq server will not send out the file name in the initial dhcp offer request. Which I found doesn’t matter. I could send out one name for the dhcp offer and another name in the proxy section. The proxy section always won. So in my current config I have the vendor class stuff turned off since it was not impacting what actually was downloaded from the tftp server.

pxe-prompt="Boot to FOG iPXE", 1
pxe-service=X86PC, "Boot BIOS PXE", undionly.kpxe
pxe-service=BC_EFI, "Boot UEFI PXE-BC", ipxe.efi
pxe-service=X86-64_EFI, "Boot UEFI PXE-64", snp.efi

So this is what I have for the part that actually sends the file to the booting client. I also discovered in the new version of dnsmasq that it doesn’t automatically append .0 to the file name, what ever the name is listed above is what is requested from the tftp server.

In the pxe-service line. The first value correlates to the Architecture Type in this document: https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence#General

By creating unique pxe-service lines your dnsmasq server will send out the proper boot file based on the transmitted architecture type in the dhcp request. So far in testing with the 6230 undionly.kpxe is sent in bios mode and ipxe.efi is sent in uefi mode. I’m still hitting a wall in uefi mode where it initializes devices for about 5 minutes then reboots. But the right iPXE kernel is being sent to the target computer. I checked and the bios is old (A11) vs current A15. I’m going to update the firmware after a bit to see if that is what is causing iPXE to not init right. I can say it works flawlessly in bios mode.

[Wayne Workman]

@george1421 said in Dnsmasq bios and uefi:

also discovered in the new version of dnsmasq that it doesn’t automatically append .0 to the file name, what ever the name is listed above is what is requested from the tftp server.

Wow…

[george1421]

@Wayne-Workman Considering what is currently being packaged with modern linux distributions is dnsmasq 2.72 (Sep 2014) is over two years old, its about time they did drop the old syslinux syntax requirements. One of many improvements I’ve seen so far.

[edit] Just reviewing the change log for 2.76 this jumps out in regards to file names:

	    Subtle change in the semantics of "basename" in
	    --pxe-service. The historical behaviour has always been
	    that the actual filename downloaded from the TFTP server
	    is <basename>.<layer> where <layer> is an integer which
	    corresponds to the layer parameter supplied by the client.
	    It's not clear what the function of the "layer" 
	    actually is in the PXE protocol, and in practise layer 
	    is always zero, so the filename is <basename>.0
	    The new behaviour is the same as the old, except when
	    <basename> includes a file suffix, in which case
	    the layer suffix is no longer added. This allows
	    sensible suffices to be used, rather then the
	    meaningless ".0". Only in the unlikely event that you
	    have a config with a basename which already has a
	    suffix, is this an incompatible change, since the file
	    downloaded will change from name.suffix.0 to just 
	    name.suffix

[Sebastian Roth]

@george1421 said:

I checked and the bios is old (A11) vs current A15. I’m going to update the firmware after a bit to see if that is what is causing iPXE to not init right. I can say it works flawlessly in bios mode.

Would you be able to service this exact same ipxe.efi binary using isc-dhcp just to see if it makes a difference? My guess is no but you never know.

[george1421]

@Sebastian-Roth I think my next step is to first update the bios on this computer from A11 to A15. The change log for these updates many uefi updates and hardware (nic and such) firmware updates. I want to make sure I’m not chasing something that has already been addressed. I have 2 issues with getting this done: 1) This computer runs Zorin (ubuntu variant) and the firmware updates are windows based. I have a WinPE flash drive at work that we use to update the computer bios at work. I need to make a copy so I can use it to update this 6230. 2) This is my wife’s computer, if I break it I will never hear the end of it. So I need to be spot on with the upgrade if you know what I mean.

[george1421]

@george1421 I was finally able to update that 6230 from firmware A11 to A15. Without changing my FOG-Pi / dnsmasq setup the 6230 now pxe boots in uefi mode (whoot!!). The kernel stayed at initializing devices for about 15 seconds, I started to panic after 8, I figured it was hung and reach for my FOG GRUB usb boot drive. When I turned around the 6230 was sitting at the FOG iPXE Menu. I timed it again and it was bout 15 seconds to init the devices and display the FOG iOXE menu. I was able to quick register the system and everything worked fine.

Below is my final dnsmasq configuration for dual booting bios (legacy) and uefi systems on dnsmasq version 2.76

# Don't function as a DNS server:
port=0

# Log lots of extra information about DHCP transactions.
log-dhcp

# Set the root directory for files available via FTP.
tftp-root=/tftpboot

# PXE menu.  The first part is the text displayed to the user.  The second is the timeout, in seconds.
pxe-prompt="Booting FOG Client", 1

# The known types are x86PC, PC98, IA64_EFI, Alpha, Arc_x86,
# Intel_Lean_Client, IA32_EFI, BC_EFI, Xscale_EFI, ARM_EFI and X86-64_EFI
# This option is first and will be the default if there is no input from the user.
# PXEClient:Arch:00000
 pxe-service=X86PC, "Boot BIOS PXE", undionly.kpxe
# PXEClient:Arch:00007
 pxe-service=BC_EFI, "Boot UEFI PXE-BC", snp.efi
# PXEClient:Arch:00009
 pxe-service=X86-64_EFI, "Boot UEFI PXE-64", snp.efi

dhcp-range=192.168.112.24,proxy

According to the change log for dnsmasq there are issues with certain uefi firmware for displaying the dnsmasq boot menu so for uefi firmware dnsmasq will just pick the first matching service entry that matches the arch type, as long as there is only one and only matching service. You will not see this menu displayed for uefi firmware, where for bios you will see the menu entry for 1 second.

I did note in the iPXE bootloader that it did say duplicate next server values presented (or something like that). And that is in line with what we were seeing in the earlier pcap where both dnsmasq and the soho router were sending conflicting next-server values.

Here is the pcap of my last and working test. Note: I see I left the snp.efi kernel configured in dnsmasq too!!.

0_1475719888587_output.pcap

[george1421]

@george1421 Last and final comment. Just for grins, I move the original Raspian Jessie version of dnsmasq (v2.72) back in place and restarted dnsmasq. With 2.72 running and the same configuration as before the Dell 6230 failed to pxe boot in UEFI mode, but would boot in bios (legacy) mode. So if you are going to use dnsmasq AND require pxe booting uefi systems you must upgrade dnsmasq to 2.76 or it will fail.

[KnightRaven]

@george1421

Hi,
I was just wondering if you actually got this to work in proxy mode? I have tried and can seem to get it to UEFI boot in proxy. I tried setting dnsmasq to serve as DHCP for a moment(and unplugged from rest of network) with just my test client and Fog/PXE and that worked. Was able to get to Fog menu.

Using dnsmasq 2.76 and just pulled latest fog rc36.

Do I need to compile something differently that I’m not seeing(it’s posible I missed something)? Or does it just not work in proxymode at this time?

thanks,
Jason

[george1421]

@KnightRaven Yes dhcpProxy mode works very well as long as you have 2.76 version of dnsmasq.

Post what your ltsp.conf files is here. I’ll take a look.

Also from the fog server command prompt key in dnsmasq -v and post the output here

[KnightRaven]

@george1421
~ $ dnsmasq -v
Dnsmasq version 2.76 Copyright 2000-2016 Simon Kelley
Compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth no-DNSSEC loop-detect inotify

This software comes with ABSOLUTELY NO WARRANTY.
Dnsmasq is free software, and you are welcome to redistribute it
under the terms of the GNU General Public License, version 2 or 3.

[george1421]

@KnightRaven OK what I want you to do (speaking as a moderator now) please create a new thread on this issue. and also include the contents of your /etc/dnsmasq.d/ltsp.conf file. We’ll carry on the discussion there.

But your dnsmasq version should/will work for what you want to do.

[KnightRaven]

@KnightRaven
ltsp.conf file…
0_1481838650169_ltsp.conf

I’m about to be out for the day so I may not get a chance to test for a few weeks. The file may also be a bit ugly but i tried to leave as much of the original info in and just updated info as needed.

[KnightRaven]

@george1421

oops. saw too late. Will open new thread.

[george1421]

@KnightRaven Yeah, I see the issue right away. When you are back on this project create a new thread and we can work through what needs to be done. You are missing a few lines that make the uefi bit work.