Bug 328691 - udev renaming wmaster0 to eth1 and clobbering NetworkManager
Summary: udev renaming wmaster0 to eth1 and clobbering NetworkManager
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: udev
Version: 7
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Harald Hoyer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-10-11 23:14 UTC by Jonathan Underwood
Modified: 2007-12-06 20:43 UTC (History)
0 users

Fixed In Version: udev-115-5.20071012git.fc7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-10-22 06:54:54 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Jonathan Underwood 2007-10-11 23:14:05 UTC
Description of problem:
Since upgrading to udev-115-4.20070921git.fc7 (currently in updates-testing)
NetworkManager has failed to function with my wireless card, and I think this is
because udev is reportedly (from /var/log/messages) doing this:

Oct  9 10:36:17 renton kernel: udev: renamed network interface wmaster0 to eth1

Version-Release number of selected component (if applicable):
udev-115-4.20070921git.fc7

Comment 1 Harald Hoyer 2007-10-12 06:53:31 UTC
correct. has to be fixed for F8 also..

Comment 2 Jonathan Underwood 2007-10-12 09:24:10 UTC
OK, thanks for the confirmation. Let me know if you want me to pull any builds
from koji for testing.

Comment 3 Fedora Update System 2007-10-15 21:24:41 UTC
udev-115-5.20071012git.fc7 has been pushed to the Fedora 7 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 udev'

Comment 4 Jonathan Underwood 2007-10-15 21:47:26 UTC
udev-115-5.20071012git.fc7 sort of works for me: Bug 328691 doesn't seem to
occur. However, upon boot NM does not detect the presence of a wireless
interface and does not list any wireless networks. Stopping the reg daemon,
unloading the kernel module, loading the kernel module and restarting the reg
daemon kicks everything into life and NM associates with an AP. With udev 113 I
didn't need to do this. BTW, I use the ipw3945 driver with the ipw3945d reg
daemon, as iwl3945 is too flakey. I am unsure whether this is a udev bug on a
ipw3945 bug at this point, but 328691 is probably fixed. 

Comment 5 Jonathan Underwood 2007-10-17 22:27:56 UTC
Just updated the kernel to the latest updates-testing version
kernel-2.6.23.1-4.fc7. On reboot and modprobing iwl3945 NM fails to scan
wireless networks as it is back to thinking there's no wireless interface. In
dmesg I see:

iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux,
1.1.17kds
iwl3945: Copyright(c) 2003-2007 Intel Corporation
ACPI: PCI Interrupt 0000:0c:00.0[A] -> GSI 17 (level, low) -> IRQ 17
PCI: Setting latency timer of device 0000:0c:00.0 to 64
iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connection
iwl3945: Tunable channels: 13 802.11bg, 23 802.11a channels
phy0: Selected rate control algorithm 'iwl-3945-rs'
net eth1: device_rename: sysfs_create_symlink failed (-17)
udev: renamed network interface wmaster0 to eth1


Comment 6 Jonathan Underwood 2007-10-17 22:30:56 UTC
Oh, however, removing the iwl3945 mac80211 and cfg80211 modules, and then
loading the ipw3945 module and starting the reg. daemon allows NM to connect to
a wireless network fine.

dmesg in this case shows

ACPI: PCI interrupt for device 0000:0c:00.0 disabled
ieee80211_crypt: registered algorithm 'NULL'
ieee80211: 802.11 data/management/control stack, git-1.1.13
ieee80211: Copyright (C) 2004-2005 Intel Corporation <jketreno.com>
ipw3945: Intel(R) PRO/Wireless 3945 Network Connection driver for Linux, 1.2.2dm
ipw3945: Copyright(c) 2003-2006 Intel Corporation
ACPI: PCI Interrupt 0000:0c:00.0[A] -> GSI 17 (level, low) -> IRQ 17
PCI: Setting latency timer of device 0000:0c:00.0 to 64
ipw3945: Detected Intel PRO/Wireless 3945ABG Network Connection
ipw3945: Detected geography ABG (13 802.11bg channels, 23 802.11a channels)
ADDRCONF(NETDEV_UP): eth1: link is not ready
ipw3945: Detected geography ABG (13 802.11bg channels, 23 802.11a channels)
ieee80211_crypt: registered algorithm 'WEP'
ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
eth1: no IPv6 routers present


I wonder if this is really a udev problem, or whether it is a kernel issue.

