Bug 469301

Summary: NetworkManager does NOT work just as /sbin/dhclient-script
Product: [Fedora] Fedora Reporter: Baif <baif>
Component: NetworkManagerAssignee: Dan Williams <dcbw>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 10CC: arxs, dcbw, wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-05-22 00:34:11 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:

Description Baif 2008-10-31 06:54:39 UTC
Description of problem:
NetworkManager does NOT work just as /sbin/dhclient-script.
There are some info provided by my DHCP server. It seems that NetworkManager does NOT get it. 

If there is a issue comes from my DHCP server , why does "/sbin/dhclient-script" work well?

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

NetworkManager-gnome-0.7.0-0.11.svn4229.fc10.x86_64
NetworkManager-glib-0.7.0-0.11.svn4229.fc10.x86_64
NetworkManager-0.7.0-0.11.svn4229.fc10.x86_64


How reproducible:
Enable ONLY one of "service network" and "service  NetworkManager".

Steps to Reproduce:
1."service NetworkManager stop"
2."service network start"; cat /etc/resolve.conf
3.verse vies...
  
Actual results:

root@baifmt30 995 0 CST Fri 2008/10/31 14:31:35 ~
# service NetworkManager stop
Stopping NetworkManager daemon:                            [  OK  ]
root@baifmt30 996 0 CST Fri 2008/10/31 14:31:43 ~
# service network restart
Shutting down loopback interface:                          [  OK  ]
FATAL: Module off not found.
Bringing up loopback interface:                            [  OK  ]
Bringing up interface eth0:
Determining IP information for eth0... done.
                                                           [  OK  ]
FATAL: Module off not found.
root@baifmt30 997 0 CST Fri 2008/10/31 14:31:49 ~
#***====================================================***
# cat /etc/resolv.conf
; generated by /sbin/dhclient-script
search office.net ks.net
nameserver 192.168.0.2
nameserver 210.22.70.3
nameserver 168.95.1.1
#***====================================================***
root@baifmt30 998 0 CST Fri 2008/10/31 14:31:52 ~
# service NetworkManager restart
Stopping NetworkManager daemon:                            [FAILED]
Setting network parameters...                              [  OK  ]
Starting NetworkManager daemon:                            [  OK  ]
root@baifmt30 999 0 CST Fri 2008/10/31 14:32:04 ~
#***====================================================***
# cat /etc/resolv.conf
# generated by NetworkManager, do not edit!

nameserver 210.22.70.3
nameserver 168.95.1.1
#***====================================================***


Expected results:
The item should be the same...

Comment 1 Dan Williams 2008-10-31 15:54:01 UTC
AT the top of /sbin/dhclient-script, can you put "env > /tmp/dhclient-env.txt" and attach the result (as a private attachment if you like)?

Comment 2 Dan Williams 2008-10-31 15:54:49 UTC
And when I said "at the top", I really meant right before the line:

PATH=/bin:/sbin

not at the very top of the file.  Thanks!

Comment 3 Baif 2008-11-01 14:29:48 UTC
OK. I got it. 
    21 # address if it is not supplied. This might be much more easily done
    22 # by the dhclient C code, and passed on.
    23 
+   env > /tmp/dhclient-env.txt
    24 PATH=/bin:/usr/bin
    25 
    26 function save_previous() {
    27     if [ -e $1 ]; then
    28         mv $1 $1.predhclient
    29     else
    30         echo ''> $1.predhclient
    31     fi
    32 }
=============================
Am I right? I have to test it in my office and now it's my Saturday night...

Comment 4 Dan Williams 2008-11-03 00:51:27 UTC
Yeah, that looks right.

Comment 5 Baif 2008-11-03 01:38:25 UTC
$ less dhclient-env.txt
new_subnet_mask=255.255.255.0
new_server_name=ks.ks.net
new_ip_address=192.168.0.162
new_network_number=192.168.0.0
interface=eth0
reason=REBOOT
new_expiry=1225704939
new_dhcp_lease_time=28800
pid=28738
new_dhcp_server_identifier=192.168.0.1
PWD=/etc/sysconfig/network-scripts
new_routers=192.168.0.254
new_domain_name_servers=210.22.70.3 168.95.1.1
SHLVL=1
new_dhcp_message_type=5
new_broadcast_address=192.168.0.255
new_filename=pxelinux.0
_=/bin/env

Comment 6 Baif 2008-11-03 01:41:32 UTC
It's very wired. Toddy I tested the "service   NetworkManager","service network " restart , stop, start. I found NetworkManager will get the right DHCP configs, but the dhclinet will NOT.

Comment 7 Bug Zapper 2008-11-26 04:32:01 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 8 Dan Williams 2009-02-14 12:38:20 UTC
So it looks like NM is correctly using the values directly from the DHCP response; we need to figure out where these are coming from:

search office.net ks.net
nameserver 192.168.0.2

Have you customized the network configuration using system-config-network at all?  What's the contents of any ifcfg files in /etc/sysconfig/network-scripts/ like ifcfg-eth0, etc?

Comment 9 Niels Haase 2009-04-10 22:38:26 UTC
Reporter, could you please reply to the previous question? If you won't reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 10 Niels Haase 2009-05-22 00:34:11 UTC
Since there are insufficient details provided in this report for us to investigate the issue further, and we have not received feedback to the information we have requested above, we will assume the problem was not reproducible, or has been fixed in one of the updates we have released for the reporter's distribution.

Users who have experienced this problem are encouraged to upgrade to the latest update of their distribution, and if this issue turns out to still be reproducible in the latest update, please reopen this bug with additional information.

Closing as INSUFFICIENT_DATA.