Advanced dnsmasq techniques

george1421

I’ve spent several hours (more than I’d like to admit) of changing, restarting, capturing and reviewing the dnsmasq booting process. The results of this testing is outlined below. I did some minor review of the documentation but the majority of what I learned, I learned the hacker way. There may be official recommendations that differ from what I’m going to post here, this is information is based on my first hand experience with dnsmasq 2.76 (NOTE: DNSMasq 2.76 was specifically compiled on my target computer. It is NOT the version that is available from most linux distribution’s repositories. If you want to follow these instructions you MUST compile your own dnsmasq 2.76 for your FOG server).

Resources used for testing
FOG Server: FOG-Pi (Raspian Jessie)
FOG/DNSMasq IP: 192.168.112.24
Router: WRT54 (soho router) @ 192.168.112.1
DNSMasq: v2.76 (compiled on FOG-Pi server)
Wireshark
Target computer: Dell e6230
Debug computer: Dell T3510

Base ltsp.conf file

# 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

# 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

# The boot filename, Server name, Server Ip Address
dhcp-boot=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="Booting FOG Client", 1

dhcp-range=192.168.112.24,proxy

george1421

This last post is about the troubles I had when trying to build the match filter. I knew from past experieences that there was a uuid field and that data was sent with the initial dhcp request. I first saw this information when you pxe boot a target computer in bios (legacy) mode. It is displayed on the screen with the dhcp server’s address, target computer’s IP, netmask and gateway information. But usually it flies off the screen so quick its hard to document since its so long.

