default.ipxe timeout

[mjcrane]

Please help. I’m getting this message “tftp://192.168.0.1/default.ipxe…” right before a connection timeout. I can see why it’s timing out - that IP is my router. The FOG/tftp server is at 192.168.0.111. On bootup, it appears like undionly.kpxe is being read properly but then the client reverts to the router IP after. Does anyone have any advice on how to fix this? Thanks.

[Wayne Workman]

is the router a consumer grade router? Are you using dnsmasq? Are you using a virtualized FOG server?

[mjcrane]

Router’s provided by ISP. Running dnsmasq in Kubuntu 14.04 under VM Workstation.

[Wayne Workman]

@mjcrane This problem comes up repeatedly. That’s how I knew to ask about dnsmasq, consumer grade router and fog in a VM.

What’s happening is during the 2nd DHCP ‘hailing’ (like on star trek), the system you’re trying to netboot is getting information exclusively from the ISPs router instead of dnsmasq as well.

In the past, this has been solved by flashing the consumer grade router with something like dd-wrt-public. But, because this is owned by your ISP, I’m afraid that isn’t possible.

There are alternatives. You could try to turn DHCP off of the consumer grade router and configure it on the virtual FOG server temporarily. You could find/borrow/purchase a flashable consumer grade router and put DD-WRT public on it, and simply configure DHCP options 066 and 067 on it and then place this device between your ISP router and your computer running the VMs. Or… perhaps you could run CrucibleWDS’s windows based ProxyDHCP. You can download just the exe from sourceforge and run that on the hosting OS and that should solve the issue. Here is their site: http://cruciblewds.org/ Keep in mind that CrucibleWDS is a fork of FOG, and that hopefully, the two projects will merge talent and features in the future for FOG-TOO. In the mean time, you could use just their ProxyDHCP with FOG on your windows machine to hopefully accomplish what you need. I’ve never recommended this to anyone before so you will sort of be the lone ranger… I’m absolutely willing to help via TeamViewer should you need it.

If you have any further questions, don’t hesitate to ask.

[mjcrane]

@Wayne-Workman Thanks for replying. I will explore those options when time permits and will get back to the forum with the results. Appreciate your help.

[Sebastian Roth]

@mjcrane Just stumbled upon this interesting article: http://jpmens.net/2011/07/18/network-booting-machines-over-http/
Checkout his dnsmasq configuration. It’s not proxy mode so better do not just copy&paste this whole config. But take a closer look on what he does with matching. Pretty good I think. It might help in your case too?! In case it does not help I would be interested in getting a packet dump when the client boots up. Best would be to use a network hub just in front of the client to be able to capture all the traffic. Or a dump on the FOG server could also be of help if time is sparse.

# iPXE sends option 175; make a rule named IPXEBOOT to match requests
dhcp-match=IPXEBOOT,175

# if the request does not (#) match the IPXEBOOT rule tell the client
# (most likely standard PXE client) to boot iPXE
dhcp-boot=net:#IPXEBOOT,undionly.kpxe

# Set "next server" for iPXE to boot from this URL
dhcp-boot=http://192.168.1.10/ipxe/boot.php

@Wayne-Workman More and more I think there is no way around a proxyDHCP implementation for FOG. But we still need to discuss about language… I reckon.

[Wayne Workman]

@Uncle-Frank That’s very interesting.

I wonder if you could configure Windows DHCP or ISC-DHCP to do the same? the way it’s written, it doesn’t seem like dnsmasq is necessary - but instead optional.

[mjcrane]

@Uncle-Frank - I tried this as well as @Wayne-Workman’s Crucible option. Sadly neither worked for me. Then again my knowledge of all this is very limited so I may not have been doing it right! I’m hoping you could look at my tcpdump and help figure out what’s going wrong and how to fix it. I captured this using the original ltsp.conf settings I started with. Thanks in advance guys!

issue_151007.pcap

