Has something changed with UEFI?
-
@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.
