Bug 603487 - Determining IP information for eth1...dhclient(3999) is already running
Determining IP information for eth1...dhclient(3999) is already running
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
13
i386 Linux
low Severity low
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
http://www.isl.uiuc.edu/~sdickson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-13 09:10 EDT by Peter van der Velde
Modified: 2011-06-27 14:07 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 461370
Environment:
Last Closed: 2011-06-27 14:07:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
/var/log/messages (908.18 KB, application/octet-stream)
2010-06-15 01:08 EDT, Peter van der Velde
no flags Details
/var/log/messages2 (1.07 MB, application/octet-stream)
2010-06-15 14:21 EDT, Peter van der Velde
no flags Details
With correct WEP key (1.35 MB, application/octet-stream)
2010-06-16 14:25 EDT, Peter van der Velde
no flags Details
keys-wlan0 (31 bytes, application/octet-stream)
2010-06-22 10:57 EDT, Peter van der Velde
no flags Details
wlan0 (385 bytes, application/octet-stream)
2010-06-22 10:57 EDT, Peter van der Velde
no flags Details
eth0 (315 bytes, application/octet-stream)
2010-06-22 10:58 EDT, Peter van der Velde
no flags Details
/var/log/messages3 (290.42 KB, application/octet-stream)
2010-06-27 16:48 EDT, Peter van der Velde
no flags Details

  None (edit)
Description Peter van der Velde 2010-06-13 09:10:59 EDT
+++ This bug was initially created as a clone of Bug #461370 +++

Description of problem:
This may have been after system had hibernated and revived.

Version-Release number of selected component (if applicable):
1.5.10

How reproducible:
eth1 -> deactivate;  eth1 -> activate succeeded (second attempt)

Steps to Reproduce:
1. In:  Network Configuration  system-config-network 1.5.10
2. Device eth1 Wireless is marked inactive
3. Select: eth1 -> activate:
  
Actual results:

Determining IP information for eth1...dhclient(3999) 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.

And yet, dhclient(3999) is apparently not effective:
ping bugzilla.redhat.com
ping: unknown host bugzilla.redhat.com


Expected results:


Additional info:

--- Additional comment from harald@redhat.com on 2008-09-07 05:00:09 EDT ---

Is NetworkManager running?

--- Additional comment from sdickson@uiuc.edu on 2008-09-07 13:05:50 EDT ---

Ooh, good question.  I didn't make note of every process running.  I just collected what I thought of at the time.  This particular system has some legacy weirdness, left over from my Internet driver battles I had in Fedora Core 7.
Apparently fc9 didn't overwrite the drivers.  Also, the current bug is not easily reproducible -- As I said, I can probably reproduce it by hibernating the system with the Network still active, then bringing it back.  I'll do that again, next.
(This stuff all works so nicely in MacOS-X/Darwin. :)  On a PPC notebook. I'll be trying X86_64 version next.  We'll see...)   :)  

For example:
In: /var/log/messages:
> Sep  7 11:29:35 localhost kernel: Broadcom 43xx-legacy driver loaded [ Features:
 PLRID, Firmware-ID: FW10 ]
fc9 did remind me to upgrade b43 and b43legacy firmware, which I did.
> Sep  7 11:29:35 localhost kernel: udev: renamed network interface wlan0 to eth1
Hmmm, this sounds suspiciously like ndiswrapper and WPC54G_driver_utility (eth2)
> Sep  7 11:30:27 localhost nm-system-settings:    ifcfg-fedora: parsing /etc/sysconfig/network-scripts/ifcfg-eth2 ... 
> Sep  7 11:30:27 localhost nm-system-settings:    ifcfg-fedora:     error: Missing SSID
> Sep  7 11:30:27 localhost nm-system-settings:    ifcfg-fedora: parsing /etc/sysconfig/network-scripts/ifcfg-eth1 ... 
> Sep  7 11:30:27 localhost nm-system-settings:    ifcfg-fedora:     error: Missing SSID
> Sep  7 11:30:27 localhost nm-system-settings:    ifcfg-fedora: parsing /etc/sysconfig/network-scripts/ifcfg-eth0 ... 
> Sep  7 11:30:27 localhost nm-system-settings:    ifcfg-fedora:     read connection 'System eth0'
> Sep  7 11:30:27 localhost nm-system-settings:    ifcfg-fedora: parsing /etc/sysconfig/network-scripts/ifcfg-lo ... 
>Sep  7 11:30:27 localhost nm-system-settings:    ifcfg-fedora:     error: Ignoring loopback device config.
...
> Sep  7 11:31:48 localhost kernel: b43legacy-phy0: Loading firmware version 0x127, patch level 14 (2005-04-18 02:36:27)
> Sep  7 11:31:48 localhost kernel: Registered led device: b43legacy-phy0:radio
> Sep  7 11:31:48 localhost kernel: ADDRCONF(NETDEV_UP): eth1: link is not ready
> Sep  7 11:31:49 localhost kernel: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
> Sep  7 11:31:51 localhost dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 67
> Sep  7 11:31:51 localhost avahi-daemon[2101]: Registering new address record for fe80::290:4bff:fe4b:73b6 on eth1.*.
> Sep  7 11:31:51 localhost dhclient: DHCPACK from 192.168.1.1
> Sep  7 11:31:51 localhost avahi-daemon[2101]: Joining mDNS multicast group on interface eth1.IPv4 with address 192.168.1.104.
> Sep  7 11:31:51 localhost avahi-daemon[2101]: New relevant interface eth1.IPv4 for mDNS.
> Sep  7 11:31:51 localhost avahi-daemon[2101]: Registering new address record for 192.168.1.104 on eth1.IPv4.
> Sep  7 11:31:51 localhost kernel: type=1400 audit(1220805111.208:4): avc:  denied  { write } for  pid=3126 comm="cp" name="resolv.conf.predhclient.eth1" dev=sda3 ino=2463784 scontext=unconfined_u:system_r:dhcpc_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:etc_t:s0 tclass=file