Comment 7 Harald Hoyer 2007-10-18 06:48:23 UTC
I would really recommend using iwlwifi without the reg daemon.

Comment 8 Harald Hoyer 2007-10-18 07:01:09 UTC
but yes, the "wmaster" renaming is a known problem.

Comment 9 Harald Hoyer 2007-10-18 07:09:30 UTC
Please check /etc/udev/rules.d/70-persistent-net.rules

Comment 10 Harald Hoyer 2007-10-18 07:12:50 UTC
ATTR{type}=="1" should be in the rules of /etc/udev/rules.d/70-persistent-net.rules

Comment 11 Harald Hoyer 2007-10-18 07:59:24 UTC
if not, remove /etc/udev/rules.d/70-persistent-net.rules and let udev recreate
it. Afterwards it should be there and hopefully fix your issues.

Comment 12 Jonathan Underwood 2007-10-18 21:26:17 UTC
(In reply to comment #7)
> I would really recommend using iwlwifi without the reg daemon.

As I say, I have tried (I presume you mean iwl3945 rather than iwlwifi - the
latter is the old name), but it doesn't work for me.

Comment 13 Jonathan Underwood 2007-10-18 21:27:23 UTC
(In reply to comment #10)
> ATTR{type}=="1" should be in the rules of
/etc/udev/rules.d/70-persistent-net.rules

I see:

# PCI device 0x14e4:0x170c (b44)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:18:8b:b4:f4:0
1", NAME="eth0"

# PCI device 0x8086:0x4222 (ipw3945)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:19:d2:6c:9a:f
4", NAME="eth1"


Comment 14 Jonathan Underwood 2007-10-18 21:28:29 UTC
(In reply to comment #11)
> if not, remove /etc/udev/rules.d/70-persistent-net.rules and let udev recreate
> it. Afterwards it should be there and hopefully fix your issues.

I moved /etc/udev/rules.d/70-persistent-net.rules out of the way (into /root),
and rebooted and the file is not recreated upon reboot. What is the right way to
recreate it?

Comment 15 Harald Hoyer 2007-10-19 05:59:55 UTC
# /sbin/chkconfig udev-post --add
# /sbin/service udev-post start

Comment 16 Jonathan Underwood 2007-10-20 14:08:48 UTC
(In reply to comment #15)
> # /sbin/chkconfig udev-post --add
> # /sbin/service udev-post start

OK, thanks, have now done that. Observations:

1) ipw3945
Removing 70-persistent-net.rules and rebooting using the ipw3945+reg daemon
results in the following 70-persistent-net.rules being created:
# PCI device 0x14e4:0x170c (b44)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:18:8b:b4:f4:01", ATTR{type}=="1", NAME="et
h0"

# PCI device 0x8086:0x4222 (ipw3945)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:19:d2:6c:9a:f4", ATTR{type}=="1", NAME="et
h1"

In this case NetworkManager still fails to associate with an AP. Stopping NM, I
can associate with an AP using system-config-network

2) iwl3945
Blacklisting ipw3945 in /etc/modprobe.d/blacklist, adding "alias eth1 iwl3945"
to modprobe.conf, removing 70-persistent-net.rules and rebooting results in only
a single entry in 70-persistent-net.rules referring to the wired device, and
iwl3945 isn't loaded on boot. Manually modprobing iwl3945 does cause 
NetworkManager to know there is a wireless interface (eth1) as reported by
nm-tool, but NM doesn't see any wireless netwroks. iwlist scan also fails to
detect any wireless networks. Running /sbin/service udev-post start after I have
manually modprobed iwl3945 results in an entry in 70-persistent-net.rules
relating to the wireless device:
# PCI device 0x14e4:0x170c (b44)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:18:8b:b4:f4:01", ATTR{type}=="1", NAME="et
h0"

# PCI device 0x8086:0x4222 (iwl3945)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:19:d2:6c:9a:f4", ATTR{type}=="1", NAME="et
h1"

Messages pertaining to all this that I see in /var/log/messages (or dmesg)

Oct 20 14:27:28 renton kernel: iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network
Connection driver for Linux,
 1.1.17kds
Oct 20 14:27:28 renton kernel: iwl3945: Copyright(c) 2003-2007 Intel Corporation
Oct 20 14:27:28 renton kernel: ACPI: PCI Interrupt 0000:0c:00.0[A] -> GSI 17
(level, low) -> IRQ 17
Oct 20 14:27:28 renton kernel: iwl3945: Detected Intel PRO/Wireless 3945ABG
Network Connection
Oct 20 14:27:28 renton kernel: iwl3945: Tunable channels: 13 802.11bg, 23
802.11a channels
Oct 20 14:27:28 renton kernel: net eth1: device_rename: sysfs_create_symlink
failed (-17)
Oct 20 14:27:28 renton kernel: ADDRCONF(NETDEV_UP): eth1: link is not ready
Oct 20 14:27:28 renton NetworkManager: <info>  eth1: Device is fully-supported
using driver 'iwl3945'. 
Oct 20 14:27:28 renton NetworkManager: <info>  nm_device_init(): waiting for
device's worker thread to start 
Oct 20 14:27:28 renton NetworkManager: <info>  nm_device_init(): device's worker
thread started, continuing. 
Oct 20 14:27:28 renton NetworkManager: <info>  Now managing wireless (802.11)
device 'eth1'. 
Oct 20 14:27:28 renton NetworkManager: <info>  Deactivating device eth1. 
Oct 20 14:27:28 renton NetworkManager: <info>  nm-netlink-monitor.c -
nm_netlink_monitor_event_handler (724) 
netlink reports device eth1 link now 1 
Oct 20 14:27:28 renton NetworkManager: <info>  nm-netlink-monitor.c -
nm_netlink_monitor_event_handler (724) 
netlink reports device eth1 link now 0 
ess}=="00:18:8b:b4:f4:01", ATTR{type}=="1", NAME="et
h0"

# PCI device 0x8086:0x4222 (ipw3945)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:19:d2:6c:9a:f4", ATTR{type}=="1", NAME="et
h1"

In this case NetworkManager still fails to associate with an AP. Stopping NM, I
can associate with an AP using system-config-network

2) iwl3945
Blacklisting ipw3945 in /etc/modprobe.d/blacklist, adding "alias eth1 iwl3945"
to modprobe.conf, removing 70-persistent-net.rules and rebooting results in only
a single entry in 70-persistent-net.rules referring to the wired device, and
iwl3945 isn't loaded on boot. Manually modprobing iwl3945 does cause 
NetworkManager to know there is a wireless interface (eth1) as reported by
nm-tool, but NM doesn't see any wireless netwroks. iwlist scan also fails to
detect any wireless networks. Running /sbin/service udev-post start after I have
manually modprobed iwl3945 results in an entry in 70-persistent-net.rules
relating to the wireless device:
# PCI device 0x14e4:0x170c (b44)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:18:8b:b4:f4:01", ATTR{type}=="1", NAME="et
h0"

