This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 473658 - /sbin/dhclient-script non-functional, network does not start
/sbin/dhclient-script non-functional, network does not start
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: dhcp (Show other bugs)
10
All Linux
medium Severity high
: ---
: ---
Assigned To: David Cantrell
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-29 15:17 EST by dann
Modified: 2013-02-08 14:01 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 02:02:08 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description dann 2008-11-29 15:17:10 EST
Description of problem:
Doing: ifup eth0
This happens:
Determining IP information for eth0...Nothing to flush.
Nothing to flush.
RTNETLINK answers: No such process
 done.
RTNETLINK answers: Network is down

Replacing /sbin/dhclient-script with the version from an F9 machine 
from dhclient-4.0.0-18.fc9.i386 makes everything work correctly.


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

dhclient-4.0.0-30.fc10.i386

How reproducible:
Always

Steps to Reproduce:
1. run ifup eth0
2.
3.
  
Actual results:
The network is not setup properly

Expected results:
It should be setup properly.

Additional info:
Comment 1 Patrice Dumas 2008-12-01 08:44:50 EST
I can confirm I get something similar. In that case, the next attempt succeeds.
In /var/log/message, there is:

Dec  1 14:30:42 localhost kernel: ADDRCONF(NETDEV_UP): eth0: link is not ready
Dec  1 14:30:42 localhost kernel: e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
Dec  1 14:30:42 localhost kernel: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Dec  1 14:30:42 localhost dhclient: Listening on LPF/eth0/00:0f:1f:cc:4a:96
Dec  1 14:30:42 localhost dhclient: Sending on   LPF/eth0/00:0f:1f:cc:4a:96
Dec  1 14:30:42 localhost dhclient: Sending on   Socket/fallback
Dec  1 14:30:46 localhost dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
Dec  1 14:30:46 localhost dhclient: DHCPOFFER from 193.51.120.249
Dec  1 14:30:46 localhost dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67
Dec  1 14:30:46 localhost dhclient: DHCPACK from 193.51.120.249
Dec  1 14:30:46 localhost NET: dhclient: failed to create default route: 193.51.120.103 dev eth0 
Dec  1 14:30:46 localhost NET[23454]: /sbin/dhclient-script : updated /etc/resolv.conf
Dec  1 14:30:46 localhost dhclient: bound to 193.51.120.183 -- renewal in 10022 seconds.
Dec  1 14:30:46 localhost dhclient: receive_packet failed on eth0: Network is down
Comment 2 David Cantrell 2008-12-03 22:39:08 EST
Are you using SELinux in enforcing or permissive mode?  What happens if you run these commands at a shell:

ifdown eth0
dhclient -v -d eth0

Paste the output from the dhclient command in a comment here.
Comment 3 Oscar Valdez 2009-01-21 10:19:22 EST
I would like to have this bug reopened.

I use profiles with system-config-network, and keep the NetworkManager service stopped at all times.

When I start device wlan0 from system-config-network, I get the following in /var/log/messages:

NET: dhclient: failed to create default route: 192.168.167.30 dev wlan0 
NET[3612]: /sbin/dhclient-script : updated /etc/resolv.conf

If I run dhclient -v -d eth0 at a shell, the default route is created. The output is as follows:

/var/lib/dhclient/dhclient.leases line 17: semicolon expected.
}
 ^
/var/lib/dhclient/dhclient.leases line 17: unterminated lease declaration.
}
 ^
