Bug #3915
closed
DHCP server static mapped clients do not receive custom DNS servers
0%
Description
When I add a static mapped DHCP client, then put 2 custom DNS servers for that client (e.g. 8.8.8.8 and 8.8.4.4 to override the usual pfSense LAN IP as the DNS server) the dhcpd.conf file gets good looking stuff written to it. But when the client gets a DHCP lease it gets the specified static IP address correctly but the DNS servers are are those for the ordinary pool, not the custom ones.
Sample /var/dhcpd/etc/dhcpd.conf is attached which looks good - see "host s_lan_3" which has 8.8.8.8 and 8.8.4.4 specified. But when it gets its DHCP lease it just gets 10.49.0.250 as the DNS server (which is LAN IP).
Tested on 2.1.5 and 2.2-BETA 7-Oct-2014 with the same issue.
It seems like a real bug in dnsmasq or maybe the conf file has to be written a bit differently or?
Files
Updated by Phillip Davis over 9 years ago
- File dhcpd.conf dhcpd.conf added
And here is the dhcpd.conf I forgot to attach.
Updated by Raul Ramos over 9 years ago
In 2.2 and using DNS Resolver it seems other way around. If you don't config custom DNS on DHCP client don't pic DNS servers.
This was tested weeks ago. I should try the last one DNS Resolver.
Updated by Renato Botelho over 9 years ago
I tried it on 2.2 and 2.1.5 and both worked as expected, my test config is similar to the one you posted.
Updated by Phillip Davis over 9 years ago
Oh dear - I was thinking this was going to be a nice clear bug, since I noticed it on my test 2.2 system, then did similar on a production 2.1.5 system and got the same problem - dhcpd.conf looks good, but "ipconfig /all" on the client shows it did not get handed the custom DNS servers.
I will try harder tomorrow with a few different clients and see if I can characterize it better...
Updated by Chris Buechler over 9 years ago
- Status changed from New to Feedback
also works fine here. Suspect client-side issue, will leave for feedback from Phil.
Updated by Phillip Davis over 9 years ago
- File DHCP-packet-capture.txt DHCP-packet-capture.txt added
It is related to the client requesting DHCP "option 252", which is related to web-proxy auto-discovery - http://tools.ietf.org/html/draft-ietf-wrec-wpad-01
On my Windows laptop, a release-renew of the lease results in a good looking packet capture of DHCP request and response. In the example packet capture the client has static-mapped IP 10.52.0.12 and is given that IP correctly by pfSense DHCP server.
Domain-Name-Server is specifically set in pfSense DHCP config to 10.49.48.1 and that is delivered correctly to the client (events at 16:15:52 in the packet capture).
Then at 16:15:56 there is another DHCP request from the client that has added "Option 252" on the end of the list of things it asks for. I believe that might be generated by a web browser (Firefox...) that wants to check for a possible proxy server. The reply to this from the DHCP server has Domain-Name-Server 10.49.32.1 - that is the DNS specified for the pool/subnet as a whole.
So under conditions like this, the DHCP server responds with the incorrect Domain-Name-Server value - what sort of bug is that?
Anyway, the pfSense-generated dhcpd.conf looks fine. Where should I look upstream to find the relevant source code and see if I can track down the cause of the bug?
Updated by Phillip Davis over 9 years ago
Domain-Name-Server is specifically set in pfSense DHCP config to 10.49.48.*250* and that is delivered correctly to the client (events at 16:15:52 in the packet capture).
Detail in post 6 should NOT be 10.49.48.1, it should be 10.49.48.250 - as per the packet capture. (There seems to be no way to update a dodgy comment on a bug)
Updated by Chris Buechler over 9 years ago
Phil - do you not see a pencil to the right of your comment? That's how you can edit previous posts. I thought it was set so anyone can edit their own posts.
On the issue at hand, that's an ISC dhcpd issue from the sounds of it. We're configuring it correctly, it works correctly in general, for some reason in that circumstance w/wpad it doesn't do what it's configured to do. It seems maybe this is referring to the same (or similar) issue?
https://lists.isc.org/pipermail/dhcp-users/2013-May/016707.html
Updated by Phillip Davis over 9 years ago
Had a look at dhcp.c ISC source code and submitted a bug report. Then after more research I found this:
Extend the DHCPINFORM processing to honor the subnet selection option
and take host declarations into account.
Thanks to Christof Chen for testing and submitting the patch.
[ISC-Bugs #35015]
This was committed to master of ISC-DHCP on 2013-12-14 and is in V4.3.n
The code diffs look like a really good thing to actually even bother looking up the host-specific options when responding to an INFORM from the client. The previous code did not even try, so it was not a little bug, more a missing feature.
The 35015 code does not appear in the V4.2.n branch. FreeBSD 10.1 pfSense 2.2 has V4.2.6 (and V4.2.7 is current-stable on ISC web site), so neither of those will have this fix/enhancement.
I expect this will be fixed when FreeBSD and pfSense is using V4.3.n of ISC-DHCP - maybe the 4.3.n series is not yet production-stable???
Anyway, this can be closed here, as the issue is dealt with upstream and the fix should flow into FreeBSD and pfSense over time.
Updated by Phillip Davis over 9 years ago
Received this text in email today from dhcp-bugs@isc.org :
--------
Yes 4.3 added this functionality. There was a bug
in the earlier versions of it that we fixed in 4.3.2.
Marking this as resolved. If you try 4.3.2 or later
and find a problem you can either re-open this
ticket or open a new ticket.
regards,
--------
When FreeBSD and then pfSense end up with ISC DHCP 4.3.2 or later then this should work.
Updated by Chris Buechler over 8 years ago
- Status changed from Feedback to Resolved