I did a little research on this dhcp option ( 97 client-identifier ) field and this is what I found in the RFQ that describes these dhcp fields. Here is a snippet of the rfq (note this is not my intellectual property only a reprint from the original RFC-4361 https://tools.ietf.org/html/rfc4361)

   DHCPv4 clients that support more than one network interface SHOULD
   use the same DUID on every interface.  DHCPv4 clients that support
   more than one network interface SHOULD use a different IAID on each
   interface.

I did have some trouble getting the pattern match just right (inserted correctly below).

dhcp-match=set:e6230,97,00:44:45:4c:4c:38:00:10:36:80:4e:c4:c0:4f:4a:58:31

My first attempt at the text to match came from the dhcp request in wireshark. This dhcp option 97 was presented as “4c:4c:45:44:00:38:36:10:80:4e:c4:c0:4f:4a:58:31” in wireshark. So I pasted that into the dhcp-match and the match failed so the action never fired. (!!). Looking now at the raw data wireshark presented the proper information, according to the RFC, was in the dhcp packet it was not just presented on the screen.

SO I knew the log-dhcp option was set in the dnsmasq file, I checked the /var/log/syslog file and there was all of the dhcp information I was searching for, except… the dhcp option 97 line conained “00:44:45:4c:4c:38:00:10:36:80:4e:c4:c0:4f:4a…” ( !! ) its incomplete!

So being the hacker I am I merged the information from wireshark with the information from the dnsmasq log to produce the final match filter.

#From wireshark
   4c:4c:45:44:00:38:36:10:80:4e:c4:c0:4f:4a:58:31
#From syslog
00:44:45:4c:4c:38:00:10:36:80:4e:c4:c0:4f:4a...

#Produced
00:44:45:4c:4c:38:00:10:36:80:4e:c4:c0:4f:4a:58:31

Looking at it now I'm not even sure why it worked. I know the UUID/IAD is constructed with two parts. And based on the number from wireshark I can see there is a big endian little endian thing going on for the UUID. but that doesn't explain how the IAD part is correct.

I’m not sure where the 00: prefix comes from the number too. I know the first 4 letters should spell dell for dell computers. If you watch the bios boot screen you can see the UUID number presented there is something like 44454c4c4544-0038-3610-804ec4c04f4a5831 (hint it goes very fast), but you can see lines up with what dnsmasq reported minus the leading 00. It would be interesting to know how dell decides on the UUID for a specific model. I’m sure there is some encoding going on.

george1421

Adding (crazy complex) UEFI support

We’ll start this section where we left off with the previous section where we added uefi support to the basic script.
Just to remain consistent this is the script we are going to start with

port=0

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

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

# 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

# inspect the vendor class string and match the text to set the tag
dhcp-vendorclass=BIOS,PXEClient:Arch:00000
dhcp-vendorclass=UEFI32,PXEClient:Arch:00006
dhcp-vendorclass=UEFI,PXEClient:Arch:00007
dhcp-vendorclass=UEFI64,PXEClient:Arch:00009

# Set the boot file name based on the matching tag from the vendor class (above)
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

# The boot filename, Server name, Server Ip Address
dhcp-boot=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="Booting FOG Client", 1

dhcp-range=192.168.112.24,proxy

Now lets say we have a computer that will not boot with the default ipxe.efi file, but instead we need the alternate intel.efi boot kernel. We’ll add some dynamics to our above script so that for all computers except for our specific model ipxe.efi is sent to the client and when we pxe boot our specific client intel.efi is sent to just that computer.

I do have to post a caveat here. The uuid field "should" represent the device type for the model and not the unique and individual device (we could use the mac address for that). I have not tested like model computers to see if the uuid is an exact match. I do see references to that this field contains two parts the uuid and guid bits. We may need to parse those if I find that these numbers are not model specific.

In the script above we’re going to add a new pattern match test just under the vendor class match. Modify the above script to look similar to this snippet.

# inspect the vendor class string and match the text to set the tag
dhcp-vendorclass=BIOS,PXEClient:Arch:00000
dhcp-vendorclass=UEFI32,PXEClient:Arch:00006
dhcp-vendorclass=UEFI,PXEClient:Arch:00007
dhcp-vendorclass=UEFI64,PXEClient:Arch:00009

#UUID for a Dell e6230 I tested (this info was gleaned from the dnsmasq log file that recorded
# a pxe boot session of this target computer
dhcp-match=set:e6230,97,00:44:45:4c:4c:38:00:10:36:80:4e:c4:c0:4f:4a:58:31

What this dhcp-match command does is set the flag e6230 to TRUE if dhcp option 97 {uuid/guid client identifier} if the data matches “00:44:45:4c:4c:38:00:10:36:80:4e:c4:c0:4f:4a:58:31” now if we determine a sub section of this uuid field is sufficient to identifiy the client we could shorten this pattern match to let say “00:44:45:4c:4c:38:00:10:36” if this properly identifies the e6230 (I simply don’t know as of now).

Now that we have the match command we need to do something with that match. That is where the next line comes in. We’ll add another dncp-boot line. First I’ll mention a dhcp-boot line that we are NOT going to use and why. This line is close to what we want in the file config file

dhcp-boot=tag:e6230,intel.efi,192.168.112.24 192.168.112.24

To decode this line there is a conditional test (if (tag:e6230 == true) then Send “intel.efi” from the following tftp server 192.168.112.24. So if our pattern matches above and set the tag e6230 true then send intel.efi.

The reason why we don’t want to use this one is because it will match as long as the uuid is the same. This means that the intel.efi boot file name will be sent if the computer is in uefi mode as well as bios (legacy) mode. To correct this behavior we’ll add another conditional test which creates an AND condition. What we want is to send the intel.efi file name if e6230 and UEFI flags are set. This dhcp-boot line would look like this:

dhcp-boot=tag:UEFI,tag:e6230, intel.efi, 192.168.112.24, 192.168.112.24

So this line will match when the UEFI tag is true (set by the vendor class match of “dhcp-vendorclass=UEFI,PXEClient:Arch:00007”) and the e6230 tage is true.

Remember I said above the order of the dhcp-boot lines appear to be important. The last match will win so we want to place this new dhcp-boot line at the bottom of the list. Adding this line in will make our total ltsp config file look like this.

port=0

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

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

# 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

# inspect the vendor class string and match the text to set the tag
dhcp-vendorclass=BIOS,PXEClient:Arch:00000
dhcp-vendorclass=UEFI32,PXEClient:Arch:00006
dhcp-vendorclass=UEFI,PXEClient:Arch:00007
dhcp-vendorclass=UEFI64,PXEClient:Arch:00009

#UUID for a Dell e6230 I tested (this info was gleaned from the dnsmasq log file that recorded
# a pxe boot session of this target computer
dhcp-match=set:e6230,97,00:44:45:4c:4c:38:00:10:36:80:4e:c4:c0:4f:4a:58:31

# Set the boot file name based on the matching tag from the vendor class (above)
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

# Our test to ensure both the UEFI and e6230 tags are set. 
dhcp-boot=tag:UEFI,tag:e6230, intel.efi, 192.168.112.24, 192.168.112.24

# The boot filename, Server name, Server Ip Address
dhcp-boot=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="Booting FOG Client", 1

dhcp-range=192.168.112.24,proxy

Save the file and exit out of the editor. Then restart the dnsmasq service.

Its been a while since I posted this. This knowledge here and above has been gleaned from some google-fu searches and trial and error (the hacker's way) to come up with the above. I'm sure much of this thread is inaccurate and the rest is completely wrong. This information is content that I've been able to compile of the past 2 days of testing. If you discover any information is inaccurate in this thread, please DM me and I'll integrate it into this document.

An interesting fact I found while researching the dhcp-match command for dhcp option 97. For the dell computers the uuid string of '00:44:45:4c:4c:38:00:10:36:80:4e:c4:c0:4f:4a:58:31" If you discount the first 8 bits [00] (i.e just look at. 44:45:4c:4c) that spells dell in hex ascii.

george1421

Adding (a bit more complex) UEFI support to the basic script

We’ll start with our basic configuration file again. Note: we removed the pxe-serivce entries we added previously.

# 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

# 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

# The boot filename, Server name, Server Ip Address
dhcp-boot=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="Booting FOG Client", 1

dhcp-range=192.168.112.24,proxy

In this example we’re going to do some additional dhcp matching options based on the initial target dhcp discover broadcast.

# 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

# 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

# inspect the vendor class string and match the text to set the tag
dhcp-vendorclass=BIOS,PXEClient:Arch:00000
dhcp-vendorclass=UEFI32,PXEClient:Arch:00006
dhcp-vendorclass=UEFI,PXEClient:Arch:00007
dhcp-vendorclass=UEFI64,PXEClient:Arch:00009

# Set the boot file name based on the matching tag from the vendor class (above)
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

# The boot filename, Server name, Server Ip Address
dhcp-boot=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="Booting FOG Client", 1

dhcp-range=192.168.112.24,proxy

As you might notice above we added the dhcp match commands to identify the hardware arch and then set a dnsmasq tag to match the patter identified.

For example dhcp-vendorclass=UEFI,PXEClient:Arch:00007 will look in the vendor class field of the dhcp request. If that field pattern matches PXEClient:Arch:00007 then the flag titled UEFI to true.

The next part of this match is done here in the dhcp-boot command.
dhcp-boot=net:UEFI,ipxe.efi,,192.168.112.24
This line says if the tage UEFI is set then send ipxe.efi (and optionally) 192.168.112.24 to the target computer in the dnsmasq dhcp offer reply.

You might notice that in the dhcp-boot lines there is no BIOS reference. That is because there is a default line that covers the BIOS type arch. That line is dhcp-boot=undionly.kpxe,,192.168.112.24. Basically if no other dhcp-boot lines match then undionly,kpxe will be returned to the target computer. I could have added a dhcp-boot=net:BIOS line then the default dhcp-boot line would no match.

you will need a matching dhcp-boot line for every arch you want to support.

Remember this for the next part. The order of the dhcp-boot lines are important since the last match wins. So if you have 3 matchine dhcp-boot lines (based on different criteria) the last matching dhcp-boot line wins.

george1421

Adding UEFI support to the basic script

The first way will be the simplest way to add uefi support will be to add a matching pxe-service line for each known architecture. In this case we’ll adjust our configuration by adding the pxe-service lines to the basic configuration.

# 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

# 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

# The boot filename, Server name, Server Ip Address
dhcp-boot=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="Booting FOG Client", 1

# The known types are x86PC, PC98, IA64_EFI, Alpha, Arc_x86,
# Intel_Lean_Client, IA32_EFI, ARM_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.kpxe

# 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

As you note above we’ve added dhcpProxy support for BIOS, and both UEFI hardware types. If you know you may have additional hardware architectures you will need to add additional lines. I “think” some early Surface Pros and Mac computers were IA32_EFI you may need to add that line for those hardware platforms.
Once you save the ltsp.conf file and restart dnsmasq your dnsmasq server should allow booting both bios (legacy) and uefi systems automatically.

(Hacker Note:) If you want to send the target computer to a different tftp server for a specific hardware type you can add the preferred tftp server to the end of the pxe-service line.

pxe-service=BC_EFI, "Boot UEFI PXE-BC", ipxe.efi,192.168.112.99

george1421

General observations

The above base script support dnsPROXY function for BIOS (legacy) clients only. As this configuraiton transforms we will add support for uefi systems (plus a few cool things I figured out).

You must include a pxe-prompt or a pxe-service entry in your configuration file or the dnsProxy function wont respond to a dhcp request.
The order of your “dhcp-boot=” (not shown above) dictates what boot file is sent to your target computer, remember last match wins
If you enter a pxe-service entry for a matching architecture (i.e. pxe-service=X86PC, "Boot BIOS PXE", undionly.kpxe) dnsmasq will not send out the file file mentioned by a “dhcp-boot=” line.
If you include a pxe-service entry the boot-file entry will not be sent to the client during a dhcp offer reply. This must signal to the client (missing boot-file, but has next-server) to use the dhcp proxy port 4011 to request the file name. Every time I had a matching pxe-service entry the {boot-file} was not sent but after the client ACK back to the dhcp server it would request the boot file name on udp port 4011 from the dnsmasq server.
I’m sure there are other things I learned that I’ve already forgot, leaving a placeholder…

Wayne Workman

wiki worthy

george1421

@Wayne-Workman said in Advanced dnsmasq techniques:

wiki worthy

Maybe once I can have a quorum of people prove or disprove my thesis. Right now there is a lot of assumptions being made (like I know what I’m doing) that need to be proven out through testing.

Wayne Workman

This has been added to the wiki here:
Link

Advanced dnsmasq techniques

168

12.0k

17.3k

155.2k