# PCI device 0x8086:0x4222 (iwl3945)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:19:d2:6c:9a:f4", ATTR{type}=="1", NAME="et
h1"

Messages pertaining to all this that I see in /var/log/messages (or dmesg)

Oct 20 14:27:28 renton kernel: iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network
Connection driver for Linux,
 1.1.17kds
Oct 20 14:27:28 renton kernel: iwl3945: Copyright(c) 2003-2007 Intel Corporation
Oct 20 14:27:28 renton kernel: ACPI: PCI Interrupt 0000:0c:00.0[A] -> GSI 17
(level, low) -> IRQ 17
Oct 20 14:27:28 renton kernel: iwl3945: Detected Intel PRO/Wireless 3945ABG
Network Connection
Oct 20 14:27:28 renton kernel: iwl3945: Tunable channels: 13 802.11bg, 23
802.11a channels
Oct 20 14:27:28 renton kernel: net eth1: device_rename: sysfs_create_symlink
failed (-17)
Oct 20 14:27:28 renton kernel: ADDRCONF(NETDEV_UP): eth1: link is not ready
Oct 20 14:27:28 renton NetworkManager: <info>  eth1: Device is fully-supported
using driver 'iwl3945'. 
Oct 20 14:27:28 renton NetworkManager: <info>  nm_device_init(): waiting for
device's worker thread to start 
Oct 20 14:27:28 renton NetworkManager: <info>  nm_device_init(): device's worker
thread started, continuing. 
Oct 20 14:27:28 renton NetworkManager: <info>  Now managing wireless (802.11)
device 'eth1'. 
Oct 20 14:27:28 renton NetworkManager: <info>  Deactivating device eth1. 
Oct 20 14:27:28 renton NetworkManager: <info>  nm-netlink-monitor.c -
nm_netlink_monitor_event_handler (724) 
netlink reports device eth1 link now 1 
Oct 20 14:27:28 renton NetworkManager: <info>  nm-netlink-monitor.c -
nm_netlink_monitor_event_handler (724) 
netlink reports device eth1 link now 0 

