Good afternoon blfs-dev mailing list members!
This is my first actual post here, but I've been reading for quite
some time. I've been using LFS since book 3 for some kind of
relativity (not that it should indicate anything, really).
Anyway, every now and then when I do a build I try out dhclient to see
if it's working for me again, since I prefer it's syntax to dhcpcd.
Today I had the last straw and had to go and figure out what was
wrong, so here's my discovery regarding dhcp-3.0.2's dhclient.
The problem only occurs when dhclient attempts to resolve from a
server that does not supply a domain-name. Debugging lead me to
realize that it comes down to this specific line from dhclient-script
(which is unmodified from the iproute2 patch, all versions):
if [ "x$new_domain_name" != x ] && [ x"$new_domain_name_servers" != x ]; then
If a domain-name is not passed from the router, then this line causes
the resolv.conf update function to fail, even if it recieved
domain-name-servers in the $new_domain_name_servers variable. Due to
the design of the whole function, it needs to be reworked as such to
avoid any glitches.
if [ "x$new_domain_name" != x ] || [ x"$new_domain_name_servers" != x ]; then
echo "# this file was generated by dhclient-script (even if you
don't have a domain-name)." > /etc/resolv.conf
chmod 755 /etc/resolv.conf
fi
if [ "x$new_domain_name" != x ]; then
echo "search $new_domain_name" >> /etc/resolv.conf
fi
if [ "x$new_domain_name_servers" != x ]; then
for nameserver in $new_domain_name_servers; do
echo "nameserver $new_domain_name_servers" >> /etc/resolv.conf
done
fi
This will allow name servers to be registered on connections that do
not recieve domain-names due to ancient hardware or what have you.
I don't know if there was a reason that the script was excluding dns
for nameless domain routers. Then again, I don't know why the script
uses "x" instead of the -n flag to check for not null. If nobody can
think of a good reason why this shouldn't be like this I will gladly
submit a patch after I learn how to make one.
Also, it should be noted that this can be worked around without a
patch - if you set a supersede statement in your dhclient.conf then
everything will work fine whether your router is glitchy or not. This
modification just allows resolv.conf to actually be updated if for
some reason the domain name is null.
Jonathan
p.s. I don't know if this is the same in future releases of dhcp
above and beyond the current blfs version as I have not had the
opportunity to check. I know that I have experienced this situation
for quite some time with my (somewhat functional) router.
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
