Bug 441596 - NetworkManager disables wired ethernet at log out, before login
NetworkManager disables wired ethernet at log out, before login
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
9
i686 Linux
low Severity medium
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
:
Depends On: 385821
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-08 17:21 EDT by David Timms
Modified: 2008-10-11 16:19 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-10-11 16:19:22 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/message indicating NM trouble bzip2ed (66.02 KB, application/octet-stream)
2008-04-28 18:50 EDT, David Timms
no flags Details
shows a boot with NM fail to start (69.40 KB, text/plain)
2008-04-29 09:14 EDT, David Timms
no flags Details
A NM trace from messages. (68.62 KB, text/plain)
2008-05-01 08:22 EDT, David Timms
no flags Details

  None (edit)
Description David Timms 2008-04-08 17:21:59 EDT
+++ This bug was initially created as a clone of Bug #385821 +++

Description of problem:
Network manager unsets the wired ethernet settings when the user logs out.

Version-Release number of selected component (if applicable):
0.7.0-0.9.1.svn3521.fc9

How reproducible:
Yes.

Steps to Reproduce:
1. Laptop network configured to use DHCP, and start eth0 interface on boot
2. NM and NM-Dispatcher running for levels 3,4,5.
3. eth wire connected.
4. boot machine
  - ping it's server assigned dhcp address: replies
5. login screen shown
  - no replies
6. login
  - + 20-30 secs: replies.
7. logout
  - no replies !

Expected results:
wireless network should get address immediately card is detected. Network shall
not software disconnect during normal wired operation of the machine.

Additional info:
Network shall assume and keep working with most recent parameters, until a dhcp
lease change gives complete new values {to avoid situations where dns nameserver
 gets set to nothing}.

This potentially also makes sense for wireless connections - eg at home where
the moment the AP is detected, machine gets assigned address and stays connected
until out of range or machine shutdown. Why does login have any effect ?
Comment 1 Dan Williams 2008-04-10 12:09:20 EDT
Please try latest NM in koji/rawhide (svn3549).

Also, have you set up ifcfg files with system-config-network, and are those
connections set NM_CONTROLLED=yes?

NetworkManager will read your ifcfg files for wired & wireless and use those if
available, and those will persist across login/logout.
Comment 2 David Timms 2008-04-28 08:01:27 EDT
Tested with on machine upgraded from F8>F9beta>rawhide
and grabbed following from koji:
NetworkManager-0.7.0-0.9.2.svn3590.fc9.i386
NetworkManager-glib-0.7.0-0.9.2.svn3590.fc9.i386
NetworkManager-gnome-0.7.0-0.9.2.svn3590.fc9.i386

When booting, now eth0 wired:
- iptables activated during boot
- starts responding to ping as gdm {login screen} starts
- stays connected as I log in.
- stays connected as I log out.
- stays connected as I log in again.
So all looks OK.

Interestingly I have:
/etc/sysconfig/network-scripts/ifcfg-eth0.bak
-rw-r--r-- 1 root root 254 2008-04-25 05:50 

cat /etc/sysconfig/network-scripts/ifcfg-eth0.bak 
# Broadcom Corporation NetXtreme BCM5788 Gigabit Ethernet
DEVICE=eth0
ONBOOT=yes
BOOTPROTO=dhcp
HWADDR=00:17:a4:e5:5e:40
TYPE=Ethernet

ie: no "NM_CONTROLLED=yes"

# service network status
Configured devices:
lo davidtdesktop re_melb
Currently active devices:
lo eth0

This is also the same and OK on another machine that was updated
F8>F9preview>rawhide to NM svn3566.
Comment 3 David Timms 2008-04-28 10:58:14 EDT
on 0.9.2.svn3614.fc9.i386 and with NM_CONTROLL=yes. Should the network stay
connected if you are:
- in init 5
- ctrl-alt-F1
- login as user
- su -c '\sbin\telinit 3'   {or 2} ?

It didn't. 

Added NetworkManager to levels 234. Now, I can telinit 3 from gnome and network
stays up. telinit to 2 and network stays up.

Rebooting and appending 2 or 3 on the kernel line, has trouble:
/sbin/service NetworkManager status
NetworkManager dead but pid file exists

/sbin/service NetworkManager stop
/sbin/service NetworkManager restart gets it going, and it gets an address
within a five seconds, and responds to ping.

Like a different bug for that situation, or is that expected ?
Comment 4 Dan Williams 2008-04-28 12:06:48 EDT
David; latest koji builds here:

http://koji.fedoraproject.org/koji/buildinfo?buildID=47429

