Yet another Person with DNSMasq issues
-
I’ve attached a pcap file, I’m not an expert on tftp or dhcp but I don’t seem to be able to see any issues?
It just looked to me as if the main DHCP server is still handing out all the details and the clients are just ignoring DNSMasq? -
@RipAU Yes, we see two DHCP offer replays. One from dnsmasq (10.254.14.77) and the other one from 10.254.14.53 (probably the new windows 2012 DHCP). At first I thought those offers were fine but now I think I found something. DHCP messages have two places for pointing to TFTP servers for PXE booting. ‘next-server’ which is kind of in the DHCP header and option 66. Those offers from the windows DHCP point to 10.254.14.53 (next-server) but 10.254.14.55 (option 66).
So the client is offered three different IP addresses to get the boot file from. No wonder it is confused. I am wondering about the configuration of the old windows DHCP server. Maybe it did not offer next-server/option 66 at all? Beyond that I don’t have a good idea why it worked before the change (don’t know enough about WDS). Maybe ast your windows DHCP admins why they point option 66 to 10.254.14.55 and we might take it from there.
Edit: One possible reason I could think of is that your FOG server was installed on hardware (seams like VMware now from what I see in the packet dump) and used to answer faster than it does now. Just a wild guess…
-
Thanks, yeah I’m thinking it is a configuration of the new servers, I’ll have to give them a call and find out how it is configured.
They have a few VMs setup to handle the DC/DNS/DHCP. 14.55 is the DC and DNS I’m unsure what other roles 14.53 have.I’ve always had FOG as a VM and I’ve only had this issue since the new Windows 2012 servers are running, so I don’t think its a timing thing.
As you mentioned the old Windows servers may not have had option 66 enabled which allowed me to use DNSmasq previously.
I’ll go through the pcap files and see if I can understand it better and harass the guys in charge about why next-server and option 66 are pointing at different locations.Thanks again.
-
@RipAU You are welcome! Hope you can find out what changed or at least how to make it work again. Do they need next-server/option 66 at all on the windows side? Usually it is not a good idea to have more than one DHCP service offering “different” information anyway.
As there are requests from different clients in that PCAP file I’d suggest using this filter so you only see the stuff you need to worry about:
bootp.id == 0x56cd898b(don’t use this filter all the time, just in this case it is very helpful) -
I’m waiting for someone to give me a call back now, to work out what exactly is set and why.
So far the DHCP/TFTP server is 14.53 so I’m not sure why they have 14.55 listed as option 66 it doesn’t actually have any TFTP or DHCP functions outside of being a DC.I’ll have to wait and see what they say. This image is a standard PXE boot and 14.55 isn’t even popping up.
Thanks, I’ll have a go with that filter.Cheers,
-
@RipAU So what did it look like with the old windows DHCP server? You never got into the “Downloaded WDSNBP” thing? Do you actually need to boot your clients from WDS at some point? You really need to think about which PXE boot you need. WDS or FOG? It’s not a good idea to try and ride two bicycles at the same time and hop from one to the other by chance. In PXE-network speak this would mean the faster PXE server is booting your client. Randomly one or the other is faster.
-
Yeah we have always had WDS and the entire windows server with DHCP/WDS etc is controlled by an outside organisation and due to policy I am unable to change it.
That said: We have had fog running and doing our imaging for quite a few years and we did previously have DNSmasq working perfectly next to Windows older windows deployment server. Just trying to figure out what has changed in the setup. Worst case I have got IPXE USB keys I can use to boot desktops but it would be handy to have a proxyDHCP working again.
I’m still waiting for feed back from the Windows admins about this and I can cross my fingers and hope.
I’ve also tested CWDS ProxyDHCP on another PC to see if it works but that has the same issue as DNSMasq in regards to the clients only going from the WDS.Thanks again.
If I can figure it out I’ll let you know just in case others run into something similar
-
I’m wondering if DHCP set to authoritative would impact ProxyDHCP. If I have time and you are available we might get together and just look at some traffic from Wireshark and see what’s happening.
-
I’m happy to dump more data from wireshark?
-
Another question coming to my mind is - what if you make it work with dnsmasq? Will this interfere the other guys WDS stuff? Anyway it’s good to work together with those people instead of against them. Try to find a way to make both work. A good starting point is that it obviously used to work in your environment. Unfortunately you can’t go back in time to trace the packets and look what’s different. So I’d suggest get into the details of PXE booting and see if you can find any hints on proxyDHCP overwriting DHCP settings: ftp://download.intel.com/design/archives/wfm/downloads/pxespec.pdf
As well I just remembered seeing clients showing “PROXY IP” information on the PXE boot screen. See here: http://www.nclone.com/wp-content/uploads/2012/04/nclone-pxeboot1.png
Sure this is not the exact same firmware (the one on the picture might even be a VM) but you see what I mean. I don’t see this information on the picture you posted. Do you remember seeing that back when it all worked?? -
@RipAU Any new on this topic? Really looking forward to hear news on this.
-
@RipAU Marking this solved as I feel there is nothing much more we can do. Feel free to post again if you have more questions on this.