The line about failing to create a symlink is suspicious. I turned off SElinux
in case that was an issue -  no difference.

So, all in all, NetworkManager is still broken with either driver. This is using 
udev-115-5.20071012git.fc7 and kernel-2.6.23.1-4.fc7.

Anything else I can do to provide useful info?



Comment 17 Harald Hoyer 2007-10-21 06:47:25 UTC
delete any /etc/sysconfig/network-scripts/ifcfg-wmaster*
and attach all /etc/sysconfig/network-scripts/ifcfg-* files

Comment 18 Jonathan Underwood 2007-10-21 10:34:51 UTC
OK, before I delete anything, here is what is currently present:

# ls /etc/sysconfig/network-scripts/ifcfg*
/etc/sysconfig/network-scripts/ifcfg-eth0 
/etc/sysconfig/network-scripts/ifcfg-wlan0.bak
/etc/sysconfig/network-scripts/ifcfg-eth1 
/etc/sysconfig/network-scripts/ifcfg-wmaste
/etc/sysconfig/network-scripts/ifcfg-lo

The only one manually created by me of those is ifcfg-eth1 (using
system-config-network).

Contents:
1) /etc/sysconfig/network-scripts/ifcfg-eth0
# Broadcom Corporation BCM4401-B0 100Base-TX
DEVICE=eth0
BOOTPROTO=dhcp
HWADDR=00:18:8B:B4:F4:01
ONBOOT=no
TYPE=Ethernet


2)/etc/sysconfig/network-scripts/ifcfg-eth1
# Please read /usr/share/doc/initscripts-*/sysconfig.txt
# for the documentation of these parameters.
TYPE=Wireless
DEVICE=eth1
HWADDR=00:19:d2:6c:9a:f4
BOOTPROTO=dhcp
NETMASK=
DHCP_HOSTNAME=
IPADDR=
DOMAIN=
ONBOOT=no
USERCTL=no
IPV6INIT=no
PEERDNS=yes
ESSID=SKY07133
CHANNEL=1
MODE=Managed
RATE='0 kb/s'

3) /etc/sysconfig/network-scripts/ifcfg-lo
DEVICE=lo
IPADDR=127.0.0.1
NETMASK=255.0.0.0
NETWORK=127.0.0.0
# If you're having problems with gated making 127.0.0.0/8 a martian,
# you can change this to something else (255.255.255.255, for example)
BROADCAST=127.255.255.255
ONBOOT=yes
NAME=loopback


4) /etc/sysconfig/network-scripts/ifcfg-wlan0.bak
# Intel Corporation PRO/Wireless 3945ABG Network Connection
DEVICE=wlan0
ONBOOT=yes
BOOTPROTO=dhcp
HWADDR=00:19:d2:6c:9a:f4
NETMASK=
DHCP_HOSTNAME=
IPADDR=
DOMAIN=
TYPE=Wireless
ESSID=
CHANNEL=
MODE=
RATE=


5)/etc/sysconfig/network-scripts/ifcfg-wmaste
DEVICE=wmaste
BOOTPROTO=dhcp
ONBOOT=no
TYPE=Unknown




Comment 19 Jonathan Underwood 2007-10-21 12:09:30 UTC
OK, following your directions here are the steps I went through, and the results
at each point:

1) I removed wmaste and wlan0.bak using system-config-network. I then verified
that /etc/sysconfig/network-scripts/{ifcfg-wmaste,wlan0.bak} were no longer present.

2) I removed /etc/udev/rules.d/70-persistent-net.rules

3) I blacklisted ipw3945 in /etc/modprobe.d/blacklist, and I ensured that "alias
eth1 iwl3945" was present in /etc/modprobe.conf

4) I rebooted and observed that (i) iwl3945 was not loaded during the reboot
(ii) 70-persistent-net.rules did not contain an entry for the wireless device.

5) I modprobed iwl3945 manually at this point and restarted NetworkManager.
nm-tool now shows that NM is seeing a wireless device, however it does not
detect any wireless networks.  /var/log/messages for this period of time:

