Bugzilla – Bug 389759
DHCP fails after update to Factory
Last modified: 2008-05-26 20:03:11 UTC
I updated beta1 to Factory yesterday (2008-05-12) via zypper dup. After the update, my wlan card does not get an IP address via DHCP, which worked all the time before. Setting an IP ("ifconfig eth1 $IP"), default route and nameservers manually makes the wlan device working. Therefore I'm quite sure the problem is really a DHCP. Some details: - ipw2100 wlan card - configured for DHCP with YaST (no network manager) - DHCP server is a Linksys router (WRT54GL) - config unchanged - I need wlan for internet access, so this is a critical bug for me ;-) (I'm on a hurry, logs will follow tonight.)
Created attachment 215081 [details] boot.msg
please reboot the system and execute following commands: ifdown eth1 dhcpcd -d eth1 > DHCP-out and append the DHCP-out and /var/lib/dhcpcd/dhcpcd-eth1.info file.
Created attachment 215509 [details] DHCP-out
Created attachment 215510 [details] dhcpcd-eth1.info
To make things more interesting: using ifup and dhcpcd -dd fixes the issue... # ifup eth1 # dhcpcd -dd eth1 Info, eth1: dhcpcd 3.1.9 starting Info, eth1: hardware address = 00:04:23:9a:3e:9a Info, eth1: DUID = 00:01:00:01:0f:bd:dc:5d:00:04:23:9a:3e:9a Info, eth1: broadcasting for a lease Debug, eth1: sending DHCP_DISCOVER with xid 0x614d7768 Debug, eth1: waiting on select for 20 seconds Debug, eth1: got a packet with xid 0x614d7768 Info, eth1: offered 192.168.1.100 from 192.168.1.1 Debug, eth1: sending DHCP_REQUEST with xid 0x614d7768 Debug, eth1: waiting on select for 19 seconds Debug, eth1: got a packet with xid 0x614d7768 Info, eth1: checking 192.168.1.100 is available on attached networks Debug, eth1: sending ARP probe #1 Debug, eth1: sending ARP probe #2 Debug, eth1: sending ARP probe #3 Debug, eth1: sending ARP claim #1 Debug, eth1: sending ARP claim #2 Info, eth1: leased 192.168.1.100 for 86400 seconds Info, eth1: no renewal time supplied, assuming 43200 seconds Info, eth1: no rebind time supplied, assuming 75600 seconds Info, eth1: adding IP address 192.168.1.100/24 Info, eth1: adding default route via 192.168.1.1 metric 0 Info, eth1: adding route to 169.254.0.0/16 metric 0 Debug, eth1: writing /var/lib/dhcpcd/dhcpcd-eth1.info Debug, eth1: waiting on select for 43200 seconds
Please test the newest dhcd package from: ftp.suse.com/pub/people/varkoly/dhcpcd/<arch>
It's at least an improvement, but... # rcnetwork status Checking optional network interfaces: eth0 eth0 IP address: 10.12.80.30/24 running eth1 device: Intel Corporation PRO/Wireless LAN 2100 3B Mini PCI Adapter (rev 04) eth1 DHCP client NOT running bssid=00:14:bf:c9:24:50 ssid=********** id=0 pairwise_cipher=CCMP group_cipher=TKIP key_mgmt=WPA2-PSK wpa_state=COMPLETED dead Checking mandatory network interfaces: lo lo IP address: 127.0.0.1/8 running Checking service network . . . . . . . . . . . . . . . running At least receiving a valid IP is easier now: # dhcpcd eth1 # works IMHO the questions are: - why is no DHCP client running after boot? - with what parameters is dhcpcd called from within the initscript? (would be useful to know for testing)
1. Is there any messages in /var/log/messages why dhcpcd has died? 2. /sbin/dhcpcd -D -K -N -t 999999 -h linux -c \ /etc/sysconfig/network/scripts/dhcpcd-hook eth0
(In reply to comment #8 from Peter Varkoly) > 1. Is there any messages in /var/log/messages why dhcpcd has died? I didn't see any relevant message there, but I found the reason by replacing dhcpcd with a "echo $@ > /tmp/logfile" script ;-) dhcpcd is called this way: dhcpcd -D -N -t 999999 -B -h cboltz -c /etc/sysconfig/network/scripts/dhcpcd-hook eth1 # one line This results in: /sbin/dhcpcd.orig: invalid option -- 'B' It isn't very surprising that dhcpcd dies... The question is where the -B parameter comes from. (a minute later) Found it: /etc/sysconfig/network/dhcp: ## Type: string ## Default: "" # # additional options, e.g. "-B" # DHCLIENT_ADDITIONAL_OPTIONS=" -B" I have no idea why this parameter is there. I doubt I added it myself, but I'm not sure. What I can say for sure: "-B" is there since at least a year (I don't have older backups) and didn't do any harm up to now. BTW: On a 10.2 system, the dhcpcd manpage says: -B Requests broadcast response from DHCP server. The solution for me is obviously to remove the -B (tested, works). The remaining question is where this -B comes from and if it should be removed on update. Please clarify this before closing this bugreport. > 2. /sbin/dhcpcd -D -K -N -t 999999 -h linux -c \ > /etc/sysconfig/network/scripts/dhcpcd-hook eth0 works.
We have done an update. Please read the file /usr/share/doc/packages/dhcpcd-1-vs-3
OK, I see.
Karl, is this something for the release notes? The no longer supported option caused some major headache for me - it would probably be a good idea to save others this experience ;-) @Peter: Is there a way to remove the no longer supported options from sysconfig in an automated way? If so, please do it...
Yes, I'll do it.
I've insert in %post commands to remove not implemented parameters
fixed for STABLE