Listening on LPF/wlan0/00:1a:92:54:d1:bb
Sending on   LPF/wlan0/00:1a:92:54:d1:bb
Sending on   Socket/fallback
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 8
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 16
DHCPOFFER from 192.168.167.53
DHCPREQUEST on wlan0 to 255.255.255.255 port 67
DHCPACK from 192.168.167.53
bound to 192.168.167.210 -- renewal in 417053478 seconds.
Comment 4 David Cantrell 2009-01-21 13:20:31 EST
(In reply to comment #3)
> I would like to have this bug reopened.
> 
> I use profiles with system-config-network, and keep the NetworkManager service
> stopped at all times.
> 
> When I start device wlan0 from system-config-network, I get the following in
> /var/log/messages:
> 
> NET: dhclient: failed to create default route: 192.168.167.30 dev wlan0 
> NET[3612]: /sbin/dhclient-script : updated /etc/resolv.conf
> 
> If I run dhclient -v -d eth0 at a shell, the default route is created. The
> output is as follows:
> 
> /var/lib/dhclient/dhclient.leases line 17: semicolon expected.
> }
>  ^
> /var/lib/dhclient/dhclient.leases line 17: unterminated lease declaration.
> }
>  ^
> Listening on LPF/wlan0/00:1a:92:54:d1:bb
> Sending on   LPF/wlan0/00:1a:92:54:d1:bb
> Sending on   Socket/fallback
> DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 8
> DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 16
> DHCPOFFER from 192.168.167.53
> DHCPREQUEST on wlan0 to 255.255.255.255 port 67
> DHCPACK from 192.168.167.53
> bound to 192.168.167.210 -- renewal in 417053478 seconds.

The original issue discussed in this bug does not pertain to the problem you are having.  Something on your system is invalidating the dhclient.leases file.
Comment 5 Jochen Wiedmann 2009-02-09 01:28:01 EST
Could this be reopened? I have the same problems, exactly since upgrading to F10. My wife, which shares the same network at home, and who is also using F10, doesn't. The problem is indipendent from the network: I observe it at home as well as within the corporate network.

Regarding David's questions from comment 2: SELinux is disabled.

