Coexistence of UEFI and Legacy - Troubleshooting help

[george1421]

@taspharel Well to fully understand what is going on using the fog server or wireshark you can capture the dhcp pxe booting process: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

The above works best if you have the fog server, pxe client and dhcp server on the same subnet. I would put your dhcp policy back in place as they are listed in the wiki. I’d be interested in what the client is sending in the dhcp discover packet as well as the response from the dhcp server.

If you are not familiar with reviewing a pcap file, upload it to a google drive and post the link here or send me an IM and I will look it over.

[Wayne Workman]

@taspharel We absolutely need a short packet capture as George said. Did the old DHCP servers get decommissioned?

[Wayne Workman]

@george1421 As often as we review PCAP files - I wonder if it would make sense to just write a tool that does the same things… like identifying all DHCP servers, identifying information about all DHCP discovery packets, identifying what DHCP server answered, what options it provided.

[george1421]

@wayne-workman Ideally that would be the best solution. Practically it would be pretty tough to program because some times the dhcp server and pxe client do different things. There is not a clear cut way to pxe boot. Sometimes the dhcp server will reply with the next server in the header, and the boot file in dhcp option 67 instead of the boot file in the header. Yes you could code for that, with a skilled tech you can look at the pcap file and understand what is going on pretty quickly even with the variations. I know that we do get a lot of tickets over pxe booting not specifically related to FOG, but more about the environment the FOG Admin is trying to pxe boot in.

I guess in the end I don’t know if it would be a useful tool or not.

[Taspharel]

@george1421 The pcap files are here:
https://drive.google.com/drive/folders/0B_yYSiicYNIAMmNKaGoyOG0wd0k?usp=sharing

issue1 is from the boot attempt of a UEFI only Lenovo X270 machine (internal name is NBW10070 (or the old one would have been NBW7070) that doesnt boot via LAN in the settings we got.

issue2 is from a desktop (WSW10074, or old: WSW7074) that successfully boots with the settings we have atm.

Settings are: According to wiki with undionly.kpxe set as Option 67 without Vendor Classes. IP Adresses for the new DC servers end with .2 and .3

@Wayne-Workman The old servers have been decomissioned yes.

[george1421]

@taspharel

Issue 1: This looks like a normal dhcp / pxe boot process (as in the flow). There is only one dhcp server involved here [192.168.43.3]. Its saying the boot server is 192.168.43.17. Its passing undionly.kpxe to the target computer. The target computer downloads this file from the tftp server and halts. The issue I see here is that your dhcp server is passing undionly.kpxe to a computer that has identified itself as a uefi BC arch 0007 type. It appears your filters on your dhcp server is not honoring the client request.

Issue 2. This computer is talking with 192.168.43.2 (Different than issue 1!!). The client is identifying itself as a bios (legacy) PC. 192.168.43.2 is saying the boot server is 192.168.43.17 with a boot file of undionly.kpxe This client appears to be a microsoft VM(??) later on I see that it loads default.ipxe so this one appears to be working.

So now it appears you have 2 AD DCs, each are providing dhcp information. with only 2 samples it hard to say they are setup correctly. It appears the bios systems are booting OK, its just the uefi systems. The systems are properly reporting itself. The dhcp server is not honoring this.

So now we need to identify a few things.

1. What is your dhcp server OS, is it 2012 or newer?
2. What wiki page are you referring to
3. Do you have both dhcp servers configured the same.

If you have both dhcp servers setup the same, you need to inspect your rules to ensure arch 0007 and arch 0009 are being setup correctly.

[Taspharel]

Okay, thanks.

So, We have two DHCP Servers, one gets its settings from the other per replication. So both should have the identical settings.

I’m refering to: https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence

Our new DCs are Windows Server 2016.

Screenshots from my dhcp server settings are in the same folder as before, the details for the other vendor classes are the same.

I added Policies with a * in front of the vendor class because i hoped that would change something, it didnt work without those either though.

[Taspharel]

I am so so so sorry.

Just came out of a call with our external IT partner and casually he said: Oh btw.: I deactivated your Policies on the DHCP server.

And I didn’t notice of course … so sorry for wasting time, it works now.

[george1421]

@taspharel No worries, its always good to know that neither of us are insane where you know what should be and we found what is according to wireshark.

I assume they will reenable your policies? You kind of need them to support dynamic booting. Well that’s not totally true, if you can’t have the policies in your MS dhcp server you can run an external proxy dhcp to supply the missing pxe boot information. The point is there are other ways to achieve what you need.

Can we close this issue?

[Taspharel]

Already enabled and works like a charm.

Can be closed, thx for helping out.