Oct 21 12:16:09 renton NetworkManager: <info>  Error getting killswitch power: o
rg.freedesktop.Hal.Device.UnknownError - An Error occurred. The Error message is
:    Could not open file /sys/devices/platform/dcdbas/smi_data. Check that dcdba
s driver is properly loaded. 
Oct 21 12:16:12 renton kernel: iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network
 Connection driver for Linux, 1.1.17kds
Oct 21 12:16:12 renton kernel: iwl3945: Copyright(c) 2003-2007 Intel Corporation
Oct 21 12:16:12 renton kernel: ACPI: PCI Interrupt 0000:0c:00.0[A] -> GSI 17 (le
vel, low) -> IRQ 17
Oct 21 12:16:12 renton kernel: iwl3945: Detected Intel PRO/Wireless 3945ABG Netw
ork Connection
Oct 21 12:16:12 renton kernel: iwl3945: Tunable channels: 13 802.11bg, 23 802.11
a channels
Oct 21 12:16:12 renton kernel: net eth1: device_rename: sysfs_create_symlink fai
led (-17)
Oct 21 12:16:12 renton kernel: ADDRCONF(NETDEV_UP): eth1: link is not ready
Oct 21 12:16:12 renton NetworkManager: <info>  eth1: Device is fully-supported u
sing driver 'iwl3945'. 
Oct 21 12:16:12 renton NetworkManager: <info>  nm_device_init(): waiting for dev
ice's worker thread to start 
Oct 21 12:16:12 renton NetworkManager: <info>  nm_device_init(): device's worker
 thread started, continuing.
Oct 21 12:16:12 renton NetworkManager: <info>  Now managing wireless (802.11) de
vice 'eth1'. 
Oct 21 12:16:12 renton NetworkManager: <info>  Deactivating device eth1. 
Oct 21 12:16:12 renton NetworkManager: <info>  nm-netlink-monitor.c - nm_netlink
_monitor_event_handler (724) netlink reports device eth1 link now 1 
Oct 21 12:16:12 renton NetworkManager: <info>  nm-netlink-monitor.c - nm_netlink
_monitor_event_handler (724) netlink reports device eth1 link now 0 
Oct 21 12:16:15 renton NetworkManager: <info>  Error getting killswitch power: o
rg.freedesktop.Hal.Device.UnknownError - An Error occurred. The Error message is
:    Could not open file /sys/devices/platform/dcdbas/smi_data. Check that dcdba
s driver is properly loaded. 
[SNIP - the last message above repeated lots of times]
Oct 21 12:16:21 renton NetworkManager: <info>  Error getting killswitch power: o
rg.freedesktop.Hal.Device.UnknownError - An Error occurred. The Error message is
:    Could not open file /sys/devices/platform/dcdbas/smi_data. Check that dcdba
s driver is properly loaded. 
Oct 21 12:16:26 renton NetworkManager: <WARN>  request_and_convert_scan_results(
): card took too much time scanning.  Get a better one. 
Oct 21 12:16:27 renton NetworkManager: <info>  Error getting killswitch power: o
rg.freedesktop.Hal.Device.UnknownError - An Error occurred. The Error message is
:    Could not open file /sys/devices/platform/dcdbas/smi_data. Check that dcdba
s driver is properly loaded. 
[SNIP - the last two messages repeated several times]
Oct 21 12:17:17 renton NetworkManager: <WARN>  nm_signal_handler(): Caught signa
l 15, shutting down normally. 
Oct 21 12:17:18 renton NetworkManager: <info>  Caught terminiation signal 
Oct 21 12:17:18 renton NetworkManager: <info>  Deactivating device eth0. 
Oct 21 12:17:18 renton NetworkManager: <info>  Deactivating device eth1. 
Oct 21 12:17:18 renton NetworkManager: <info>  starting... 
Oct 21 12:17:18 renton NetworkManager: <info>  Found radio killswitch /org/freed
esktop/Hal/devices/dell_wlan_switch 
Oct 21 12:17:18 renton kernel: ADDRCONF(NETDEV_UP): eth1: link is not ready
Oct 21 12:17:18 renton NetworkManager: <info>  eth1: Device is fully-supported u
sing driver 'iwl3945'. 
Oct 21 12:17:18 renton NetworkManager: <info>  nm_device_init(): waiting for dev
ice's worker thread to start 
Oct 21 12:17:18 renton NetworkManager: <info>  nm_device_init(): device's worker
 thread started, continuing. 
