TFTP Server

[Raymond Bell]

@Tom-Elliott Ok after some testing with 2 computers plugged in to same new switch one works great boots right in to fog the other enter tftp server same computers models same DHCP

[Tom Elliott]

@Raymond-Bell Then I really don’t know what’s going on. I’m sorry man, maybe @Sebastian-Roth or @George1421 can be of some more help. I’m not much on the figuring out side as I used to be, and I’ve given everything I can think of.

Sorry I’m not more useful at this point.

[Raymond Bell]

@Tom-Elliott said in TFTP Server:

@Raymond-Bell Then I really don’t know what’s going on. I’m sorry man, maybe @Sebastian-Roth or @George1421 can be of some more help. I’m not much on the figuring out side as I used to be, and I’ve given everything I can think of.

Sorry I’m not more useful at this point.

Ok thanks man…

i even unplugged the one that was giving me the tftp and plugged it into the port one that is work and same error

[george1421]

@Raymond-Bell TBH I only skimmed this thread so I may have missed something. But my intuition is telling me there is a secondary dhcp server responding to the target computer giving it conflicting pxe boot info.

[george1421]

So lets start with some data collection.

Is the dhcp server, fog server and target computer all on the same subnet/vlan? If so we can use the fog server to help us see what is going on in the pxe booting process.

I have a tutorial here on how to use tcpdump from the FOG server to capture a pcap file of the booting process: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

If the dhcp server, fog server, and pxe booting client are on the same subnet/vlan then go and grab the pcap and post it here. If any is on a different vlan then give us an idea of your network design so we can come up with a useful plan to collect this information.

[Raymond Bell]

@george1421 yes there are all on same subnet/vlan
Here you go sir0_1542402185175_output.pcap

10.24.32.60 is the ip the host pulled from dhcp

[george1421]

@Raymond-Bell Ah found it.

You actually have 3 dhcp servers responding. If you use wireshark and inspect the pcap file at patch #19 There is a dhcp server 192.168.15.1 that is giving band info. The other 2 dhcp servers 10.24.31.232 and .230 are in harmony. The 192.168.15.1 appears to be a cisco router on the surface.

[Raymond Bell]

@george1421 You the man i will look for that and i might just know what it is sorry to bother all of you …

[george1421]

@Raymond-Bell That 192.168.15.1 looks like its a real device on your network in that its giving the correct domain name, but its subnet mask and IP address range is not compatible with the rest of your network.

[Raymond Bell]

@george1421 said in TFTP Server:

@Raymond-Bell That 192.168.15.1 looks like its a real device on your network in that its giving the correct domain name, but its subnet mask and IP address range is not compatible with the rest of your network.

Ok might be the Earth Quake centers stuff

[Tom Elliott]

You mean I was kind of on the right track? Lol. Yay me! I just don’t do all the fancy pcap stuff sorry.

[Raymond Bell]

@Tom-Elliott said in TFTP Server:

You mean I was kind of on the right track? Lol. Yay me! I just don’t do all the fancy pcap stuff sorry.

LOL you are fine im thinking it might be a Cisco ATA i had a user connect this morning

[Raymond Bell]

@george1421 @Tom-Elliott

It was that ATA… Sorry for all the trouble guys

[george1421]

@Raymond-Bell said in TFTP Server:

It was that ATA… Sorry for all the trouble guys

That is why we are here to help. I’m glad you have it worked out. Something simple, but it caused you so much problems. On the plus side you are now on 1.5.5 with all of the fixes, so you are in a better place than when you started the day.