Posts made by george1421

@dureal99d said in 7156 Uefi pxe DHCP error:

@george1421 but I should also educate myself on the recommended

You know the skills you are adding here are a bit complex, but also VERY valuable when trying to debug why networking isn’t working as intended. These are always good skills to have in your toolbox, for whenever you need them.

So far you’ve compiled and installed a linux application from source code, setup a dnsmasq server, and now are digging into network communications and soon pxe booting both uefi and bios (legacy) devices. While a lot was done with parroting what I posted, you have started with the foundations of some rather complicated subjects, where you go with it is up to you.

@dureal99d said in 7156 Uefi pxe DHCP error:

@george1421 I guess what I was asking it should I disable DNS masq on my DD wrt router

Yes… you didn’t mention you had dd-wrt running that offers dhcp.

In this case No don’t disable it because dd-wrt is using dnsmasq for dns forwarding, dhcp, and something else (I think). DNSMasq running on your FOG server will still function in the proxyDHCP role.

@george1421 Another option is to install tcpdump on your FOG/DNSMasq server then use the following filter:
sudo tcpdump -w output.pcap port 67 or port 68 or port 69 or port 4011

Then perform the pxe boot. The tcpdump program is much lighter then wireshark, but doesn’t allow viewing of the captured data. Once your pxe device boots to completion or error then ctrl-c out of the tcpdump program. You can transfer this file to a windows computer using putty and review it with wireshark. This is the exact process I used when debugging dnsmasq for one of my tutorials. This way you can see what changes to the ltsp.conf file have on the output when viewed from wireshark.

@dureal99d I believe the proper term is IT voodoo.

Well once you update that file and restart dnsmasq, dnsmasq will listen for a dhcp broadcast and reply as if it is a dhcp server but will only offer specific dhcp fields.

I’m all for education so I suggest you learn and understand what is going on here. I suggest that you install wireshark on a Windows computer or if you have to your fog server and use the following filter “port = 67 or port = 68 or port = 69 or port = 4011” This will instruct wireshark to only listen for this communication. Now pxe boot the target computer. Now if you using wireshark on a windows computer it will only be able to hear broadcast bits of dhcp (this will be enough to understand what is going on.) If you install it on the FOG server then you can see the entire pxe booting process.

@dureal99d Yes it is a file you create. Typically we call this ltsp.conf and it goes in /etc/dnsmasq.d directory. You will need to use your favorite text editor. I use vi (because I’m old). You need to be sure to launch your text editor either as administrator if doing via the gui or as sudo if launching it by command line. If you use vi then the command would be sudo vi /etc/dnsmasq.d/ltsp.conf If you have never used vi before, don’t! All of the text editor commands are cryptic and will drive you nuts to learn.

@dureal99d Ah ok to add uefi support? I am working on another tutorial that covers that. https://forums.fogproject.org/topic/8726/advanced-dnsmasq-techniques

I think the bits you need are on the third post. Below is that config file. The 192.168.112.24 is MY FOG/dnsmaq server. This is the simple way to add uefi support. I’m working on a more complex way that opens up new options. But if you want to get uefi/bios working this should get you going.

# 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

@dureal99d said in 7156 Uefi pxe DHCP error:

@george1421 to edit this file what do I type

?? File you need to edit ??

@dureal99d OK then issue the network manager restart that is below. Then (at least on my Pi) inspect the /var/log/syslog file way at the bottom. You should see the startup of the dnsmasq service. Confirm the version number there is showing 2.76. If that is the case then you have successfully updated your dnsmasq to 2.76.

@dureal99d Yes, that is expected. It says the binary you complied is up to date and just recopied the files to their destination location. So dnsmasq -v should show that 2.76 is installed (hope).

@dureal99d OK just install your distro’s dnsmasq version then just pop back to the directory where you built dnsmasq and just key in sudo make install and it should see that the binary has already been created and just copy over the compiled version. But did the compile right since it was installed and reported the right version when the command was run.

@mkstreet If I had to pick one thing that your current network does that I would wish to stop is this.

Your primary dhcp server (172.16.1.1) to not send the dhcp option 66 {next-server} with a value of 172.16.1.1 to your subnet (10.0.253.0/16). Understand I’m not saying this is your entire problem and there may be something else underlying issue. The second part (maybe wish), that with the next server being not sent at 172.16.1.1 but have the next server value being sent as the IP address of your FOG server. If that happens then dnsmasq is not needed.

@dureal99d Did you remember to install your distribution’s dnsmasq package first? If so the service name may not be called dnsmasq since it appears that Ubuntu 16 looks like its systemd based. A quick check is to just reboot the computer. Once its back up then key in ps aux|grep dnsmasq to see if the dnsmasq service is running in memory. I need to figure out what the proper systemd restart command is.

[Edit] According to this github page: https://gist.github.com/magnetikonline/6236150

# for Ubuntu 16.04LTS
$ sudo systemctl restart NetworkManager

# for Ubuntu 14.04LTS
$ sudo restart network-manager

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).

1. 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.
2. The order of your “dhcp-boot=” (not shown above) dictates what boot file is sent to your target computer, remember last match wins
3. 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.
4. 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.
5. I’m sure there are other things I learned that I’ve already forgot, leaving a placeholder…

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

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.

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.

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.

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

@dureal99d Sorry I was testing some advanced dnsmasq configs so I couldn’t respond right away. Yes my current test environment is with a soho home router (WRT54) as the dhcp server and my FOG-Pi server (Pi2b running Raspbian) as the dnsmasq 2.76 server.

@dureal99d I actually just completed the first phase over in the tutorials

https://forums.fogproject.org/topic/8725/compiling-dnsmasq-2-76-if-you-need-uefi-support