Oct 21 12:17:18 renton NetworkManager: <info>  Now managing wireless (802.11) de
vice 'eth1'. 
Oct 21 12:17:18 renton NetworkManager: <info>  Deactivating device eth1. 
Oct 21 12:17:18 renton kernel: ADDRCONF(NETDEV_UP): eth0: link is not ready
Oct 21 12:17:18 renton NetworkManager: <info>  eth0: Device is fully-supported u
sing driver 'b44'. 
Oct 21 12:17:18 renton NetworkManager: <info>  nm_device_init(): waiting for dev
ice's worker thread to start 
Oct 21 12:17:18 renton NetworkManager: <info>  nm_device_init(): device's worker
 thread started, continuing. 
Oct 21 12:17:18 renton NetworkManager: <info>  Now managing wired Ethernet (802.
3) device 'eth0'. 
Oct 21 12:17:18 renton NetworkManager: <info>  Deactivating device eth0. 
Oct 21 12:17:18 renton NetworkManager: <info>  nm-netlink-monitor.c - nm_netlink
_monitor_event_handler (724) netlink reports device eth0 link now 0 
Oct 21 12:17:18 renton NetworkManager: <info>  nm-device-802-3-ethernet.c - link
_deactivated_helper (129) device eth0 will set active link to FALSE 
Oct 21 12:17:18 renton NetworkManager: <info>  nm-device-802-3-ethernet.c - nm_d
evice_802_3_ethernet_link_deactivated (149) device eth0 scheduled link_deactivat
ed_helper 
Oct 21 12:17:18 renton NetworkManager: <info>  nm-netlink-monitor.c - nm_netlink
_monitor_event_handler (724) netlink reports device eth1 link now 0 
Oct 21 12:17:18 renton NetworkManager: <info>  nm-netlink-monitor.c - nm_netlink
_monitor_event_handler (724) netlink reports device eth1 link now 0 
Oct 21 12:17:18 renton NetworkManager: <info>  nm-netlink-monitor.c - nm_netlink
_monitor_event_handler (724) netlink reports device eth0 link now 0 
Oct 21 12:17:18 renton NetworkManager: <info>  nm-device-802-3-ethernet.c - nm_d
evice_802_3_ethernet_link_deactivated (149) device eth0 scheduled link_deactivat
ed_helper 
Oct 21 12:17:18 renton NetworkManager: <info>  nm-device-802-3-ethernet.c - link
_deactivated_helper (129) device eth0 will set active link to FALSE 
Oct 21 12:17:18 renton NetworkManager: <info>  Updating allowed wireless network
 lists. 
Oct 21 12:17:18 renton NetworkManager: <info>  Error getting killswitch power: o
rg.freedesktop.Hal.Device.UnknownError - An Error occurred. The Error message is
:    Could not open file /sys/devices/platform/dcdbas/smi_data. Check that dcdba
s driver is properly loaded. 
Oct 21 12:17:18 renton NetworkManager: <info>  Wireless now enabled by radio kil
lswitch 
Oct 21 12:17:24 renton NetworkManager: <info>  Error getting killswitch power: o
rg.freedesktop.Hal.Device.UnknownError - An Error occurred. The Error message is
:    Could not open file /sys/devices/platform/dcdbas/smi_data. Check that dcdba
s driver is properly loaded. 
Oct 21 12:17:30 renton NetworkManager: <info>  Error getting killswitch power: o
rg.freedesktop.Hal.Device.UnknownError - An Error occurred. The Error message is
:    Could not open file /sys/devices/platform/dcdbas/smi_data. Check that dcdba
s driver is properly loaded. 
Oct 21 12:17:32 renton NetworkManager: <WARN>  request_and_convert_scan_results(
): card took too much time scanning.  Get a better one. 
Oct 21 12:17:36 renton kernel: intel_rng: FWH not detected

6) I then ran /sbin/service udev-post start and confirmed that
70-persistent-net.rules now contains an entry for the wireless card.

7) I then rebooted to see if iwl3945 would now be loaded on boot with the
updated 70-persistent-net.rules file. However iwl3945 is not loaded on reboot.
running /sbin/udevtrigger also does not cause iwl3945 to load.

8) I now manuall modprobed iwl3945 and confirmed that nm-tool sees the eth1
wireless device - it does. NM still detects no wireless networks though. iwlist
scan gives:
eth1   Failed to read scan data: Resource temporarily unavailable

