Difference between revisions of "ProxyDHCP with dnsmasq"
m (→dnsmasq's Roles in FOG) |
|||
| Line 12: | Line 12: | ||
= dnsmasq's Roles in FOG = | = dnsmasq's Roles in FOG = | ||
| − | dnsmasq is used when there is an existing DHCP service on the network that must continue to be used and cannot be altered to support FOG. dnsmasq is a form of Proxy DHCP. It listens for DHCP requests (from hosts) and responses (from dhcp service). When a request and response is heard, dnsmasq "adds to" the response. For it's role in fog, it adds the next-server and file name options. These are known in Windows as DHCP Options 066 and 067. | + | '''From the perspective of FOG''', dnsmasq is used when there is an existing DHCP service on the network that must continue to be used and cannot be altered to support FOG. dnsmasq is a form of Proxy DHCP. It listens for DHCP requests (from hosts) and responses (from dhcp service). When a request and response is heard, dnsmasq "adds to" the response. For it's role in fog, it adds the next-server and file name options. These are known in Windows as DHCP Options 066 and 067. |
Ideal scenarios for dnsmasq include: | Ideal scenarios for dnsmasq include: | ||
| Line 27: | Line 27: | ||
*When you intend your FOG server to be portable. | *When you intend your FOG server to be portable. | ||
| − | |||
= How ProxyDHCP works = | = How ProxyDHCP works = | ||
Revision as of 17:19, 12 October 2016
Legacy article:
Using_FOG_with_an_unmodifiable_DHCP_server/_Using_FOG_with_no_DHCP_server
Related articles:
Modifying existing DHCP server to work with FOG
Contents
dnsmasq's Roles in FOG
From the perspective of FOG, dnsmasq is used when there is an existing DHCP service on the network that must continue to be used and cannot be altered to support FOG. dnsmasq is a form of Proxy DHCP. It listens for DHCP requests (from hosts) and responses (from dhcp service). When a request and response is heard, dnsmasq "adds to" the response. For it's role in fog, it adds the next-server and file name options. These are known in Windows as DHCP Options 066 and 067.
Ideal scenarios for dnsmasq include:
- When you are unwilling or unable to turn off DHCP services on a consumer-grade piece of network equipment (such as an ISP-provided device or low-end store purchased device)
- When you are unwilling or unable to run DHCP on your FOG Server.
- When you do not have access or permission to change the DHCP service at your place of employment.
- When changes to your employer's DHCP service may be overly complex to perform.
- When errors made in the configuration of your employer's DHCP service could cause an unwanted, unplanned, or unexpected network outage.
- When you intend your FOG server to be portable.
How ProxyDHCP works
- When a PXE client boots up, it sends a DHCP Discover broadcast on the network, which includes a list of information the client would like from the DHCP server, and some information identifying itself as a PXE capable device.
- A regular DHCP server responds with a DHCP Offer, which contains possible values for network settings requested by the client. Usually a possible IP address, subnet mask, router (gateway) address, dns domain name, etc.
- Because the client identified itself as a PXEClient, the proxyDHCP server also responds with a DHCP Offer with additional information, but not IP address info. It leaves the IP address assigning to the regular DHCP server. The proxyDHCP server provides the next-server-name and boot file name values, which is used by the client during the upcoming TFTP transaction.
- The PXE Client responds to the DHCP Offer with a DHCP Request, where it officially requests the IP configuration information from the regular DHCP server.
- The regular DHCP server responds back with an ACK (acknowledgement), letting the client know it can use the IP configuration information it requested.
- The client now has its IP configuration information, TFTP Server name, and boot file name and it initiate a TFTP transaction to download the boot file.
Install dnsmasq on CentOS 7
Setting up DNSMasq on Centos 7 is pretty straight forward and can be done in about 10 minutes.
Use case(s):
- You don't have administrative access to the dhcp server for your subnet/network (such as an ISP run router)
- Your dhcp server is a basic one like what you might find if you use a home class internet router.
Here are the steps needed to setup dnsmasq on your FOG server running under Centos 7
- Ensure that Centos is up to date
- Install the service
- Create a config file for your FOG server
- Paste in the following settings
- Create the needed .0 files. By creating a link each time the undionly file is updated the .0 file will remain current.
- Restart the dnsmasq service
- Then ensure dnsmasq service starts on each boot.
yum upgrade -y
yum install dnsmasq -y
vi /etc/dnsmasq.d/ltsp.conf (hint: I'm old school and use vi exclusively, you may use what ever editor you choose)
# 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,,<fog_server_IP> # 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 # 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 and X86-64_EFI # This option is first and will be the default if there is no input from the user. pxe-service=X86PC, "Boot to FOG", undionly pxe-service=X86-64_EFI, "Boot to FOG UEFI", ipxe pxe-service=BC_EFI, "Boot to FOG UEFI PXE-BC", ipxe dhcp-range=<fog_server_ip>,proxy
The above values are for BIOS booting via PXE. As of the date of this post, dnsmasq does not support the uefi menu or uefi booting. So for now dnsmasq and uefi are not compatible (as of May16 the devs of dnsmasq have released their first attempt an supporting uefi firmware. I can see great things coming from this). You must update the <fog_server_ip> values with the exact IP address of your FOG server.
ln -s /tftpboot/undionly.kpxe /tftpboot/undionly.0 ln -s /tftpboot/ipxe.efi /tftpboot/ipxe.0
systemctl restart dnsmasq.service
systemctl enable dnsmasq.service
For the copy and paste people like me here is the concise version.
yum upgrade -y yum install dnsmasq -y vi /etc/dnsmasq.d/ltsp.conf <insert text> <update settings in text> ln -s /tftpboot/undionly.kpxe /tftpboot/undionly.0 ln -s /tftpboot/ipxe.efi /tftpboot/ipxe.0 systemctl restart dnsmasq.service systemctl enable dnsmasq.service
Compiling dnsmasq 2.76 if you need uefi support
Reference: https://forums.fogproject.org/topic/8725/compiling-dnsmasq-2-76-if-you-need-uefi-support
There has been a brilliant bit of code added to dnsmasq 2.76 (May 2016) to provide / fix support for sending uefi boot information to uefi systems. The issue is that most linux distributions do not have this latest version of dnsmasq available for install. It may take quite a while to get this version into the mainstream linux distributions. As always the case with FOSS environments you can download and compile your own software as long as the author releases the source code.
In this tutorial I'll outline the steps required to compile and install this latest version of dnsmasq for common distributions of linux. I don't have access to every version and/or flavor so I'll only document what I've personally perform. I would encourage other, that can, document their experiences here with flavors/versions of linux that I don't cover.
Before you compile this updated version of dnsmasq be sure that you install the version of dnsmasq from your linux distributions, package repository. This way you will be sure that all of the supporting scripts and dependences have been installed. In the steps below we will just replace the dnsmasq binary with the latest compiled version.
Ubuntu 16.04 LTS based systems
Build system: Mint 18 x64 (Based on Ubuntu 16.04 LTS) (note the following instructions worked perfectly for Raspbian Jessie which is Debian based)
- First we need to setup our build environment
- Next we'll get the source code for dnsmasq 2.76
- Extract the source code from the tar file
- Change into the dnsmasq build directory
- Lets update a few settings in the config file. I know there are other ways to go about this with command line switches, but I didn't
- Find this section
- Paste in these settings just below the above text
- Save and exit the config.h file
- We need to see where the current dnsmasq file is located. (NOTE: Please be sure that dnsmasq has already been installed in your linux distribution to ensure all of the dependences have been installed before we proceed)
- This command should respond with something like this:
- The key bit of info here is that dnsmasq is installed in **/usr/sbin**. What we need to do is tell the install script to not place the dnsmasq files in the default location (according to dnsmasq of /usr/local/sbin) but to place the files where the distribution dnsmasq put them (/usr/sbin). SO in this case we want to overwrite the dnsmasq binary in /usr/sbin. To do this we need to update the prefix variable in the Makefile (compiler instruction file)
- Since we know where dnsmasq is now, lets go and update the Makefile to reflect the location where we dnsmasq installed
- Search for this line and change
- Save and exit out of the Makefile
- Lets backup the original dnsmasq executable just in case...
- Ok here's where we create and install the latest version of dnsmasq
- Once the install is done lets ensure that the right version of dnsmasq is found first in the search path.
- Key in the following
- Ensure the version displays 2.76 if so you are all set
- The last and final step is to ensure that the application runs when the service is called.
- If the service starts correctly (no errors) then you're done.
- If you question if dnsmasq is running the proper version you can always inspect /var/log/syslog for any dnsmasq error messages.
sudo apt-get update sudo apt-get install build-essential sudo apt-get install -y wget libdbus-1-dev libnetfilter-conntrack-dev idn libidn11-dev nettle-dev libval-dev dnssec-tools
wget http://www.thekelleys.org.uk/dnsmasq/dnsmasq-2.76.tar.gz
tar -zxf dnsmasq-2.76.tar.gz
cd dnsmasq-2.76
sudo vi src/config.h
/* #define HAVE_LUASCRIPT */ /* #define HAVE_DBUS */ /* #define HAVE_IDN */ /* #define HAVE_CONNTRACK */ /* #define HAVE_DNSSEC */
#define HAVE_DBUS #define HAVE_IDN #define HAVE_IDN_STATIC #define HAVE_CONNTRACK #define HAVE_DNSSEC
which dnsmasq
# which dnsmasq /usr/sbin/dnsmasq
sudo vi Makefile
PREFIX = /usr/local # To this PREFIX = /usr
sudo cp /usr/sbin/dnsmasq /usr/sbin/dnsmasq.old
sudo make install
At this point the compiler will dig through the source code and compile the dnsmasq program. Hopefully it will compile and install without errors.
dnsmasq -v The output should look like this:
Dnsmasq version 2.76 Copyright (c) 2000-2016 Simon Kelley Compile time options: IPv6 GNU-getopt DBus no-i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth 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.
sudo service dnsmasq restart
Advanced dnsmasq techniques
Reference: https://forums.fogproject.org/topic/8726/advanced-dnsmasq-techniques
Introduction
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
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.
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
# 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
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.
Match filter troubles
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.
