Solved tftp server issue
-
@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.