Bug 603487
| Summary: | Determining IP information for eth1...dhclient(3999) is already running | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Peter van der Velde <petervandervelde> | ||||||||||||||||
| Component: | NetworkManager | Assignee: | Dan Williams <dcbw> | ||||||||||||||||
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||||||
| Severity: | low | Docs Contact: | |||||||||||||||||
| Priority: | low | ||||||||||||||||||
| Version: | 13 | CC: | dcbw, harald, jklimes, jmoskovc, jpopelka, sdickson | ||||||||||||||||
| Target Milestone: | --- | ||||||||||||||||||
| Target Release: | --- | ||||||||||||||||||
| Hardware: | i386 | ||||||||||||||||||
| OS: | Linux | ||||||||||||||||||
| URL: | http://www.isl.uiuc.edu/~sdickson | ||||||||||||||||||
| Whiteboard: | |||||||||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||||||||
| Doc Text: | Story Points: | --- | |||||||||||||||||
| Clone Of: | 461370 | Environment: | |||||||||||||||||
| Last Closed: | 2011-06-27 18:07:29 UTC | Type: | --- | ||||||||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||||||||
| Documentation: | --- | CRM: | |||||||||||||||||
| Verified Versions: | Category: | --- | |||||||||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||||||
| Embargoed: | |||||||||||||||||||
| Attachments: |
|
||||||||||||||||||
|
Description
Peter van der Velde
2010-06-13 13:10:59 UTC
closing the lid of my laptop and opening it again does the trick. Extra note: laptop doesn't suspend when closing the lid(closing is detected(sound is played)) If you need extra info please do contact me. For sure not a system-config-network problem. The "dhclient(PID) is already running - exiting." message comes from dhclient when something (NM, initscripts) tries to start dhclient using (-pf pidfile) the same pidfile as the already running dhclient. Let's pass this to NM. Peter, can you show us what's in your /var/log/messages when you close and open the lid. You can attach the file to this bug report. Thanks [root@lindapc ~]# service network restart
Shutting down interface eth0: [ OK ]
Shutting down loopback interface: [ OK ]
Bringing up loopback interface: [ OK ]
Bringing up interface eth0:
Determining IP information for eth0... failed; no link present. Check cable?
[FAILED]
Bringing up interface wlan0: RTNETLINK answers: Operation not possible due to RF-kill
Error for wireless request "Set Encode" (8B2A) :
SET failed on device wlan0 ; Invalid argument.
Determining IP information for wlan0...dhclient(1298) is already running - exiting.
This version of ISC DHCP is based on the release available
on ftp.isc.org. Features have been added and other changes
have been made to the base software release in order to make
it work better with this distribution.
Please report for this software via the Red Hat Bugzilla site:
http://bugzilla.redhat.com
exiting.
failed.
[FAILED]
[root@lindapc ~]#
Created attachment 424034 [details]
/var/log/messages
By the way I noticed just waiting for the laptop to go into standby(it doesn't suspend unfortunally) has the same effect as closing the lid. [root@lindapc /]# ps -ef | grep net
root 13 2 0 16:14 ? 00:00:00 [netns]
Linda 2230 1 0 16:15 ? 00:00:00 /usr/bin/knetworkmanager
root 2660 2397 0 16:49 pts/1 00:00:00 grep net
[root@lindapc /]# ps -ef | grep dh
root 1279 1 0 16:14 ? 00:00:00 /sbin/dhclient -H 192.168.1.1 -1 -q -lf /var/lib/dhclient/dhclient-wlan0.leases -pf /var/run/dhclient-wlan0.pid wlan0
root 2728 2397 0 16:55 pts/1 00:00:00 grep dh
[root@lindapc /]# 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... failed; no link present. Check cable?
[FAILED]
Bringing up interface wlan0: Error for wireless request "Set Encode" (8B2A) :
SET failed on device wlan0 ; Invalid argument.
Determining IP information for wlan0... done.
[ OK ]
[root@lindapc /]#
Peter, you shouldn't need to run 'service network restart' when NetworkManager is running, since NM should be handling the networking. Is there some reason you need to do that? If you're trying to get networking back after resume or startup and NetworkManager isn't able to do that, then we should figure out what's the problem with NM. I noticed your /var/log/messages doesn't include any information from NetworkManager, are you sure it's running at that point? 'ps -ef | grep Net' (capital N) will tell you. I could not get my wireless up with nm. I've attached my /var/log/messages trying with nm. Created attachment 424255 [details]
/var/log/messages2
With nm on
Created attachment 424547 [details]
With correct WEP key
I noticed an error on the wep key length, fixed that but still no connection with nm. Without nm management on the interface it's up and running. It complains in the logfile about the mac address...
I noticed that you had NM_CONTROLLED set to "no" in ifcfg files which tells NM to ignore the connection. In later logs the variable is not there any more, so NM can try to connect. The "error: Invalid WEP key length" indicates problem with WEP key. There were some problems with WEP key in NM. What type of key do you use? There are basically 3 types of WEP key: 1) hexadecimal key: string of 10 of 26 hex characters 2) ascii key: 5 or 13 characters long string (it is prefixed with s: for use with iwconfig in ifcfg file) 3) WEP passphrase: string up to 63 chars. It is hashed to get actual WEP key. Could you post your ifcfg-eth0, ifcfg-wlan0, and keys-wlan0. When obfuscating the key, change just characters and not length, not to confuse that. Anyway, Peter, could you describe what you want to achieve and what's your actual problem? I want to achieve a wireless network connection which stays connected and comes up after opening the lid. This was no issue before(using vista on this laptop, I finally got my girlfriend to switch to linux ;-)). With NM it wont connect at all (after putting 0x in front of the key the WEP length error dissapears that could be checked in the UI ;-)). Without NM I can get it up but it disconnects after a while(RTNETLINK answers: Operation not possible due to RF-kill Error for wireless request "Set Encode" (8B2A) : SET failed on device wlan0 ; Invalid argument. Determining IP information for wlan0...dhclient(1298) is already running - exiting. ) and wont get up. After closing the lid and opening it again(some hours in between) it wont come up either, only a restart fixes it. I will post my config after saving this message. Created attachment 425962 [details]
keys-wlan0
Created attachment 425963 [details]
wlan0
Created attachment 425964 [details]
eth0
After installing updates I retried setting the networkmanager on. And it works! I hope the connections stays alive and gets restored after closing the lid for several hours. Unfortunately the connection isn't 100% stable. It disconnects without any apparent reason. Rebooting is the only option then. I will add my /var/log/messages. Created attachment 427260 [details]
/var/log/messages3
> Jun 27 17:21:19 lindapc kernel: b43-phy0: Radio hardware status changed to DISABLED > Jun 27 17:21:19 lindapc NetworkManager[1413]: <info> WiFi now disabled by radio killswitch > Jun 27 17:21:19 lindapc kernel: b43-phy0: Radio turned on by software > Jun 27 17:21:19 lindapc kernel: b43-phy0: The hardware RF-kill button still turns the radio physically off. Press the button to turn it on. WiFi gets turned off by killswitch (probably due to closing the lid). Searching on this a bit, it seems that there are some problems with drivers related to killswitch lately. As per bug #606249, could you try to blacklist hp-wmi platform driver? (in /etc/modprobe.d/blacklist.conf) Other possibly related reports: bug #591226 bug #573224 What laptop do you use? What is output of 'rfkill list' when the problem appears? I've blacklisted hp-wmi
After a while the problem occurs again:
[Linda@lindapc ~]$ rfkill list
0: phy0: Wireless LAN
Soft blocked: no
Hard blocked: yes
[Linda@lindapc ~]$
Pressing the wifi button has no effect.(it's blue like its on otherwise it turns orange)
It's a compaq presario c700.
(In reply to comment #20) > I've blacklisted hp-wmi > > After a while the problem occurs again: > > [Linda@lindapc ~]$ rfkill list > 0: phy0: Wireless LAN > Soft blocked: no > Hard blocked: yes > [Linda@lindapc ~]$ > > Pressing the wifi button has no effect.(it's blue like its on otherwise it > turns orange) > It's a compaq presario c700. That's a kernel bug and should get filed separately so that it can be fixed kernel-side... This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. |