• Recent
    • Unsolved
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Register
    • Login

    Advanced dnsmasq techniques

    Scheduled Pinned Locked Moved
    Tutorials
    2
    9
    9.1k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • george1421G
      george1421 Moderator
      last edited by 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
      

      Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!

      1 Reply Last reply Reply Quote 2
      • george1421G
        george1421 Moderator
        last edited by 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.

        Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!

        1 Reply Last reply Reply Quote 0
        • george1421G
          george1421 Moderator
          last edited by 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.

          Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!

          1 Reply Last reply Reply Quote 0
          • george1421G
            george1421 Moderator
            last edited by 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.

            Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!

            1 Reply Last reply Reply Quote 0
            • george1421G
              george1421 Moderator
              last edited by 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
              

              Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!

              1 Reply Last reply Reply Quote 0
              • george1421G
                george1421 Moderator
                last edited by 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).

                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…

                Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!

                1 Reply Last reply Reply Quote 0
                • Wayne WorkmanW
                  Wayne Workman
                  last edited by Wayne Workman

                  wiki worthy

                  Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!
                  Daily Clean Installation Results:
                  https://fogtesting.fogproject.us/
                  FOG Reporting:
                  https://fog-external-reporting-results.fogproject.us/

                  george1421G 1 Reply Last reply Reply Quote 1
                  • george1421G
                    george1421 Moderator @Wayne Workman
                    last edited by Wayne Workman

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

                    Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!

                    1 Reply Last reply Reply Quote 0
                    • Wayne WorkmanW
                      Wayne Workman
                      last edited by

                      This has been added to the wiki here:
                      Link

                      Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!
                      Daily Clean Installation Results:
                      https://fogtesting.fogproject.us/
                      FOG Reporting:
                      https://fog-external-reporting-results.fogproject.us/

                      1 Reply Last reply Reply Quote 0
                      • 1 / 1
                      • First post
                        Last post

                      201

                      Online

                      12.0k

                      Users

                      17.3k

                      Topics

                      155.2k

                      Posts
                      Copyright © 2012-2024 FOG Project