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

[Tom Elliott]

@_mateo change pxelinux.0 to undionly.kpxe

[_mateo]

@Tom-Elliott Oh god, thanks. I remember that section of the tutorial a little lacking, sorry to say. It says something to the effect of, “Change any settings you think would need to change.” And I could really only think in terms of IP addressing, but that’s just my inexperience showing. Either way, thank you very much!

Just another quick question. After making changes like this, is it required/advised to restart the service or machine?

Edit: Also, I’m still getting the error. I tried changing it there and the ltsp.conf file. I’ll try a restart

[_mateo]

@Tom-Elliott My bad. There are a two instances of pxelinux.

But now that I have that taken care of, I get through the iPXE process. But then it crashes, error message says, “Could not start download: Operation no supported” and then a link to ipxe.org

[Tom Elliott]

@_mateo sorry I didn’t go all in depth on exactly what to change and what to do but any change to a Config file typically means the service referencing that file needs to be restarted or reloaded, I typically restart to ensure things are right.

[Sebastian Roth]

Again, please take a picture or tell is the exact error message you see on the screen.

[_mateo]

@Sebastian-Roth Sorry! Attaching now. The error is so fast I had to shoot a video to catch it, so the last bit of the URL is missing. But this is what I’m seeing:
I was following this thread a bit, should I upload a tcpdump? https://forums.fogproject.org/topic/6067/could-not-start-download-operation-not-supported/16

Edit: I also tried the new binary that you mentioned and didn’t see a change.

[_mateo]

So in this article there’s this line:

In the litsp.conf that I have, it just has the “dhcp-boot=undionly.kpxe”
Is this by design since I’m on 1.2.0?

[Wayne Workman]

@_mateo Look through these threads:

https://forums.fogproject.org/topic/4745/how-to-configure-dhcp-proxy/11

https://forums.fogproject.org/topic/4867/issues-booting-to-fog-using-dnsmasq/6?page=2

https://forums.fogproject.org/topic/5533/a-new-dnsmasq-issue/7

And you should probably fill in the additional dhcp-boot options.

[Sebastian Roth]

Have you looked through this article yet? https://wiki.fogproject.org/wiki/index.php/Troubleshoot_TFTP

Capturing a packet dump using wireshark or tcpdump on your FOG server would definitely help. I will take a look if you upload a PCAP file.

[_mateo]

@Wayne-Workman
https://forums.fogproject.org/topic/5533/a-new-dnsmasq-issue/7 - Yes. I actually had that line commented out because it was preventing the dnsmasq service from starting in the first place.

I’ve also tried the tips in the other two threads. I think I may be able to modify our network DHCP. So if I just make the option 66 and 67 changes, could I just stop the dnsmasq service and everything will be okay? Or will I have to modify any other conf files?

@Sebastian-Roth 0_1454445769060_issue.pcap Hopefully I didn’t allow too much garbage to get in. Thanks for taking a look!

[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.