Hello, FYI:
1) The OPTION MODIFIERS section of dhclient.conf(5) indicates that the default client configuration script processes only options 1 (subnet mask), 3 (routers), 6 (domain name servers), and 15 (domain-name). In fact /sbin/dhclient-script also uses option 28 (broadcast address). 2) dhclient-script(8) mentions several times static routes but in fact the static-routes option is not used by /sbin/dhclient-script 3) When /etc/dhclient.conf is empty, the default requested options in the read_client_conf function of /usr/src/sbin/dhclient/clparse.c include option 2 (time offset) and option 12 (host name) which are never processed by /sbin/dhclient-script. I guess it doesn't really hurt to request them in clparse.c just to ignore them later in /sbin/dhclient-script (if they are actually supplied by the DHCP server) but I found it a bit confusing when reading the code... /****************************************/ On a related note, I couldn't find in /usr/src/sbin/dhclient/dhclient.c any code that explicitly removes from a DHCP server's reply any option that was not explicitly requested (or required) by dhclient. Unrequested options sent by a DHCP server seem to always end up in dhclient-script's environment and the system then relies on dhclient-script implicitly ignoring what it does not know about in its environment. This looks to me a lot like a "default allow" policy that relies on dhclient-script doing the Right Thing. When the user later discovers a problem (for example when dhclient-script messes up the /etc/resolv.conf of people who run their own DNS server) the user then has to use "supersede" as some sort of after-the-fact blacklist for unwanted options. IMHO, it would be better if dhclient.c used the list of options requested by the user as a whitelist and then put in dhclient-script's environment only strictly what the user wanted dhclient-script to know about. I.e. the policy for unrequested options would in essence switch to "default deny". This would also have the nice side effect that, if the user didn't ask for the domain-name and domain-name-servers options, then dhclient-script would never change /etc/resolv.conf regardless of what the DHCP server included in its reply. Then people who run their own DNS server (like me, which is why I started looking into this whole thing) wouldn't have to use "supersede" and /etc/resolv.conf.tail (which works but leads to the duplication of information between /etc/resolv.conf, /etc/resolv.conf.tail, and /etc/dhclient.conf, and thus has the feel of curing the /etc/resolv.conf symptom instead of curing the dhclient-script disease :-)). While I'm on the topic, I also think that it would be nicer to completely remove all the default requested options from clparse.c and instead have the default /etc/dhclient.conf request subnet-mask, broadcast-address, routers, domain-name, and domain-name-servers explicitly. This means that it would no longer be "sufficient to just create an empty dhclient.conf file" (from the EXAMPLES section of dhclient.conf(5)) for things to "magically" work, and such a change would also require existing users who currently have an empty /etc/dhclient.conf to change it to explicitly request all the basic options (though sysmerge could easily take care of that one-time change) but I think it just would be cleaner and clearer to have the default requested options listed explicitly in the default /etc/dhclient.conf rather than to have them hard coded and buried in clparse.c. Maybe it's just me :-) Anyway, food for thoughts. Philippe
