Serve different types of .efi boot files
-
Server
- FOG Version: RC-13
- OS: Ubuntu 16.04
Client
- Service Version: 11.5
- OS: windows / Ubuntu / mint fedora / centos
Description
Ok so with the help of @george1421 I was able to get a successful working tftp boot server working using dnsmasq ver 2.76. even though I have a ddwrt router I cut off the dnsmasq on it cause now my fogserver acts as both.
But this is not my new issue. my new issue is this. I can boot both uefi and bios/legacy systems however. I don’t know how to add certain types of architectures to the ltsp.conf file.
For example. I have a couple of machines that only will complete boot if I serve it the intel1756.efi file. but I don’t know how to add it in addition to the architectures it already has. so when a file is served I only get the ipxe.efi file.
I used wireshark to see what architecture the machine states it is and it states
PXEClient:Arch:00007:UNDI:003016ipxe.efi will not complete the boot but intel7156.efi does. anyways here is my ltsp.conf
# 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=IA32_UEFI,PXEClient:Arch:00006 dhcp-vendorclass=BC_UEFI,PXEClient:Arch:00007 dhcp-vendorclass=X86-64_EFI,PXEClient:Arch:00009 # The default boot filename, Server name, Server Ip Address dhcp-boot=undionly.kpxe,,192.168.1.109 # Set the boot file name based on the matching tag from the vendor class (above) dhcp-boot=net:IA32_UEFI,i386-efi/ipxe.efi,,192.168.1.109 dhcp-boot=net:BC_UEFI,ipxe.efi,,192.168.1.109 dhcp-boot=net:X86-64_EFI,ipxe.efi,,192.168.1.109 # 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.1.109,proxy -
Take a look here: https://forums.fogproject.org/topic/8726/advanced-dnsmasq-techniques
There is nothing else in that dhcp option that is unique other than the arch. The undi 003 016 just defines the version number of undi the client is using. If you want something unique per client look at dhcp option 97 of the dhcp request.
-
@george1421 I’ve looked at what you have written and your tutorial 4 specific Hardware but I still remain. Confused
-
@dureal99d Oh man, I spent 4 hours writing that and its still confusing?
Actually it is a hard subject to master.
Basically what you need is a new match test.
I want you to go look at any of the pcaps you took yesterday and in the initial “hello I’m here” (probably frame 1 or 2) from the target computer to the world, look at the options, specifically option #97 and post the answer here.
-
@dureal99d It might help to look at this, it’s a collection of george’s posts about dnsmasq basically, but links to other resources as well.
https://wiki.fogproject.org/wiki/index.php?title=ProxyDHCP_with_dnsmasq
-
@george1421 thats weird it says
00000000-0000-0000-0000-000000000000 -
@dureal99d Well that is a unique pattern too. But I would expect something like 44454c4c45440-038-3610-804ec4-c04f4a5831 the numbers are not important just the uniqueness of the UUID field.
Did that uuid (dhcp option 97) come from a vm or a real computer?
-
@george1421 real computer a Samsung np300e5c
-
@dureal99d nuts, can you try another?
You can capture this with wireshark on a computer and not have to go the tcpdump route and then copy the file, etc. Any computer on the same subnet as the booting computer can detect these broadcast messages if you are running wireshark.
-
@george1421 said in Serve different types of .efi boot files:
can capture this with wireshark on a computer
sure
-
@george1421 wire shark capture. here ip address 192.168.1.121
-
@george1421 tcdump here of another machine Asus R503U
-
@dureal99d well on the first one I didn’t see any systems that transmitted their uuid in dhcp option 97. That sux a bit.
You might also want to learn about capture filters in wireshark. They are similar to the capture filters for tcpdump.
‘udp.port == 67 or udp.port == 68 or udp.port == 69 or udp.port == 4011’ this one is equiv to the tcpdump one we were using. Let me look at the ASUS computer.
-
@george1421 said in Serve different types of .efi boot files:
might also want to learn about capture filters in wireshark
for asus 00000011-0000-0000-0000-50465d986f3c / udp.port == 68
-
@dureal99d The asus one has something we can work with. That dhcp option 97 is ‘00000011-0000-0000-0000-50465d986f3c’
I can tell you if you boot this computer in bios mode (just for this test) you will probably see this listed on the initial pxe boot screen as GUID.
This number should also be visible in the /var/log/syslog or where ever dnsmasq is writing its log. In my testing the value from wireshark did not match up exactly with what was found in the dnsmasq log. You need the value that looks similar from the dnsmasq log. But with that information we can take the next step to create a match test.
-
@dureal99d said in Serve different types of .efi boot files:
@george1421 said in Serve different types of .efi boot files:
might also want to learn about capture filters in wireshark
for asus 00000011-0000-0000-0000-50465d986f3c / udp.port == 68
Bonus points for you!!
-
-
@dureal99d Which computer needs the special kernel the ASUS or Lenovo?
-
@george1421 they both like that intel1756.efi kernel
-
@dureal99d Like it enough to make that your default kernel and then the ones that don’t like it you make exceptions for? Use the 80/20 rule what do you have the most of on your campus and then make that your default kernel and the others be the exception.