[Sebastian Roth]

@mjcrane From what I can see in the packet dump you have three DHCP servers:

• 192.168.0.1 - ISP - offering IP address and next-server (pointing to 192.168.0.1)
• 192.168.0.110 - ?? - proxy DHCP (pointing to 192.168.0.110) could this be Crucible??
• 192.168.0.111 - FOG - dnsmasq in proxy mode (next-server 192.168.0.111/bootfile undionly.kpxe(.0))

Probably better to turn off Crucible ProxyDHCP again if it does not work for you.

My guess is that iPXE (undionly.kpxe) uses the ‘next-server’ sent by your ISP altough the binary itself comes from a different IP. You can force iPXE to load default.ipxe from any IP you want using your own embedded script. I just compiled one for you with your IP (192.168.0.111) undionly.kpxe

Give that a try. If it works you should start looking into compiling your own iPXE binaries. It’s not too hard as there is a online service. I’ll tell you about this later if we are on the right track with this.

[Wayne Workman]

@Uncle-Frank said:

I just compiled one for you with your IP (192.168.0.111)

I still haven’t wrapped my head around how to do this… But I really want to learn. I tried it once and it was sort of a disaster…

[Sebastian Roth]

@mjcrane How did you go with the undionly.kpxe binary I uploaded?

@Tom-Elliott Working on the DHCP proxy stuff I just came to a solution for this situation as well - by accident.

#!ipxe
...
isset ${next-server} && isset ${proxydhcp/next-server} && set next-server ${proxydhcp/next-server}
...

It’s just a rough sketch. Though I testet it - working! I’ll get back to you about the ipxe script soon I think. Thanks again for the discussion about this stuff. Now that I have tested a little more it seams like the DHCP info from pre-iPXE boot is available in iPXE in most cases anyway. Might be only an issue with my specific lab PCs. Will test next week…

[mjcrane]

@Uncle-Frank Still not working for me. I could see that it’s pointing to 192.168.0.111/default.ipxe but I’m getting the same timeout error. I also made sure Crucible is removed from my environment. Here’s the latest tcpdump in case you need it.issue_151027c.pcap

[Sebastian Roth]

Weird that is… I can’t see much related traffic after undionly got downloaded via TFTP. Only thing I wonder is that I see ARP requests after that. 111 is asking who is 177 (the client).

As I have been playing with iPXE and script files a lot I don’t really remember exactly what script I compiled into the uploaded binary. But as it does not do dhcp after TFTP I’ll compile a new one for you that does exactly that. Hope this will help you: undionly.kpxe

[mjcrane]

@Uncle-Frank That did it … you fixed it! Awesome! I’m going to start up/down-loading shortly to test everything. Just for future reference, can you share what you changed in the file? Good work you guys are doing here - thank you.

[Sebastian Roth]

@mjcrane Great! Got it right this time You are welcome!

Take a look at this script: http://sourceforge.net/p/freeghost/code/HEAD/tree/trunk/src/ipxe/src/ipxescript

This is compiled into the iPXE binary Tom is building for all of you (the original undionly.kpxe you had in /tftpboot sitting). The last line is chainloading default.ipxe from the FOG server. In your case the variable ${next-server} is being set to your ISPs router IP. So I just compiled a new binary and exchanged the varibable with a “hardcoded” 192.168.0.111 - pretty ugly but still working…
If you want to play with this without installing all the building tools you can go to https://rom-o-matic.eu/ (But be warned, getting all the settings right is kind of tricky!)
Just give it a try. There is a lot you can learn about PXE booting by trying out these things.

As I already said there might be a fix in the script that we could add which hopefully should work for others too. @Tom-Elliott What do you think? See in one of my earlier posts. Either that or we just overwrite next-server without checking it being set or not in case proxydhcp is set?!

#!ipxe
...
isset ${proxydhcp/next-server} && set next-server ${proxydhcp/next-server}
...