Can't boot to PXE

[Sebastian Roth]

This is an interesting one again! I don’t see any DHCP server offering an IP address to the client!! WHAT?? It does do a kind of normal DHCP DORA (Discover, Offer, Request, Ack). But without ever handing IP information to the client (always 0.0.0.0 as if it is configured to be a DHCP Proxy server). It only sends next-server (option 66) to the client.

But I doubt this is really the case because a little later on I see the client (same MAC address and now IP 192.168.1.59) asking a different server (192.168.1.6) on port 4011. Please tell us which is which in your network and who should be handing out which information? Do we see all the DHCP traffic in this pcap file?

[roee]

@Sebastian-Roth

My DHCP server is the 192.168.1.6.
It has option 66 with string 192.168.1.14 which is the Fog server.
192.168.1.59 is the IP address assigned to the client which was trying to boot to PXE.
This pcpap file recorded all my DC (which is also my DHCP server) traffic during the boot of the client machine.
Option 67 is also enabled with parameter undionly.kpxe which I don’t really know what to do with it.

Thanks

[roee]

Thanks for the interest you’re taking in this.
I will try to answer all questions.
I don’t have any other PXE service in my network. I did try Acronis but removed it completely along with all components and all dns/dhcp related records. Wjen I tried Acronis I had the same issue, and before I tried the Acronis this DC (DHCP server) was installed fresh.
The client machine is a laptop Dell E7440, boot order is NIC first, when fails it holds until a key is pressed to continue to boot from HDD.
WOL settings were disabled, but I did another boot attempt using the LAN only - same result.
I think the issue is that option 66/67 are ignored and port 4011 is still being used rather then UDP.
DHCP server is 192.168.1.6, client receives 192.168.1.59. FOG servers is 192.168.1.14.

Thanks again!

[Sebastian Roth]

In that PCAP file we don’t see your DHCP (192.168.1.6) answering any of the DHCP queries! We only see 192.168.1.83 answering. Please see what/who is 192.168.1.83!

Looking through the packet dump file again with the new information you gave: I don’t see DHCP replys from 192.168.1.6! Definitely something missing in the dump?! Did you capture traffic right on that machine?

[george1421]

@Sebastian-Roth said:

Definitely something missing in the dump?! Did you capture traffic right on that machine?

@roee Be sure your pcap device (wireshark ??) is attached to a mirrored port that is mirroring the information from the target computer. This will ensure you capture all dhcp traffic.

[roee]

The FOG server is installed as a VM hosted on a Windows 7 VMware workstation 12.
IP of the Windows 7 machine is 192.168.1.83.
VM Lan card is set to bridge, I made sure it has comm with dhcp, dns, client and www.

Does that shed some light?

[Wayne Workman]

@Wayne-Workman said:

@george1421 said:

what is the IP address of the dhcp server listed?

192.168.1.83

Are you running DHCP on your windows 7 machine?

[roee]

@Wayne-Workman

Definitely not. The Windows 7 is the host of the fog server VM.
DHCP is on a dedicated Windows 2008R2 server Dell R620.

[Wayne Workman]

@roee I ask because in the packet capture you posted, I’m seeing several DHCP offers from 192.168.1.83. This doesn’t necessarilly mean you’re running DHCP on the windows 7 machine, but it could mean that your Fog server’s NIC is not bridged, but might instead be NAT’d.

Looking further at it, I see there are several DHCP Requests to 192.168.1.6

But why is your Windows 7 machine offering DHCP ?
And still, among none of these requests and offers do I see options 66 and 67 set.

Have you looked at our WiKi page on this?
https://wiki.fogproject.org/wiki/index.php?title=Modifying_existing_DHCP_server_to_work_with_FOG

[george1421]

@roee just be aware that there IS a dhcp server inside vmware workstation. It should only be for the internal host only networks. Make sure this isn’t configured incorrectly.

[Wayne Workman]

@george1421 said:

just be aware that there IS a dhcp server inside vmware workstation.

Had no idea.

[roee]

@Wayne-Workman

I couldn’t find on VMWare workstation anywhere a DHCP settings, or anything else that might use as DHCP of some sort.
The NIC is set to bridge for sure. see attached file.

[george1421]

@roee I have vm workstation 11 and the setting is under the edit menu Edit->Virtual Network Editor…

As long as the dhcp server is not bridged to the physical adapter you should be all right. In my case I just made sure the vmnetX logical adapters weren’t bound to the physical network adapter. There should be isolation so your PC should not respond to dhcp requests.

It may be doing something with dhcp and the nat service, but again this is abnormal.

[Sebastian Roth]

Do you have “VMware DHCP Service” in your windows service listing (Administrative Tools…)? Maybe try stopping this service and see if you still get those DHCP packets from 192.168.1.83…

[george1421]

@Sebastian-Roth said:

Do you have “VMware DHCP Service” in your windows service listing (Administrative Tools…)? Maybe try stopping this service and see if you still get those DHCP packets from 192.168.1.83…

Great point, I have that service disabled on my workstation. I didn’t want any crosstalk.

[roee]

Hey guys!

Any other ideas or notions or should I just abandon FOG?

Thanks

[Sebastian Roth]

@roee Have you disabled VMware DHCP service? Any changes? If I don’t have a proper PCAP file with all the DHCP packets I can just guess at what is going on in the network. This is like trying to catch a fish with bare hands but having my eyes shut (just joking!).

As you already said - same problem with Acronis PXE. This has nothing to do with FOG itself. Using Windows DHCP server is fine (others have got it working perfectly) but this is nothing we can do with an installer script or something. We are more than happy to give advice and help to get this fixed but we need information to do that. Provide a full PCAP file (best if using a monitoring port or hub on the client side), post screenshots of your DHCP server settings.

Full PXE spec you can find here: ftp://download.intel.com/design/archives/wfm/downloads/pxespec.pdf (looks a bit overwhelming on first sight but it’s definitely a good source to understand how all this works - including port 4011 thing)
Something interesting I just found in the spec (page 17/PDF page 19) is that it also talks about DHCP option 43. @Wayne-Workman You know a lot more about windows DHCP than I do. Have you ever used option 43? Hopyfully we see screenshots of the DHCP settings and you can have a look.

[Jaymes Driver]

@roee

You can always give DNSMASQ a shot, it usually helps to resolve issues when the files are not being delivered to the clients.

It works as a proxy DHCP server and only offer ip addresses to the machines looking to pxe boot. And helps the clients to resolve to your FOG Server.

I would recommend installing DNSMASQ and using the settings from the wiki to see if that alleviates any of the issues you are experiencing.

I had to use this in my environment when we were Novell and when we switched to Active Directory. I also still left options 66 & 67 set to the fog server and the boot file respectively.

https://wiki.fogproject.org/wiki/index.php/Using_FOG_with_an_unmodifiable_DHCP_server/_Using_FOG_with_no_DHCP_server#DNSMASQ_settings_for_iPXE

[george1421]

@Jaymes-Driver What we haven’t been able to clearly identify is of there is currently a proxy DHCP server setup. So adding a second one would only confuse the issue. Under normal conditions most dhcp servers should not bind to port 4011 or even try to use it.

At the heart of the issue this is not a FOG problem, but one with the OP’s environment. I’m suspecting some legacy code running from some previous imaging environment like (RIS, WDS, or a commercial product). But that is only speculation without a clean and complete pcap file.

[Wayne Workman]

@Sebastian-Roth DHCP Option 043 looks like this on Server 2012

Here’s the rest of that option’s text:

You can type in the binary or ASCII fields as you can with the other windows DHCP options.

I’m not using this option though.