FOG 1.3.0 - SVN 6050 - "Please enter tftp server:"

[ttrammell]

@Tom-Elliott We only have one; we have two DNS servers. I use an automated script where it activates fog with installfog.sh -y. Could it have possibly enabled DHCP through that? If so, is there a way to check or fix it easily?

[Tom Elliott]

@ttrammell There’s a couple causes for this, but more often than not when this message is “suddenly sprung on” the issue is there was an accidentally introduced DHCP Server. DNS Servers have nothing to do with handing out the tftp files. You could potentially try Wireshark capture to see what’s going on.

The other way this could happen, I suppose, is the Option 66 is defined but Option 67 is not. (Option 66 is the IP to look at, while 67 is the file to use for booting).

[Tom Elliott]

FOG 1.3.0 does not assume Yes, for DHCP server. You could validate this though and yes it’s possible if in the past DHCP was enabled and was not told to be turned off during installation. You might try:

service dhcpd stop

[ttrammell]

@Tom-Elliott Running that on the server came back with an error.

# service dhcpd stop
dhcpd: unrecognized service

As far as everyone I work with knows, we haven’t introduced another DHCP server; will dig around and see if something is hiding on the network.

I will also take a look at Option 66 and 67 to make sure they are still set right.

Any other ideas to try while I am looking into this?

[george1421]

@ttrammell If your fog server, dhcp server and pxe booting client are on the same subnet we can use tcpdump to capture the pxe booting process to see if you are getting another dhcp offer packet.

1. Install tcpdump on the fog server
2. start the tcpdump program with the following command sudo tcpdump -w output.pcap port 67 or port 68 or port 69 or port 4011
3. PXE boot the target computer to the error
4. Press control-c on the tcpdump program
5. Either review the pcap file with wireshark or post the pcap here and we can review it for you.

[ttrammell]

Tom fixed me up; at least for now.

He can probably give you a much more elaborate explanation as to why it didn’t work; I kind of just watched in awe as he figured it out.

Edit: BTW, thanks again, Tom. Will post more on this if the issue comes back.

[Tom Elliott]

I remoted in with @ttrammell and we restarted the rpcbind service. While initially it didn’t appear to work, it suddenly started working again. I don’t know for sure if this was the rcpbind service restart or if there was indeed a rogue dhcp server. Hopefully, if the issue comes up again, we can probably pin it as a rogue dhcp server.

In either case the devices are working right now, and I even helped correct an NFS mount issue :).

[Tom Elliott]

Marking as solved, for now. If it happens again just let us know.

Thank you,

[alwos]

@tom-elliott

Hi tom, porcierto my english is regular, so I’m using the google tool. I have the same problem, I’m using two dhcp servers, one in the range 172 … and the other one in the 10 … please explain the / tftpboot /

[george1421]

@alwos Two comments.

1. Please open your own thread because your problem may not be the same.
2. If you are more happy, use your native language to explain the problem because your post is not understandable.