default.ipxe timeout

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