DNSMasq ProxyDHCP tries to pull ipxe.default from wrong IP

[Sebastian Roth]

@Quazz Intersting one I only see one DHCP conversation in that dump file and no TFTP traffic.

The DHCP discover and request packets have option 60 (Vendor class identifier) set to ‘MSFT 5.0’ which indicates this packets are coming from a windows client. They are not pxe boot requests as they would have ‘PXEClient’ set as vendor class if the NIC would try booting via PXE! As a result the DHCP server answering those does not send option 66/67 or next-server/filename which is just fine because the client didn’t ask for PXE info.

Where exactly did you capture this traffic? Did you see the client booting up via PXE? My guess would be that you captured traffic on the “router side” and therefore missed the PXE DHCP traffic to the FOG server. But wait? Clients send their very first DHCP discovery and request to 255.255.255.255 broadcast. We should see those! I am confused.

[Quazz]

@Sebastian-Roth I may have dun’goofed.

I just captured this on Windows, as you already know.

I suppose I should set up a debug task and capture it like that, then filter it later, right?

Should dnsmasq be enabled when doing this? Should ISC-DHCP?

EDIT: I also noticed dnsbootimage was set to 192.168.1.1 in .fogsettings . I don’t really know what that setting does, do you reckon that should be switched out?

I set up a DNS server in the mean time anyway, as it was a pain to not be able to access our internal network during network outages.

Thanks

[Tom Elliott]

@Quazz Edit the default.ipxe file?

vi /tftpboot/default.ipxe

From the sounds of it, the ipxe boot process is set correctly, but the default.ipxe file may have the wrong IP to get the information from to begin with.

For upgrade/install fixing, yes edit the /opt/fog/.fogsettings particularly the ipaddress= line.

[Quazz]

@Tom-Elliott Just checked and all those are pointing to the FOG server, which only makes sense since it works with ISC-DHCP and on some clients with dnsmasq ProxyDHCP.

And seeing as it looks on the wrong IP address for the default.ipxe, I’m not sure changing anything in that file would help. (even so everything looks normal in it)

[Sebastian Roth]

@Quazz Could you please try capturing the traffic on your FOG server. Start dnsmasq and stop ISC-DHCP service. Install tcpdump (package is called tcpdump on redhat/centos/fedora and debian/ubuntu) and then start it: sudo tcpdump -i eth0 -w pxeboot.pcap port 67 or port 68 or port 69
Leave this command sitting there and startup one of your clients. When you see the FOG boot menu you better shutdown the client, go back to your FOG server and stop tcpdump with Ctrl-c. Please upload this dump file here.

[Quazz]

@Sebastian-Roth I did as you say, the file will be lower in this comment. First though, something strange happened on the iPXE load screen that I have not seen before (perhaps related to upgrading FOG to latest earlier). It said it got info from both the dhcp server and the proxydhcp (and then selects proxyDHCP correctly).

Anyway, here’s the dump file:

0_1450362544801_pxeboot.pcap

Thanks

[Wayne Workman]

@Quazz Packet two is concerning…

Maybe try this?

port=0
log-dhcp
tftp-root=/tftpboot
dhcp-boot=undionly.kpxe,192.168.1.156,192.168.1.156
dhcp-no-override
pxe-service=X86PC, "Boot from network", undionly
dhcp-range=192.168.1.156,proxy

[Sebastian Roth]

Will be interesting to see if Wayne’s suggestion will make a difference. From my experience the clients don’t care about ‘server host name’ being set or not! But give it a try and let us know.

For further reference here in this thread I try to describe what I see in the pcap file. Overall this looks pretty good to me. Client (‘vendor class’ = PXEClient…) broadcasts a DHCP discovery and gets two answers. One from the router (192.168.1.1) offering IP, netmask, DNS server etc. The other answer comes from dnsmasq running on the FOG server (192.168.1.156) and provides PXE boot information next-server pointing to itself and filename = undionly.0
Then the client sends a DHCP request to confirm the IP information and is presented a DHCP ACK from 192.168.1.1. All fine from what I can see. Then the client (192.168.1.26) requests undionly.0 via TFTP.

After that first round of DHCP/TFTP from the NIC ROM we see another DHCP communication with very similar information being exchanged. This is iPXE requesting an IP. Looks good as well! Then iPXE receives default.ipxe

To sum things up: To me this looks pretty good! Now can you please try the exact same thing but bootup one of the clients that does not work…

[Quazz]

I work in a small repairshop, things come and go at a fast pace, as soon as I come across one that doesn’t work again I’ll update this.

[Quazz]

I have not come across this issue since starting this thread (I did update FOG somewhere after the start of the thread which included updates for the binaries)

At worst it will ask me to enter the IP address which is a small price to pay for peace of mind.

So I guess this can be considered solved for now.