TFTP hangs in PXE boot, resulting in PXE session ending.

[Wayne Workman]

@_mateo said:

So if I just make the option 66 and 67 changes, could I just stop the dnsmasq service and everything will be okay?

Yes. And that is the best way.

[_mateo]

@Wayne-Workman So it worked! Sayonara dnsmasq… Though now I’m getting a chainloading error. Know of any current materials on the topic? I see this tutorial: https://wiki.fogproject.org/wiki/index.php/Boot_looping_and_Chainloading

But I don’t know that it applies to newer fog installations.

Edit: Pic incoming

[_mateo]

@Wayne-Workman
I’m not sure where the 10.129.1.79 address comes from… My Fog server is 10.92.1.174 fyi

[_mateo]

Well, maybe the chainloading thing is a red herring. My TFTP is just timing out, I take it?

[Wayne Workman]

@_mateo said:

I’m not sure where the 10.129.1.79 address comes from… My Fog server is 10.92.1.174 fyi

Look into this file on your fog server:
/tftpboot/default.ipxe There is one IP Address at the bottom, this should be your FOG Server’s IP Address.

Also, on your fog server, look into Web Interface -> FOG Configuration -> FOG Settings -> Web Server -> FOG_WEB_HOST and make sure that value is your FOG Server’s IP address.

Also inside of /opt/fog/.fogsettings there is a field for the FOG Server’s IP address called ipaddress This should be set to the FOG server’s IP as well.

Only one of these things is wrong I think, but I’m including all three for future readers.

[Sebastian Roth]

@_mateo Great that you uploaded the PCAP file and changed to use option 66/67 on your DHCP server!

Looking at the PCAP file I see another DHCP server answering you queries. An that is 10.129.1.79! This is causing the current issue. This DHCP server hands out an IP in the range of 192.168.0.x to the client and offers to be a boot server (option 66 set to 10.129.1.79). You need to find this machine! The machines MAC address is 00:0d:b9:1e:27:fc (wireshark says it’s a PcEngine NIC - not sure if that helps).

[Wayne Workman]

@Sebastian-Roth Nice.

[_mateo]

@Sebastian-Roth Ah, it must be our DHCP for our public WiFi! So you think option 66 is active on that? I’ll go check! Hopefully I have access. Thanks so much.

@Wayne-Workman Thanks for the suggestions! Though, all of them were right. So I think Sebastian might be onto something.

[Sebastian Roth]

We have seen home routers sending out option 66 for no reason. I really hope that you can find and stop this device from answering on the LAN altogether.

[_mateo]

@Sebastian-Roth Hmm… So we could possibly have a rogue AP? I’ll have to ask my coworkers and see if they know anything about it.

[_mateo]

@Sebastian-Roth Also, as a student of networking I have to ask… How do you go about analyzing PCAP? Can you just open it with Wireshark?

[Wayne Workman]

@_mateo said:

How do you go about analyzing PCAP? Can you just open it with Wireshark?

Yes.

If you’re hardcore, you use Vi. Or, not even open it and use cat with grep and awk and sed

[Sebastian Roth]

@_mateo said:

How do you go about analyzing PCAP? Can you just open it with Wireshark?

Yes, that’s pretty much all you need to do. Then there is a couple of years experience looking through those dump files but just give it a go and start learning.

[_mateo]

@Wayne-Workman Haha! Oddly enough, I’ve only ever been taught to navigate and edit .conf files with Vi. I was following a FOG tutorial and was thinking, “What’s this ‘sudo nano’ crap all about?”

@Sebastian-Roth Gotcha! Thanks for your help. Still no word on if there’s a rogue AP/dhcp service running somewhere. I’ll keep you posted.

P.S. I have a community oriented question for you guys. Is it okay to keep posting in the same thread with each issue that comes up as I go along? I figure someone looking for a TFTP or PXE error will stumble across this, but we’ve covered a few different topics. I guess the search engine will be good enough to find keywords, I’m mostly just curious!