tftp server issue
-
We have been using FOG for 10 years, Recently we can not image from ONE of our subnets but all other subnets still work. ALL subnets worked previously. The scope has! been recreated for the subnet we are having problems with. The scope options 66 and 67 are the exact same on all our subnets DHCP scopes and have been confirmed. We have configured a test FOG server to rule out this is a FOG server problem and it still is not working.
-
see new attachment of message when we enter the the tftp server 10.1.100.201
-
Does this subnet (where you are trying to pxe boot from) have a screening router/firewall between it an your fog server subnet?
As I see it you have 2 problem.
- Your target computer is not getting the right pxe boot information to boot.
- Your target computer is not able to reach the tftp server (assuming that your fog server IP address is 10.8.100.22)
So the first step is to understand why the target computer isn’t getting the right dhcp information.
- Take a witness computer (i.e. a laptop) and install wireshark on it.
- Plug that witness computer into the same subnet as the pxe booting client computer
- Launch wireshark as administrator
- Key in this capture filter
udp port 67 or udp port 68 - Start the capture with the ethernet network adapter that is connected to the subnet where the pxe booting computer is.
- Now pxe boot the target computer to the error
- Stop the capture.
- Save the capture
- Upload the capture to a share file site and post the link here. I’ll take a look at the pcap to see what the target computer is being told.
For your information you should see the target computer send out a DISCOVER packet, and then you should see one or more OFFER packets. Its the offer packets I’m interested in reviewing. There should be only one OFFER on a normal network.
-
@frankv24 Any news on this?
-
@george1421 - Thanks We captured data while trying to image a machine on the 10.15 network where are fog server is on the 10.8 network all other subnets work except 10.15 subnet, when adding capture filter 67 and 68 no data was found for .203 machine we remove the capture filter and get this output for ,203
-
@frankv24 said in tftp server issue:
when adding capture filter 67 and 68 no data was found for .203 machine we remove the capture filter and get this output for ,203
Unfortunately there is no information in the picture that could help us here. When capturing network traffic it’s always important to know at which point you capture and which devices are involved in the communication.
So I need to ask you on which device was this traffic being captured? Is it the DHCP server itself or on another client what is connected to a mirror port on the same switch than client 10.15.101.203?
-
@frankv24 said in tftp server issue:
when adding capture filter 67 and 68 no data was found for .203
Just to be clear, if you setup a filter for .203 in addition to udp ports 67 and 68, then that is the problem. The dhcp process uses broadcast messages to communicate. Since they are broadcast messages all client computers on the 10.15 subnet will hear this communication. That is why as long as the witness computer is on the 10.15 subnet and listening it should hear the dhcp communications. At the point of the dhcp communications, the target computer doesn’t know its IP address.
-
Not entirely sure what’s going on here, but I’m guessing you can’t reach the tftp server given that subnet configuration which I’m guessing is passed along by the wrong DHCP server.
If we can see which DHCP communication those clients get, then it will likely lead to the correct answer.
-
@george1421 The filter was set on the witness machine and was not specific to .203. We saw traffic, but no traffic from .203 which was the machine we were pxe booting - Thanks for the response.
-
@Sebastian-Roth Thanks for the response - We did not capture from our DHCP server, We used another machine connected to the same switch and subnet 10.15.100.* as the machine we were pxe booting from.
-
@frankv24 said:
We did not capture from our DHCP server, We used another machine connected to the same switch and subnet 10.15.100.* as the machine we were pxe booting from.
You should see the DHCP broadcasts (client asking for an IP) then. What you don’t see is all the following traffic because most of that is unicast (only going from port A to port B on the switch and not to port C where your capture client is connected to!).
-
@frankv24 - RESOLVED - First thank youfor all your responses the forum is great. We narrowed this down to the issue to be on the 4th floor IDF of the 10.15.100.* subnet by shutting down each fiber interface on the MDF to the floors IDF’s - Once the 4th floor was shutdown the PXE boot worked. We then narrowed are search to the 4th floor IDF switch where we found a NETGEAR wireless router connected in student lab to the 4th floor IDF - Once this swithc was reemoved - the entire 10.15.100 subnet was able to PXE boot
-
@frankv24 said in tftp server issue:
we found a NETGEAR wireless router connected in student lab
Ah you found a rogue dhcp server hiding on your network. Well done. I know its very difficult to find these devices and keep them off your network.