--- Additional comment from sdickson@uiuc.edu on 2008-09-07 14:23:09 EDT ---

Ok, here's the compleat test.
hibernated system -> revived

system-config-network -> eth1 is marked active

ps -edf | grep -i network
dickson   2907     1  0 11:31 ?        00:00:00 /usr/bin/system-config-network
root      2908  2907  0 11:31 ?        00:00:00 /usr/sbin/userhelper -w system-config-network
root      2914  2908  0 11:31 ?        00:00:04 /usr/bin/python /usr/sbin/system-config-network-gui
root     20352  4086  0 13:07 pts/0    00:00:00 grep -i network

ping bugzilla.redhat.com
ping: unknown host bugzilla.redhat.com

eth1 -> deactivate
eth1 -> activate

ping bugzilla.redhat.com
PING bugzilla.redhat.com (209.132.176.231) 56(84) bytes of data.
64 bytes from bugzilla.redhat.com (209.132.176.231): icmp_seq=1 ttl=111 time=140 ms

In the past -- and probably still now, when changing ISP/Wifi source, I have to
delete interface eth1 and rebuild it to get it to work.  Cheers,  -Stewart
http://us.imdb.com/Name?Stewart+Dickson   http://emsh.calarts.edu/~mathart/MathArt_siteMap.html

--- Additional comment from jmoskovc@redhat.com on 2008-11-28 08:46:21 EST ---

This sounds more like problem with NM or dhclient - that they are not able to revive connection after suspend. Does this problem still persist? I can't reproduce it - my connection is properly revived after hibernate or suspend.

Jirka

--- Additional comment from fedora-triage-list@redhat.com on 2009-06-09 22:38:33 EDT ---


This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  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 '9'.

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 9'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 9 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

--- Additional comment from fedora-triage-list@redhat.com on 2009-07-14 12:58:53 EDT ---


Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 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.
Comment 1 Peter van der Velde 2010-06-13 09:14:12 EDT
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.
Comment 2 Jiri Popelka 2010-06-14 06:27:00 EDT
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
Comment 3 Peter van der Velde 2010-06-15 01:02:55 EDT
[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 ~]#
Comment 4 Peter van der Velde 2010-06-15 01:08:32 EDT
Created attachment 424034 [details]
/var/log/messages
Comment 5 Peter van der Velde 2010-06-15 01:15:54 EDT
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.
Comment 6 Peter van der Velde 2010-06-15 10:58:08 EDT
[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 /]#
Comment 7 Dan Williams 2010-06-15 12:18:29 EDT
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.
Comment 8 Peter van der Velde 2010-06-15 14:20:58 EDT
I could not get my wireless up with nm. I've attached my /var/log/messages trying with nm.
Comment 9 Peter van der Velde 2010-06-15 14:21:56 EDT
Created attachment 424255 [details]
/var/log/messages2

With nm on
Comment 10 Peter van der Velde 2010-06-16 14:25:59 EDT
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...
Comment 11 Jirka Klimes 2010-06-21 05:21:43 EDT
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?
Comment 12 Peter van der Velde 2010-06-22 10:49:19 EDT
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.
Comment 13 Peter van der Velde 2010-06-22 10:57:23 EDT
Created attachment 425962 [details]
keys-wlan0
Comment 14 Peter van der Velde 2010-06-22 10:57:54 EDT
Created attachment 425963 [details]
wlan0
Comment 15 Peter van der Velde 2010-06-22 10:58:59 EDT
Created attachment 425964 [details]
eth0
Comment 16 Peter van der Velde 2010-06-22 11:19:33 EDT
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.
Comment 17 Peter van der Velde 2010-06-27 16:46:43 EDT
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.
Comment 18 Peter van der Velde 2010-06-27 16:48:33 EDT
Created attachment 427260 [details]
/var/log/messages3
Comment 19 Jirka Klimes 2010-06-28 08:36:36 EDT
> 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?
Comment 20 Peter van der Velde 2010-06-29 01:15:31 EDT
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.
Comment 21 Dan Williams 2010-08-17 12:39:18 EDT
(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...
Comment 22 Bug Zapper 2011-06-02 07:03:39 EDT
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
Comment 23 Bug Zapper 2011-06-27 14:07:29 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.