Updated Fog server now have to manually enter tftp server address

[george1421]

This still tells me that something is wrong with your dhcp option 66 settings or you have 2 dhcp servers responding with conflicting information.

<edit> Probably the next step is to capture a pcap of the pxe booting process as long as the fog server and pxe booting client are on the same subnet (vlan) for this test. Follow these instructions and upload the pcap here for review: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

[pkt]

They are on different subnets, are there instructions for the wire-shark capture?

[pkt]

There are 2 Windows DHCP Servers but they are working in high availability so all settings are the same. option 66 is pointed at the fog server and 67 is undionly.kpxe

[george1421]

@pkt wireshark from the same subnet as the pxe booting computer will work. We currently don’t have instructions for wireshark since the fog server will tell us a bit more of what is going on post dhcp setup. If I get a chance this afternoon I’ll do something quick to get you going, but the ports we want to monitor will be the same for wireshark. If you have used it before you should be able to create a filter in wireshark to make what we are grabbing with tcpdump.

[Wayne Workman]

@george1421 The TFTP Troubleshooting guide has steps on how to take a capture with TCPDump and examine it with wireshark:
https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_TFTP#Troubleshooting
There’s also just the straight TCPDump article:
https://wiki.fogproject.org/wiki/index.php?title=TCPDump

[alh]

We had a similar effect when using PXE chaining. I believe the issue occurs when undionly.kpxe hands over to the “normal” FOG boot image. So the DHCP server initially hands out the correct boot image and the client is instructed by “undionly.kpxe” to boot “http://IPofFOGserver/fog/service/ipxe/boot.php?mac=${net0/mac}”. But then DHCP sends again “undionly.kpxe” as boot image and you have your conflict.

We solved it by compiling undionly.kpxe ourselves which is really easy. After downloading the source create a file, e. g. fog.ipxe with the following content:

#!ipxe

dhcp
chain http://IPofFOGserver/fog/service/ipxe/boot.php?mac=${net0/mac}

Then you need to compile the file like this: make bin/undionly.kpxe EMBED=fog.ipxe.

That makes sure that the DHCP parameters regarding boot image are ignored. Works perfectly for us and we got rid of entering the IP manually.

[alh]

Actually when looking at the source of ipxescript it doesn’t prompt conflicting information but when the option next-server (for whatever reason) is not set:

:nextservercheck
isset ${proxydhcp/next-server} && set next-server ${proxydhcp/next-server} ||
isset ${next-server} && goto netboot || goto setserv

:setserv
echo -n Please enter tftp server: && read next-server && goto netboot || goto setserv

To me it is not clear why at this stage (after we booted from the undionly.kpxe and therefore already found our desired boot server) one does not simply hard-code the IP of the FOG server here during installation?

https://svn.code.sf.net/p/freeghost/code/trunk/src/ipxe/src/ipxescript

[george1421]

@alh Thanks for the great info. At this point I still think its valuable to grab a pcap of the pxe boot process to see what is actually being sent to the target computer. It may be something simple, or something a bit more complex where your solution would work. At this point we don’t know for sure.

[alh]

Maybe also this link helps in setting up MS DHCP correctly:

ipxe.org/howto/msdhcp

[Sebastian Roth]

@alh said:

To me it is not clear why at this stage (after we booted from the undionly.kpxe and therefore already found our desired boot server) one does not simply hard-code the IP of the FOG server here during installation?

The iPXE binaries are not being compiled on installation time but provided as binary. Therefore we can’t just hard-code the FOG server IP.