DNSMasq ProxyDHCP tries to pull ipxe.default from wrong IP

[Quazz]

Okay, so, I did some wireshark capturing and when ISC-DHCP-SERVER is running, all devices seem to receive their DHCP info from ISC-DHCP.

So I guess the main reason the issue of IP conflict comes up is when it’s unable to communicate with the rest of the network which typically happens when the router has issues as that is referred to as the DNS. So I guess for ISC-DHCP if I can resolve that I would be fine.

Also tried to capture traffic directly to the router and next-server option seems to be set as 0.0.0.0 according to wireshark. However option 63 is not passed along. (does this mean it defaults to the router’s ip or that it’s not set?)

Thanks for the help already, guys.

[Sebastian Roth]

Relay agent IP being 192.168.1.1 makes me think this might be a DHCP answer from your ISP. But this is just a wild guess. Would you mind uploading the full packet dump (use display filter bootp || tftp and then save those packets to a new PCAP file) so I can have a closer look? You can also send me a chat message with a link if you don’t want to publicly upload the file - although there should not be any reason to be concerned as this seams to be all private IP addresses!

[Quazz]

0_1450343902342_DHCP captured packets.pcap

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