make NM active at runlevel 2.  You may need to reset priorities though with
chkconfig.  Is there any message in /var/log/messages about NM?  Did NM crash,
perhaps because HAL wasn't up yet?
Comment 5 David Timms 2008-04-28 18:50:39 EDT
Created attachment 304052 [details]
var/log/message indicating NM trouble bzip2ed

(In reply to comment #4)
> David; latest koji builds here:
Yes that's what I was using in comment #3

> make NM active at runlevel 2.
# chkconfig --list NetworkManager
NetworkManager	0:off	1:off	2:on	3:on	4:on	5:on	6:off

> You may need to reset priorities though with chkconfig.
# chkconfig NetworkManager resetpriorities

> Is there any message in /var/log/messages about NM?  Did NM crash,
> perhaps because HAL wasn't up yet?
Yes: I have added some extra debuginfos, and am about to try again, but here is
the log up2 this point: search for ** START **
Comment 6 David Timms 2008-04-29 09:14:28 EDT
Created attachment 304114 [details]
shows a boot with NM fail to start

note: I echoed a message >> to log at the point of service NetworkManager
start.

I see this weird console kit error during the network plug events:
Apr 29 22:51:52 davidtnotebook console-kit-daemon[2273]: WARNING: Couldn't read
/proc/3698/environ: Error reading file '/proc/3698/environ': No such process

It didn't crash with a backtrace like the previous attachment.
Comment 7 David Timms 2008-04-30 10:02:24 EDT
Based on some f-test-list discussion I tried:
# chkconfig haldaemon resetpriorities
# chkconfig NetworkManager resetpriorities

Now:
- NetworkManager doesn't start during normal boot.
- service NetworkManager restart says Failed, OK, OK
- service NetworkManager status
NetworkManager dead but pid file exists

- service haldaemon start, OK.
- service NetworkManager restart says Failed, OK, OK
Now Network manager icon appears and it does it's thing.
Comment 8 Dan Williams 2008-05-01 06:37:35 EDT
Any chance you could grab the /var/log/messages from that attempt?  If NM is
dead (but left a PID) it probably crashed, and we'd need to grab the log to try
to see where it crashed...

Also, which svn version is this?  Latest from koji (svn3623) or something before
that?
Comment 9 David Timms 2008-05-01 08:22:07 EDT
Created attachment 304306 [details]
A NM trace from messages.

# rpm -qa kerne\* Net\* dbu\* hal\*|sort
dbus-1.2.1-1.fc9.i386
dbus-debuginfo-1.2.1-1.fc9.i386
dbus-glib-0.74-6.fc9.i386
dbus-glib-debuginfo-0.74-6.fc9.i386
dbus-libs-1.2.1-1.fc9.i386
dbus-python-0.82.4-2.fc9.i386
dbus-qt-0.70-4.fc9.i386
dbus-x11-1.2.1-1.fc9.i386
hal-0.5.11-0.7.rc2.fc9.i386
hal-cups-utils-0.6.16-3.fc9.i386
hal-debuginfo-0.5.11-0.7.rc2.fc9.i386
hal-info-20080317-6.fc9.noarch
hal-libs-0.5.11-0.7.rc2.fc9.i386
kernel-2.6.24.5-85.fc8.i686
kernel-2.6.25-8.fc9.i686
kernel-devel-2.6.24.5-85.fc8.i686
kernel-devel-2.6.25-8.fc9.i686
kernel-headers-2.6.25-8.fc9.i386
kerneloops-0.10-11.fc9.i386
NetworkManager-0.7.0-0.9.3.svn3623.fc9.i386
NetworkManager-debuginfo-0.7.0-0.9.3.svn3623.fc9.i386
NetworkManager-glib-0.7.0-0.9.3.svn3623.fc9.i386
NetworkManager-gnome-0.7.0-0.9.3.svn3623.fc9.i386
[root@davidtnotebook log]# rpm -Va kerne\* Net\* dbu\* hal\*|sort
[root@davidtnotebook log]# sestatus
SELinux status: 		enabled
SELinuxfs mount:		/selinux
Current mode:			enforcing
Mode from config file:		enforcing
Policy version: 		22
Policy from config file:	targeted

disclaimer: I have been renaming my var/log/messages, before restarting my
notebook. But quite often the clock keeps getting screwed. I can't be 100% sure
that the versions above were active when the preceding NetMan oops occured.
Comment 10 Bug Zapper 2008-05-14 05:09:21 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 11 Dan Williams 2008-10-11 16:19:22 EDT
Should be long-fixed; if the connection is a system connection from an ifcfg file, NM will honor it before login.

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