From Bugzilla Helper: User-Agent: Opera/8.5 (X11; Linux i686; U; en) Description of problem: Using a Netgear WGR614 v5 wireless router connected directly to the comcast cablemodem, I have my FC4 box set to get the information via DHCP for it's network info, and as well, the netgear box similarly. I checked the dhclient-script in its make_resolv_conf() subroutine, and it's *clean*.. i.e. it does what it's supposed to WRT filling in the 'search' field in resolv.conf -- if the field is empty, it won't write the string 'search ' with no value, into resolv.conf (which is invalid and causes `host` to fail. However, apparently sometime after dhclient-script runs, something *else* is adding the empty search string back into resolv.conf such that the line 'search ' (minus the quotes) gets written to resolv.conf, causing failure of `host` and several other related commands. I have no idea what's causing this, and I've *looked* Every time the client updates dhcp, I have to go manually edit resolv.conf to remove the erroneous blank search line. Version-Release number of selected component (if applicable): dhcp-3.0.2-22.FC4, dhclient-3.0.2-22.FC4 How reproducible: Always Steps to Reproduce: 1. service network restart Actual Results: resolv.conf is populated with a 'search ' line that has no domain following it Expected Results: if the search domain is empty, whatever it is, shouldn't be writing "search " into resolv.conf, but it should either leave the line completely blank or not write anything at all. Additional info: I'll be happy to try and figure out which program/script is causing the problem if someone can just tell me how to log which apps are run in sequence, when started by a given process (such as service network restart)
Do you use NetworkManager ? ie. does 'chkconfig --list NetworkManager' report 'on' for any runlevel ? If so, it is responsible for writing resolv.conf, not dhclient. No other app / script should be writing resolv.conf, AFAIK. If so, can the problem be reproduced after you 'chkconfig --del NetworkManager'? If not, please move this bug to 'NetworkManager'. If not, or if NetworkManager was not enabled, read on. Do you have an /etc/dhclient*.conf file ? If so, the search / nameserver parameters could be overridden there - what are its contents ? Try removing it: # mv /etc/dhclient*.conf /tmp Please try this, for the ethX interface configured with DHCP: # ifdown ethX # cat /etc/resolv.conf ( should be empty, or have the initial contents you set up before dhclient was enabled. If it contains invalid parameters: # echo -n ''>/etc/resolv.conf ) # rm -f /var/lib/dhcp/dhclient-ethX.leases ( ensure selinux is in "Permissive" mode, or you won't see any output from the next command: # setenforce 0 ) # dhclient -1 \ -pf /var/run/dhclient-ethX.pid \ -lf /var/lib/dhcp/dhclient-ethX.leases \ 2>&1 | tee /tmp/dhclient.log when the dhclient command above completes: 1. Is the resolv.conf file correct or invalid ? Please append these files to this bug report after the dhclient command above has completed: /tmp/dhclient.log /etc/resolv.conf /var/lib/dhcp/dhclient-eth0.leases Then we should have enough information to resolve this bug report - thank you.
Created attachment 119084 [details] log from dhclient
Created attachment 119085 [details] resolv.conf file after running above commands
Created attachment 119086 [details] leases file
all well and good except for the following: immediately after having done the above, I tried this: 12:51pm {22} localhost:/root># service network restart Shutting down interface eth0: [ OK ] Shutting down interface wlan0: [ OK ] Shutting down loopback interface: [ OK ] Bringing up loopback interface: [ OK ] Bringing up interface eth0: Determining IP information for eth0... done. localhost [ OK ] 12:58pm {23} localhost:/root># cat /etc/resolv.conf ; generated by /sbin/dhclient-script nameserver 192.168.25.1 search and look, there's the bug. ^^ 'search ' all by itself. Like I said, I'm at a loss to explain how it gets there.
blah, forgot to attach the results of the commands you gave me before pasting the above. Here: 12:43pm {2} localhost:/root># chkconfig --list NetworkManager error reading information on service NetworkManager: No such file or directory 12:43pm {3} localhost:/root># ls /etc/dhclient* ls: No match. 12:49pm {15} localhost:/root># ifdown eth0 12:49pm {16} localhost:/root># cat /etc/resolv.conf ; generated by /sbin/dhclient-script nameserver 192.168.25.1 12:49pm {17} localhost:/root># rm -f /var/lib/dhcp/dhclient-eth0.leases 12:49pm {18} localhost:/root># setenforce 0 setenforce: SELinux is disabled 12:50pm {19} localhost:/root># dhclient -1 \ ? -pf /var/run/dhclient-ethX.pid \ ? -lf /var/lib/dhcp/dhclient-ethX.leases \ ? 2>&1 | tee /tmp/dhclient.log Ambiguous output redirect. 12:50pm {20} localhost:/root># bash Wed Sep 21 12:50:39 EDT 2005 [root@localhost ~]# dhclient -1 \ > -pf /var/run/dhclient-ethX.pid \ > -lf /var/lib/dhcp/dhclient-ethX.leases \ > 2>&1 | tee /tmp/dhclient.log Internet Systems Consortium DHCP Client V3.0.2-RedHat Copyright 2004 Internet Systems Consortium. All rights reserved. For info, please visit http://www.isc.org/products/DHCP /sbin/dhclient-script: configuration for eth1 not found. Continuing with defaults. /etc/sysconfig/network-scripts/network-functions: line 51: eth1: No such file or directory Listening on LPF/eth1/00:e0:18:a7:73:5e Sending on LPF/eth1/00:e0:18:a7:73:5e Listening on LPF/eth0/00:20:18:d9:48:1e Sending on LPF/eth0/00:20:18:d9:48:1e Listening on LPF/wlan0/00:12:17:71:a8:86 Sending on LPF/wlan0/00:12:17:71:a8:86 Sending on Socket/fallback DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 5 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 6 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 5 ip length 314 disagrees with bytes received 534. accepting packet with data after udp payload. DHCPOFFER from 192.168.25.1 DHCPREQUEST on eth0 to 255.255.255.255 port 67 ip length 314 disagrees with bytes received 534. accepting packet with data after udp payload. DHCPOFFER from 192.168.25.1 DHCPREQUEST on wlan0 to 255.255.255.255 port 67 ip length 314 disagrees with bytes received 534. accepting packet with data after udp payload. DHCPACK from 192.168.25.1 bound to 192.168.25.4 -- renewal in 32577 seconds. [root@localhost ~]# exit exit 12:50pm {21} localhost:/root># cat /etc/resolv.conf ; generated by /sbin/dhclient-script nameserver 192.168.25.1 as you can see, this works as expected, however see above.
Your DHCP servers, on both eth1 and wlan0, are NOT supplying the 'domain-name' option, so dhclient will not write it. Neither do your dhcp servers set the dhcp host-name option. I think I may have found the problem : is your hostname not set ? Or - does the problem disappear when you put "HOSTNAME=myhostname" in /etc/sysconfig/network-scripts ? (where "myhostname" is the name you want to give your host). The problem is in /etc/sysconfig/network-scripts/ifup-post, which does: # don't set hostname on ppp/slip connections if [ "$2" = "boot" -a \ "${DEVICE}" != lo -a \ "${DEVICETYPE}" != "ppp" -a \ "${DEVICETYPE}" != "slip" ]; then if need_hostname; then IPADDR=`LANG= LC_ALL= ifconfig ${DEVICE} | grep 'inet addr' | awk -F: '{ print $2 } ' | awk '{ print $1 }'` eval `/bin/ipcalc --silent --hostname ${IPADDR}` if [ "$?" = "0" ]; then set_hostname $HOSTNAME fi fi fi ie., if, after all the network scripts have been parsed for 'HOSTNAME=' or 'DNS=' or 'DOMAIN=' settings, and DHCP has brought up the interface (possibly setting the hostname and search path), the hostname is still unset, the ifup-post script will do a DNS lookup and unconditionally set the hostname . After you've done a service network restart, what is your hostname set to ? What is the output of the command: # ipcalc --silent --hostname $IP where $IP is the address of the interface that was brought up with DHCP (eth0)? The problem is in /etc/sysconfig/network-scripts/network-functions, which unconditionally sets the search path in resolv.conf to a possibly empty search list: set_hostname () { hostname $1 if ! grep search /etc/resolv.conf >/dev/null 2>&1; then domain=`echo $1 | sed 's/^[^\.]*\.//'` rsctmp=`mktemp /tmp/XXXXXX`; cat /etc/resolv.conf > $rsctmp echo "search $domain" >> $rsctmp change_resolv_conf $rsctmp /bin/rm -f $rsctmp fi } The problem here is that the argument to this function may be empty, or may not contain any '.'s . If it does not contain any '.'s, then the invalid line 'search ' is added to resolv.conf, if the dhclient did not receive any 'domain-name' option and resolv.conf contains no existing 'search' path - I'll raise a bug to get this fixed in initscripts. If adding the HOSTNAME=myhostname to /etc/sysconfig/network does not resolve your problem, please read on. I made a mistake with the dhclient command above - you should have appended the interface name - ie ran 'dhclient ... eth0' - sorry. dhclient' ran for for eth1 which has no /etc/sysconfig/network-scripts/ifcfg-eth1 file, so the 'service network restart' command only brings up interface eth0. Please could you retry for eth0: # service network stop # ifup lo # rm -f /var/lib/dhclient-eth0.leases # echo -n '' > /etc/resolv.conf # dhclient -1 \ -pf /var/run/dhclient-ethX.pid \ -lf /var/lib/dhcp/dhclient-ethX.leases \ eth0 \ 2>&1 | tee /tmp/dhclient.log And then please append the contents of the /etc/resolv.conf, the /var/lib/dhcp/dhclient-eth0.leases file, and the output of 'hostname' and 'domainname' to this bug report - thank you.
This text above: > does the problem disappear when you put "HOSTNAME=myhostname" > in /etc/sysconfig/network-scripts should read: > does the problem disappear when you put "HOSTNAME=myhostname" > in /etc/sysconfig/network ^^^^^^^ IE. if you set the HOSTNAME= in /etc/sysconfig/network, the problem should disappear, and no 'search' option will be written to resolv.conf, since none was specified by the dhcp server. If possible, get your dhcp server to send the domain-name option (and possibly the host-name option). If you cannot control what your dhcp server sends, then add this line to /etc/dhclient.conf: ' default domain-name "my search path"; ' - then dhclient would write ' search my search path ' to /etc/resolv.conf. If neither of the above solutions are sufficient, then please follow instructions above for gathering the 'dhclient eth0' session info. Thanks!
This problem can be resolved by: o Getting your dhcp server to supply the 'host-name' and / or 'domain-name' options OR o Putting the HOSTNAME='myhostname' option in /etc/sysconfig/network OR o Adding a mapping between the IP address you get on eth0 and your chosen hostname to /etc/hosts: '192.168.25.4 myhostname.my.domain myhostname ' As such, it is not due to any bug in dhcp, but due to misconfiguration . The bug about /etc/sysconfig/network-scripts/network-functions creating an empty 'search ' path when no host name is configured and no host-name or domain-name are sent by DHCP will be fixed in a future release of initscripts - but the root cause is not configuring any host name or domain name for the host.