About the commands to run: I do not understand in what state I should run these: After starting dhclient failed?
Comment 6 Jochen Wiedmann 2009-02-09 01:31:24 EST
(In reply to comment #2)

Here's my output from running the above commands after successfully obtaining an IP address:

[jwi@mcjwi ~]$ sudo /etc/sysconfig/network-scripts/ifdown /etc/sysconfig/network-scripts/ifcfg-eth0 
[jwi@mcjwi ~]$ sudo /sbin/dhclient
dhclient         dhclient-script  
[jwi@mcjwi ~]$ sudo /sbin/dhclient -v -d eth0
Internet Systems Consortium DHCP Client 4.0.0
Copyright 2004-2007 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/

Listening on LPF/eth0/00:15:c5:3a:c1:c5
Sending on   LPF/eth0/00:15:c5:3a:c1:c5
Sending on   Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 14
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
DHCPOFFER from 10.29.20.1
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPACK from 10.29.20.1
bound to 10.29.20.103 -- renewal in 173818 seconds.
Comment 7 Jochen Wiedmann 2009-02-09 01:35:05 EST
(In reply to comment #2)

As it happened, after executing the commands from comment #6, I had the same problem again with restarting the network. So, here's the same output, after observing the problem. Doesn't look different to me.


[jwi@mcjwi ~]$ sudo /etc/init.d/network restart
Shutting down loopback interface:                          [  OK  ]
Bringing up loopback interface:                            [  OK  ]
Bringing up interface eth0:  
Determining IP information for eth0...RTNETLINK answers: No such process
 done.
RTNETLINK answers: Network is down
                                                           [  OK  ]
[jwi@mcjwi ~]$ sudo /etc/sysconfig/network-scripts/ifdown /etc/sysconfig/network-scripts/ifcfg-eth0 
[jwi@mcjwi ~]$ sudo /sbin/dhclient -v -d eth0Internet Systems Consortium DHCP Client 4.0.0
Copyright 2004-2007 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/

Listening on LPF/eth0/00:15:c5:3a:c1:c5
Sending on   LPF/eth0/00:15:c5:3a:c1:c5
Sending on   Socket/fallback
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 15
DHCPOFFER from 10.29.20.1
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPACK from 10.29.20.1
bound to 10.29.20.103 -- renewal in 176816 seconds.
Comment 8 Jochen Wiedmann 2009-02-09 01:36:24 EST
A final note: When running /etc/init.d/network restart, as in comment #7, I typically receive an error message that dhclient is already running:

[jwi@mcjwi ~]$ sudo /etc/init.d/network restart
Shutting down loopback interface:                          [  OK  ]
Bringing up loopback interface:                            [  OK  ]
Bringing up interface eth0:  
Determining IP information for eth0...dhclient(4367) 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]
Comment 9 David Cantrell 2009-02-10 02:22:55 EST
Reopening the bug so I can evaluate it again.  Please bear with me as I need to set up an F-10 debugging environment for this problem.
Comment 10 Jochen Wiedmann 2009-02-10 02:29:15 EST
Thanks very much for reopening!
Comment 11 pelle2004 2009-03-15 12:15:24 EDT
I have similar problems with DHCP. 

In my case two kinds of DHCP request are issued to the DHCP server.
One with a assign Host Name and one without. My DHCP server assigned 
these request with different IP (still same MAC). After a period the 
client and the server disagree totally and it end up in the:  

RTNETLINK answers: No such process done.
RTNETLINK answers: Network is down

To get away from this I have to.

1. ifdown eth0
2. echo -n >/var/lib/dhclient/dhclient-eth0.leases
3. ifup eth0

In this case NM=no and ONBOOT=yes 

Workaround for solving the problem was to assigne a fixed IP 
related to the MAC on the DHCP server.

I only have this fault on a Lenova T500 (ICH9 82567LM / e1000e driver)
Noticeable is that after ifdown a DHCP Request is transmitted every
time the Network cable is unplugged/plugged. And it is of the
faulty type without host name record.

Other things

1. Several leases files

/var/lib/dhclient/dhclient-eth0.leases <- Without NW
/var/lib/dhclient/dhclient.leases <- Without NW
/var/lib/dhclient/dhclient-eth0.lease <- With NW

2. dhclient SELinux fault on ~/i18n 

fixed with ->
====
module fix_dhcpc_i18n 1.0;

require {
	type root_t;
	type dhcpc_t;
	type user_home_t;
	type xdm_t;
	type var_spool_t;
	class dir create;
	class file { read unlink };
}

#============= dhcpc_t ==============
allow dhcpc_t user_home_t:file read;
====
Comment 12 Jochen Wiedmann 2009-04-16 01:37:10 EDT
David?
Comment 13 David Cantrell 2009-04-16 03:16:23 EDT
Sorry for the delay.  My development work for F-11 has taken precedence over this bug.  I will post here within a week with an update.

Apologies for the delay.
Comment 14 David Cantrell 2009-04-17 17:08:44 EDT
A fix for this issue will be in dhcp-4.0.0-34.fc10

The update will first appear in the updates-testing collection.  Please test it there to verify it fixes the problem.  Only after verification that it works can I move it to the main updates collection.
Comment 15 Fedora Update System 2009-04-17 17:22:26 EDT
dhcp-4.0.0-34.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/dhcp-4.0.0-34.fc10
Comment 16 Jochen Wiedmann 2009-04-20 01:24:07 EDT
Thanks, David! I can confirm that the updated version works fine for me and fixed this problem.
Comment 17 Fedora Update System 2009-04-21 20:59:29 EDT
dhcp-4.0.0-34.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update dhcp'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-3825
Comment 18 Fedora Update System 2009-06-26 23:01:47 EDT
dhcp-4.0.0-36.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/dhcp-4.0.0-36.fc10
Comment 19 Fedora Update System 2009-07-11 13:09:14 EDT
dhcp-4.0.0-36.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 20 Bug Zapper 2009-11-18 03:00:22 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  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 '10'.

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 10'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 10 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 21 Bug Zapper 2009-12-18 02:02:08 EST
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 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.