[AD] DHCP server; workaround for line 060 (PXEClient)
-
Server
- FOG Version: 1.3.4
- OS: CentOS 7
Client
- Service Version:
- OS: Windows 7 Professional x64 SP1
Description
Good day guys,
first, thank you for your previous help with my previous topic.Now, to the new issue.
As you know, now my FOG service is running properly, FOG server is properly configured (though I didn’t managed to configure VNC server yet; but that’s OT). So what’s left to do is to configure DHCP server.In my case, FOG server is not handling the job of DHCP server; that one runs on Active Directory Domain Controller - Windows Server 2012 R2. I’ve succesfully configured lines 66 and 67 as per wiki guide, but for FOG to work properly, I have to disable line 60 (PXEClient), or test computer just won’t boot over PXE. The question is; is there a possible workaround for FOG to work properly even with line 60 enabled? Seems like I can’t just disable this line, either because of zero clients (we have two schoolrooms with these) or WDS server; one of these two does require this setting to be enabled.
Any ideas?
Thank you.
-
Good day,
issue is solved; line 060 was being used by WDS server, which is inactive for some time and we do not use it anyway. It was agreed to disable this line and so FOG server is already running smoothly - 40 GB test image deployed on testing PC within 3 minutes. AWESOME! Plus I’ve managed to integrate few utilities such as Clonezilla, Clonezilla Server Edition (or DRBL live), System Rescue CD, PMagic, GParted and AVG Rescue CD.Will come back with other questions; thanks so far!
-
When I got FOG working, I no longer needed WDS.
Others here have figured out how to get WDS & FOG to co-exist, but it’s not worth the effort or complexities in my opinion. fog replaces WDS, is simpler to use, and is faster.
Related threads:
https://forums.fogproject.org/topic/1955/pxe-boot-chainloading-to-wds
https://forums.fogproject.org/topic/3570/using-fog-adv-menu-to-chainload-wds
https://forums.fogproject.org/topic/4830/wds-and-fog?page=1 -
It would be interesting to know what is going down the wire when you have dhcp option 60 set vs when you have it disabled in regards to fog.
If you could refresh my memory, you are not running the dhcp server on FOG, and/or dnsmasq on your fog server, right?
If your fog server, dhcp server, and pxe booting target computers are on the same subnet I’d like to see a packet capture with option 60 set and with it removed to see what fog/the client computers are doing different.
If you can meet the above requirements and are willing to do a little packet trace for us let me know and I’ll post the instructions.
One last question, is your dhcp server running on windows 2012 or newer?
-
@Wayne-Workman If option 060 is enabled just only for WDS server, then I guess it would not hurt to have it removed - currently, WDS does not even work since there are some network issues and there is still some server migration underway. So if only WDS is in the way, then there is - probably - no problem. But, if zero clients are at fault … well, that is entirely different issue. Thank you for provided threads, I will look them over.
@george1421 Well, I am willing to cooperate - tomorrow is Sunday, so there should not be any classes; which means that I can fiddle with network little bit, so if you have specific instructions, fire away and I’ll give you feedback.
As far as refreshing your memory; you’re right, FOG server does not run DHCP server nor dnsmasq. FOG, DHCP and PXE test-booting machine should be on the same subnet (I suppose it would not work otherwise with option 060 disabled) and they are assigned in the same VLAN (except with DHCP server; if I understand it well enough, it provides DHCP services for all our VLANs).
And DHCP server is running on Windows Server 2012 R2.
-
Well this is going to be a pretty low impact test. We just want to capture a packet trace with dhcp option 60 removed and one with it enabled. This should tell us what is going sideways during pxe boot.
First a little background. The DHCP protocol is broadcast based. That means that discovery, offer, request and ack are all sent as broadcast messages (because the client doesn’t have an IP address during this process). Knowing this fact we can eavesdrop on the communication between the dhcp server and pxe client with the FOG server as long as all three are in the same broadcast domain, subnet, vlan, etc.
So what I want you to do, is ensure that all three (if you can’t get all three, get the pxe client and fog server in the same broadcast domain). Then install the tcpdump on your fog server since you’re useing centos/rhel its
yum install tcpdump
. Once that is done we can start the testing protocol. One thing you should do is keep the time when you start tcpdump and start the pxe boot process on the client as short as possible. Because if you have a busy dhcp network we may key in on the wrong dhcp boot. So you want to start tcpdump and then right away start the target pxe booting.OK now to the protocol.
- With DHCP option 60 set.
- Start tcpdump on the FOG server’s linux console with this command
tcpdump -w test1.pcap port 67 or port 68 or port 69 or port 4011
Just a quick sidebar: We are telling tcpdump to write the output of the packet capture to test1.pcap. And we have setup some filters because we only care about dhcp (port 67 and 68), tftp (port 69), and dhcpProxy (4011, but it doesn’t apply here since we are not using dnsmasq). - PXE boot the target computer until you see the error or the FOG iPXE menu.
- Wait about 5 seconds then hit ctrl-C on the FOG server’s linux console.
- Now remove the DHCP option 60.
- Start tcpdump on the FOG server’s linux console with this command
tcpdump -w test2.pcap port 67 or port 68 or port 69 or port 4011
- PXE boot the same target computer until you see the error or the FOG iPXE menu.
- Wait about 5 seconds then hit Ctrl-C on the FoG server linux console.
- Upload both test1 and test2 pcaps here.
If you want to review these two pcap with wireshark be my guest. You should see the dhcp process in the data section of wireshark. You should see the client sending out a discovery request, the dhcp server sending an offer announcement, the client sending a request for the things it needs and ack coming back from the dhcp server saying here’s your settings.
-
@george1421 Thank you. I will get to it a little bit later, once the usually heavy “morning traffic” calms down. Before that however, I have one - probably little bit silly - question; path for the saved output log of tcpdump will be shown in console, or is there a specific path to it? And in case of the latter option, where would I find it?
Thank you.
-
@HaRD The saved path will be the current directory. You should use the root user to run this command. Just login and key in (or use putty to login) and paste the command as I provided. The output file will be saved in the root user’s home directory.
-
I should have explained what I said, why I said it. WDS uses DHCP option 60 (among other things), and that doesn’t work with fog, it prevents it from working. When you install the WDS roll, and your DHCP is a domain controller in WDS’s domain, it automatically adjusts DHCP option 60. This option can just be disabled if WDS doesn’t work anyways.
-
Good day,
issue is solved; line 060 was being used by WDS server, which is inactive for some time and we do not use it anyway. It was agreed to disable this line and so FOG server is already running smoothly - 40 GB test image deployed on testing PC within 3 minutes. AWESOME! Plus I’ve managed to integrate few utilities such as Clonezilla, Clonezilla Server Edition (or DRBL live), System Rescue CD, PMagic, GParted and AVG Rescue CD.Will come back with other questions; thanks so far!