Has something changed with UEFI?
-
So after looking over this thread, I have to ask the question, why are you using dnsmasq? What dhcp server do you have? Is it restricted so you can’t make changes?
-
That makes perfect sense, so this is setup how it should be. dnsmasq starts, reads the commented file, and then moves on to ltsp.conf, where we have defined all of our settings.
I just tried with snponly.efi, and ipxe.efi and neither of them are loading up.
Here is a screen grab from a video I took of the process.
And here is the screen it immediately jumps to.
-
Also, I want to point out some stuff with dnsmasq that has tripped me up before.
Firstly, it uses WHAT-EVER it finds inside
/etc/dnsmasq.dDoesn’t matter what it’s named. ltsp.conf, ltsp.conf.old, MyXmasWishList.txt - it does not care. If you have backup configurations in there, move them somewhere else.
Maybe that issue is resolved in the newer version, I don’t know.
Second - when dnsmasq sends out it’s ProxyDHCP - it appends
.0to thefilenameit gives. You could do some complex stuff with symbolic links, but I prefer not to. I prefer to copy the file I want to use. In your case, let’s go with ipxe.efi. You’d copy that like so:cp /tftpboot/ipxe.efi /tftpboot/ipxe.efi.0 -
@george1421 We use an Infoblox appliance that is controlled by the main campus of our university. We have some control over it, such as adding in the DHCP options, but not much else.
-
@svalding said in Has something changed with UEFI?:
@george1421 We use an Infoblox appliance that is controlled by the main campus of our university. We have some control over it, such as adding in the DHCP options, but not much else.
OK understood. I just wanted to make sure we are going down this path for the right reasons.
I forgot about the part that Wayne mentioned (the weird behavior of dnsmasq with adding .0 to the file name). As a test you can do the copy thing, but I would create a symbolic link instead. That way if/when you update FOG you won’t have an old (static) copy of ipxe.efi causing issues.
-
Sure thing. My brain is fried for the day. I’m going to pick this up tomorrow morning. Hopefully the network guy is in the office at main campus and I can work with him on getting some tcp dumps from the traffic for this dhcp offer/ack process.
Also I am going to try to setup port mirroring on the switch this machine is plugged into and do a wireshark there. I’ll get to the bottom of it!
I appreciate all you gentleman’s help today. It’s been quite a learning curve having to pick this up while the guy who usually handles it is out.
-
@svalding If you have some skills you can do the packet capture right from the fog server.
If you install tcpdump on your fog server you can capture what you need with.
tcpdump -w output.pcap port 67 or port 68 or port 69Start the capture then boot the pxe target, keep recording until the pxe client errors out then stop the capture. If the dhcp server, fog server and target computer are in the same subnet the fog server will hear everything since dhcp communications are broadcast based. Just take the pcap file and load it into wireshark to review it. If you have questions then post the pcap file to the forum so the devs can take a look at it. The answers will be in the pcap what is really going on.
-
Here’s the PCAP file. It looks like TFTP is trying to give it undionly.kpxe, which isn’t right!
-
I"m going to do another capture against a mirrored port. The machine and the fog server are on separate VLANs, so i’m not sure I’m grabbing all the packet data that I can get if I were to mirror the port on the switch. I’ll post that information as well once I have it.
-
@svalding Just for clarity the fog server is not in the same broadcast domain (vlan) as the target computer or the dhcp server?
-
Correct. That’s why I want to do a port mirror and packet capture. I’m not seeing all of the information from a tcpdump on the fog server itself.
-
@svalding said in Has something changed with UEFI?:
Correct. That’s why I want to do a port mirror and packet capture. I’m not seeing all of the information from a tcpdump on the fog server itself.
OK that is what I wanted to confirm. Since you are doing a proxyDHCP setup and the system running the proxyDHCP are in a different broadcast domain as the target, it will never hear the dhcp request of the target computer.
Since your dhcp server is in a different broadcast domain (subnet) than your target computer you are probably using a dhcp-relay or dhcp-helper service on your router that sits between the vlans. Typically in this setup you would add the proxyDHCP server as the last host in the list of dhcp servers in the dhcp-relay service. You still want your main/primary dhcp server listed first in the relay, but by adding the server running the proxyDHCP service to the list (last) the proxyDHCP server will be aware of the dhcp request and reply its info too. Its a bit complicated, but that is how you have your network setup.
-
Can confirm, our network is setup in the most steaming pile of socks way you can think of. But, it’s a big university with lots of moving parts, complexity is to be expected.
Mod edited.
-
HOLD! THE! PHONE!
I just found a section in our infoblox called “FIle Distribution” What’s inside that you ask? all these freaking .kpxe, .pxe, and .efi files.
What the blubber. I’m going to upload a new copy of snponly.efi and give this machine a boot again. UGH!
Mod edited.
-
@svalding just for clarity you infoblox is also using iPXE boot kernels?
-
That’s a good question. I just discovered that these were all on here, and the timestamps on the upload match when we were mucking about getting Surface Pro 3’s to boot pxe with their UEFI. So I took a chance and uploaded the files to the infoblox. Didn’t change anything for me though. Still just getting a succeeded to download NBP file and then the retry screen.
-
@svalding Something that has bugged me (from the beginning) is where is refind.efi coming onto play? You should only use that as an exit mode from uefi mode if everything else fails to work. You should not see that as a boot processor.
I think you are right you need to setup a mirrored port for that target system and capture all traffic for udp ports 67, 68, and 69 (that will capture dhcp and tftp requests). We really need to understand the actors here and what the target is really being told.
-
at this point, I believe that to be an anomaly on our network. We reimaged the machine this morning that was throwing that boot menu and it has been working perfectly.
I’m still working on the port mirroring thing.
-
Guys. It’s working! I was able to get some local help from our team, and we found the issue in the infoblox. We had to make some changes for BOOTP on this particular VLAN, and move away from snponly to ipxe.efi. After I restarted services on the Infoblox appliance, this test machine booted pxe and fog!
Such a relief, and you’ll be glad to know it wasn’t anything inherently wrong on the fog side of things, just needed to adjust some settings on the infoblox appliance and we are good to go!
Again, I can’t thank you all enough for all your help. You’ve been amazing. I love this project.
-
@svalding Hey that’s great you have it going now. Don’t forget to disable dnsmasq you started setting up. It will cause you some pain/confusion if its left running and you don’t need it.