9) Out of curiosity I had a look to see if
/etc/sysconfig/network-scripts/ifcfg-wmaste* had re-appeared, but it hadn't.

10) At this point I gave up on iwl3945, and decided to see what joy using
ipw3945 gives me.

11) I removed 70-persistent-net.rules. I changed alias eth1 iwl3945 to alias
eth1 ipw3945 in modprobe.conf. I blacklisted iwl3945 in
/etc/modprobe.d/blacklist. I then rebooted.

12) On reboot I observe that ipw3945 is loaded, and that 70-persistent-net.rules
contains an entry for the wireless device eth1. NM however fails to associate,
despite asking for a wireless key (which is already stored in gnome-keyring
anyway). iwlist scan gives:
eth1   No scan results.

13) Stopping NM, unloading and reloading ipw3945 and ieee80211* and doing an
ifup eth1 gets me instantly associated.


At this point, I have no idea wheterh we're still looking at udev bugs, iwl3945
bugs, ipw3945 bugs, NM bugs... or all of the above. :)Let me know if there's
anything else I can do to test.

Comment 20 Harald Hoyer 2007-10-22 06:54:54 UTC
1. on my system iwl3945 is autoloaded by udev
2. iwl3945-firmware provides the firmware needed
3. I heard issues with the kill switch
4. my F7 is updated

What you might try: 
* Move away the old ipw3945 and ieee80211* modules. 
* Do not start the ipw daemon.
* Check, that the firmware files are really from iwl3945-firmware
* You might search for a solution for the message: "Could not open file
/sys/devices/platform/dcdbas/smi_data. Check that dcdbas driver is properly loaded."

Besides of that, I think we can close _this_ bug. Feel free to add comments
here. I'll try to help.

Comment 21 Jonathan Underwood 2007-10-22 14:11:56 UTC
(In reply to comment #20)
> 1. on my system iwl3945 is autoloaded by udev

Not on mine, but it was with udev-113.

> 2. iwl3945-firmware provides the firmware needed
I have iwl3945-firmware-2.14.1.5-1 installed.
# rpm -ql ipw3945-firmware
/lib/firmware/ipw3945.ucode
/usr/share/doc/ipw3945-firmware-1.14.2
/usr/share/doc/ipw3945-firmware-1.14.2/LICENSE
/usr/share/doc/ipw3945-firmware-1.14.2/README


> 3. I heard issues with the kill switch
Yes, i think this may be the root of it actually. Perhaps it was a bug that it
worked with udev-113.

> 4. my F7 is updated
> 

Mine too, up to date with the updates-testing repo.

> What you might try: 
> * Move away the old ipw3945 and ieee80211* modules. 
I will try this, but don't expect it was the issue - I have been careful to
confirm that they are not loaded when iwl3945 is loaded (and vice versa).

> * Do not start the ipw daemon.
Yes - this i have been doing whenever testing iwl3945 - I should have pointed
this out sorry.

> * Check, that the firmware files are really from iwl3945-firmware
Confirmed (see above).

> * You might search for a solution for the message: "Could not open file
> /sys/devices/platform/dcdbas/smi_data. Check that dcdbas driver is properly
loaded."
> 
This is related to the kill switch thing, but is probably at the bottom of it.

> Besides of that, I think we can close _this_ bug. Feel free to add comments
> here. I'll try to help.

OK, thanks. On your system, does NM work as expected with this version of udev?

My worry is this: since upgrading to udev-115, NM has stopped working with
ipw3945, and iwl3945 has stopped working. At least, that is the observation. I
can't categorically prove a causal link, though. I see the same symptom with
kernel 2.6.22.9-91 which with udev-113 worked fine, so i think that eliminates
the kernel.

For sanity's sake I'll try forcing a downgrade to udev-113 later (when I have
cleared enough work to risk breaking my system). Anyway, probably fair to close
the bug if it works for you.



Comment 22 Harald Hoyer 2007-10-22 14:24:44 UTC
if a downgrade of to udev-113 solves this problem with NM, then you can reopen
this bug.

Comment 23 Fedora Update System 2007-11-09 23:55:31 UTC
udev-116-3.fc7 has been pushed to the Fedora 7 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 udev'

Comment 24 Fedora Update System 2007-12-06 20:43:30 UTC
udev-116-3.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.


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