Hi again,
On Wed, May 10, 2006 at 21:35:34 +0100, Jerome BENOIT wrote:
Hi !
Florian Kulzer wrote:
On Wed, May 10, 2006 at 16:50:45 +0100, Jerome BENOIT wrote:
[...]
/etc/udev/rules.d/z25_persistent-net.rules ,
======================================================================
# This file was automatically generated by the /lib/udev/write_net_rules
# program, probably run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line.
# PCI device 10b7:9200 (3c59x)
ACTION=="add", SUBSYSTEM=="net", DRIVER=="?*",
SYSFS{address}=="00:90:4b:b0:a6:bb", NAME="eth0"
# PCI device 14e4:4301 (ndiswrapper)
ACTION=="add", SUBSYSTEM=="net", DRIVER=="?*",
SYSFS{address}=="00:90:4b:b0:a6:bb", SYSFS{type}=="1", NAME="wlan0"
# PCI device 10b7:9200 (3c59x)
ACTION=="add", SUBSYSTEM=="net", DRIVER=="?*",
SYSFS{address}=="00:08:74:e7:4d:0e", NAME="eth0"
=============================================================================================
[...]
br0 is a bridge: before the trouble wlan0 and eth0 were bridged together:
br0={wlan0,eth0}
[...]
0000:00:1f.6 Modem: Intel Corporation 82801CA/CAM AC'97 Modem Controller
(rev 02)
0000:01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R250 Lf
[FireGL 9000] (rev 01)
0000:02:00.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado]
(rev 78)
0000:02:01.0 CardBus bridge: Texas Instruments PCI4451 PC card Cardbus
Controller
0000:02:01.1 CardBus bridge: Texas Instruments PCI4451 PC card Cardbus
Controller
0000:02:01.2 FireWire (IEEE 1394): Texas Instruments PCI4451 IEEE-1394
Controller
0000:02:03.0 Network controller: Broadcom Corporation BCM4303 802.11b
Wireless LAN Controller (rev 02)
and ip link:
1: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:90:4b:b0:a6:bb brd ff:ff:ff:ff:ff:ff
2: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
3: wlan0_temp: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
link/ether 00:90:4b:b0:a6:bb brd ff:ff:ff:ff:ff:ff
4: br1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
link/ether 00:90:4b:b0:a6:bb brd ff:ff:ff:ff:ff:ff
Well, I have no experience with bridging network devices, but I have the
impression that it has led to some confusion when the persistent udev
rules for the network devices were created. I would first try to disable
bridging and configure udev correctly for the individual devices.
I think you should comment out one of the "eth0" lines in your
z25_persistent-net.rules. Then you have to find out the correct hardware
addresses for both cards and put them in the appropriate lines in this
file. If the bridge is still active you might be able to get the
addresses with "brctl showmacs br1", but I don't know how to reliably
tell which card is the wireless one. If the bridge is disabled you
should be able to use a combination of "ip link", "ifconfig",
"iwconfig", "udevinfo -a -p /class/net/eth0" and "udevinfo -a -p
/class/net/wlan0_temp" to identify the HW addresses unambiguously. After
you set up the persistent rules file correctly you should get eth0 and
wlan0 after a reboot. (Note: Some tools might report the hexadecimal
numbers in the HW address using uppercase letters [A-F]; for the udev
rules you need to use lowercase [a-f].)
Once it works for the individual devices you can activate the bridging
again. If this screws things up it is probably appropriate to file a bug
against udev.