Unable to configure DHCP in Ubuntu for PXE boot Win10
-
@george1421 Thank you for the response. I figured I was assigning a wrong subnet. Now my isc-dhcp server is all set and running. I have also checked your shared link and added those settings to my dhcpd.conf file. It’s all fine now.
However, I am still getting the same error at windows while i try to pxe boot into it, you can notice the filename and next-server here
Thanks again!
-
@itachi_19 said in Unable to configure DHCP in Ubuntu for PXE boot Win10:
error at windows while i try to pxe boot into it, you can notice the filename and next-server here
There is something unexpected going on here. I have an idea what is going on but we need proof.
What I want you to do is follow the instructions here to capture a pxe boot from the FOG server point of view. Make sure the target computer you pxe boot is on the same subnet as the fog server. https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue
You can either upload the pcap to a file share site and post the link here or look at the pcap with wireshark. What you should see is a DISCOVER packet from the pxe booting computer then one or more OFFER packets. The OFFER packets come from dhcp servers that hear the DISCOVER packet. The only one responding should be from the IP address of your FOG server. I’m suspecting you have a rouge dhcp server on this network.
-
@itachi_19 In the iPXE picture we see
Windows 10.pxe. Where is that coming from? Another DHCP server in your network? -
@sebastian-roth I don’t get this part either as there is no other dhcp server. I have hardly configured this one. And this windows machine also has the same ip address as of my Ubuntu machine on which the fog server is running.
-
@itachi_19 Lets get that pcap so we can see what the target computer is being told. It wouldn’t be the first time we found a rouge dhcp server causing problems.
-
@george1421 Thank you for the guidance. I am working on it, will get back to you shortly.
-
@george1421 I manually set a static ip address for my windows machine. Now the settings are ip: 10.02.16, subnet mask: 255.255.255.0, and the defualt gateway is 10.0.2.2.
I am using following tshark command to capture the packets before network boot the windows machine.
tshark -i enp0s3 -f “port 67 or port 68 or port 69 or port 4011” -w /tmp/dhcp.pcap
and the .pcap file is empty.
Even before changing from assigning IP address automatically to static the result was the same.
-
@itachi_19 Why don’t you use the
tcpdumpcommand provided by George? If the pcap stays empty with that as well then the machine is not PXE booting I would say! -
@sebastian-roth Tried tcpdump just now, still empty!
-
@itachi_19 You set the static IP on what device? Is it on the same subnet as the pxe booting computer?
If running tcpdump, is that on the FOG server? And the pxe booting target computer is on the same subnet?
Please understand we are trying to get a picture of how your network is setup and testing parameters.
-
@george1421 I tried both with the dynamic and static IP addresses on the windows machine (the one I am trying to pxe boot).
I am running tcpdump on the FOG server (which I set up on my ubuntu machine) and the pxebooting target computer is on the same subnet.
-
@itachi_19 That is very strange because tcpdump should be seeing something. Even normal dhcp network traffic.
FWIW the target computer needs to use dhcp to pick up the boot file info. What you have windows configured to doesn’t matter.
tcpdump -w output.pcap port 67 or port 68 or port 69 or port 4011should just work. You may need to define the interface it listens on for some linux distros like thistcpdump -i eth0 -w output.pcap port 67 or port 68 or port 69 or port 4011If your fog server is not seeing the dhcp requests are you blocking dhcp broadcasts…
What I don’t understand is that dhcp has to be working as well as tftp since in your picture ipxe is loading then its pulling an IP address again. So the FOG server HAS TO SEE the packets… unless ipxe is coming from a different server.
If we are not getting anything from tcpdump then wireshark on a witness computer on the same subnet as the pxe booting computer should capture it. Wireshark capture filter of
port 67 or port 68 -
@itachi_19 Thinking a bit more about this I am wondering where your FOG server and host/client are actually running?! The only picture we have from the PXE boot looks pretty much like a VM setup, right? What kind of virtualization do you use? What network settings do you use for those VMs?
-
@sebastian-roth Yes, both are VMs on a Virtualbox, and their network is set to NAT.
-
@george1421 I have added the interface.
However, there is one interesting thing I think I must share. I tried to capture packets and pxe boot again after setting target computer to assign IP addresses automatically. Tcpdump or tshark both don’t capture the packets again however when I recheck my dhcp-server status again, this is what I get.
I don’t understand what this really means but I am hopeful this can be useful. Note that at this point both machines have the same IP.
-
@itachi_19 said in Unable to configure DHCP in Ubuntu for PXE boot Win10:
Yes, both are VMs on a Virtualbox, and their network is set to NAT.
Really set to “NAT” or “NAT Network”? With simple NAT the VMs can’t see each other. While NAT Networt should work for PXE boot testing as you do I still think it’s not ideal to use because you cannot connect to your VMs from the outside unless you configure port forwardings. What I mean is, accessing the FOG server web interface or via SSH from your system hosting the VirtualBox VMs can be pretty handy at times.
Using Bridged network can make things easier but this would interfere with the rest of your network. So you need to know what you are doing.
Probably NAT network would be the way for you to go for now.
-
@itachi_19 There is something going on here because both conditions can’t happen tcpdump sees nothing but dhcpd responds to a client request.
Are you running tcpdump as root or sudoing to it? If you don’t have elevated rights I can understand why tcpdump would not see (because tcpdump can’t connect to the raw socket).
Yes, both are VMs on a Virtualbox, and their network is set to NAT.
Well that would keep the witness computer from seeing this communication. With NAT enabled that still doesn’t explain where the tftp://10.0.2.4/Windows@2010.pxe “Windows 10.pxe” file name is coming from. As they say, the culprit has to be in the house (virtualbox).
