+++ 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 ?
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.
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.
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 ?
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?
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 **
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.
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.
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?
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.
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
Should be long-fixed; if the connection is a system connection from an ifcfg file, NM will honor it before login.