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. -- Regards, Florian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]