Doesn't handle devices with unusual names

Please attach your /etc/iftab file.

I sometimes see a similar issue on my laptop after suspend-to-ram.

On resume, often times the internal wireless card (an ipw2200) will be renamed to eth0_clashed (when it is normally eth0). My /etc/iftab looks pretty sane to me (contents below).

eth0 mac 00:12:f0:74:ae:f9
eth1 mac 00:12:3f:80:06:e7

....ae:f9 is indeed the mac of my ipw2200 card.

When this happens, hal completely forgets about the card. That is, "lshal | grep eth0" does not output anything. However, ifconfig and iwconfig still show it. Sometimes these symptoms also occur without the interface being renamed.

I have come to believe that this is a bug in the ipw2200 driver's suspend functions, rather than a problem with udev or hal. I wonder what card the original bug reporter is using?

I'm also using ipw2200. Whether it's a regression in the driver itself or in udev or hal, I cannot say due to lack of knowledge. What I do know is that this didn't happen with at least Dapper Flight 3. I can help track the problem but someone has to give me directions on how to provide the necessary information.

i am getting
sam@titania-d:~$ iwconfig
lo no wireless extensions.

eth1 no wireless extensions.

eth0_clashed NOT READY! ESSID:off/any
          Mode:Managed Channel:0 Access Point: Not-Associated
          Tx-Power=31 dBm Sensitivity=0/200
          Retry min limit:0 RTS thr:off Fragment thr:off
          Link Quality:0 Signal level:0 Noise level:0
          Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
          Tx excessive retries:0 Invalid misc:0 Missed beacon:0

eth2 IEEE 802.11b ESSID:"wiffy" Nickname:"HERMES I"
          Mode:Managed Frequency:2.437 GHz Access Point: 00:0F:66:DA:4C:5D
          Bit Rate:11 Mb/s Sensitivity:1/3
          Retry limit:4 RTS thr:off Fragment thr:off
          Power Management:off
          Link Quality=19/92 Signal level=-78 dBm Noise level=-97 dBm
          Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:20
          Tx excessive retries:154 Invalid misc:0 Missed beacon:0

sit0 no wireless extensions.

eth2 is the built in orinoco airport, and eth0_clashed should probably be my netgear WG511 v2.0

my iftab has
eth0 mac 00:09:5b:e6:4c:03
eth1 mac 00:0a:95:e5:1e:68
eth2 mac 00:30:65:2c:74:d7

i am running dapper clean installed from daily 20060227 on a powerbook 3,5

Please provide output from "ifconfig -a"

sam@titania-d:~$ ifconfig -a
eth1 Link encap:Ethernet HWaddr 00:0A:95:E5:1E:68
          BROADCAST MULTICAST MTU:1500 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
          Interrupt:41 Base address:0xb400

eth2 Link encap:Ethernet HWaddr 00:30:65:2C:74:D7
          inet6 addr: fe80::230:65ff:fe2c:74d7/64 Scope:Link
          UP BROADCAST MULTICAST MTU:1500 Metric:1
          RX packets:29925 errors:0 dropped:0 overruns:0 frame:0
          TX packets:23304 errors:878 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:37079652 (35.3 MiB) TX bytes:3575358 (3.4 MiB)
          Interrupt:57

eth0_clas Link encap:Ethernet HWaddr 00:30:B4:00:00:00
          BROADCAST MULTICAST MTU:1500 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
          Interrupt:58

lo Link encap:Local Loopback
          inet addr:127.0.0.1 Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING MTU:16436 Metric:1
          RX packets:9 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:472 (472.0 b) TX bytes:472 (472.0 b)

sit0 Link encap:IPv6-in-IPv4
          NOARP MTU:1480 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

sam: there is no bug here, your machine is behaving properly. the additional card isn't listed in /etc/iftab and is being prevented from taking the name eth0 which is assigned to another.

What?!?!?!? I'm left speechless... so, a couple of months ago everything is detected properly, now it isn't and you say that it isn't a bug.

Ok cool, you just lost one customer.

I don't see any evidence of anything not being detected here. And you've ignored my request for information from you.

Why are you saying I ignored you? Over here in Portugal, Tuesday was a national holiday so I was away for the weekend (and away from computers about 95% of the time :-) )

Sam Tygier has a very similar problem and he has posted the information you requested. If you fix his problem, more surely than not you'll fix mine as well. I'll post every bit of information as soon as I can get it but, at least, don't go rejecting bug reports because a couple of days have past by since you requested the information.

This bug has been rejected because there is no evidence of incorrect behaviour here, everything is working as expected. Your lack of reply just led me to assume, which you have confirmed, that you were experiencing the same behaviour as Sam.

Your card is being named eth0_clashed because the kernel assigned it the name "eth0", which your /etc/iftab file reserves for a different card.

As documented in many places, including this bug tracker, the Wiki and the Forums, you can fix this by adding a new line to /etc/iftab to name the card that's clashing.

Alternately you can remove the reservation for the eth0 name.

My opinion is that a few bugs exist here:
1) /etc/iftab, if I recall correctly, is a file maintained by the ifrename package. I never touched it so whatever the contents of that file are, their the default and if that file should be empty then there's a bug in ifrename

2) it's pretty obvious to me that the _clashed suffix means that something went wrong with the detection of the cards. As I mentioned before, this problem didn't exist in Hoary, Breezy and Dapper Flight 3 (never bothered to test Warty on the laptop).

3) if the card is named with the _clashed suffix, network related stuff should work. But it doesn't. If you read my original report, this was reported against *network-manager* not udev. So network-manager doesn't support interfaces with a _clashed suffix. Maybe because no card should be named like this.

On Wed, 2006-03-01 at 12:59 +0000, Celso Pinto wrote:

> My opinion is that a few bugs exist here:
> 1) /etc/iftab, if I recall correctly, is a file maintained by the
> ifrename package. I never touched it so whatever the contents of that
> file are, their the default and if that file should be empty then
> there's a bug in ifrename
>
Not entirely true. In breezy it was owned by the ifrename package, that
was true, in dapper it is owned by the udev package. For both (and
since warty) it has been written by the Installer to match your network
cards at install time (otherwise they'd randomly swap places each
boot).

> 2) it's pretty obvious to me that the _clashed suffix means that
> something went wrong with the detection of the cards. As I mentioned
> before, this problem didn't exist in Hoary, Breezy and Dapper Flight 3
> (never bothered to test Warty on the laptop).
>
Not true. You're using a development release, remember. The _clashed
suffix is simply a debugging check to make sure that the new udev device
renaming code is correctly observing that the kernel wanted to call the
device "eth0" but that your /etc/iftab file reserves that name for a
different card.

It has always been the intention that the _clashed suffix would go away
before release, and in fact I uploaded the patch for that today as I'm
content with the results.

> 3) if the card is named with the _clashed suffix, network related stuff
> should work. But it doesn't. If you read my original report, this was
> reported against *network-manager* not udev. So network-manager doesn't
> support interfaces with a _clashed suffix. Maybe because no card should
> be named like this.
>
Ah, I had missed that in others ganging up on the bug for their own
_clashed problems -- sorry for the confusion.

 affects /distros/ubuntu/network-manager
 status unconfirmed
 summary "Does not see, or ignores device names not matching expected
pattern"

Thanks for your time,

Scott
--
Scott James Remnant
<email address hidden>

i experienced the problem with the same hardware plugged in as when installed. so it should not clash with the contents of /etc/iftab.

it seems that in my ifconfig -a the MAC address of my wireless card is miss read. "00:30:B4:00:00:00" seems like an unlikely MAC address, breezy (and it seems the installer) read it as "00:09:5b:e6:4c:03"

On Wed, 2006-03-01 at 13:48 +0000, sam tygier wrote:

> i experienced the problem with the same hardware plugged in as when
> installed. so it should not clash with the contents of /etc/iftab.
>
> it seems that in my ifconfig -a the MAC address of my wireless card is
> miss read. "00:30:B4:00:00:00" seems like an unlikely MAC address,
> breezy (and it seems the installer) read it as "00:09:5b:e6:4c:03"
>
Please don't pollute this bug report!

If the kernel is not detecting your MAC address correctly, that is a
kernel bug and should be filed there.

Scott
--
Scott James Remnant
<email address hidden>

On Wed, 2006-03-01 at 12:59 +0000, Celso Pinto wrote:

> 3) if the card is named with the _clashed suffix, network related stuff
> should work. But it doesn't. If you read my original report, this was
> reported against *network-manager* not udev. So network-manager doesn't
> support interfaces with a _clashed suffix. Maybe because no card should
> be named like this.
>
Celso, could you try something for me while you still have a problem
with NM detecting your card with the _clashed suffix:

Run python and paste the following into it:

----8<--------8<--------8<--------8<--------8<--------8<--------8<----
import dbus
bus = dbus.SystemBus()
proxy_obj = bus.get_object("org.freedesktop.NetworkManager",
    "/org/freedesktop/NetworkManager")
dbus_iface = dbus.Interface(proxy_obj, "org.freedesktop.NetworkManager")
dbus_iface.getDevices()
---->8-------->8-------->8-------->8-------->8-------->8-------->8----

and give me the output. Then try this in the same window:

----8<--------8<--------8<--------8<--------8<--------8<--------8<----
proxy_obj = bus.get_object("org.freedesktop.NetworkManager",
    "/org/freedesktop/NetworkManager/Devices/eth1")
dbus_iface = dbus.Interface(proxy_obj, "org.freedesktop.NetworkManager")
dbus_iface.getProperties()
---->8-------->8-------->8-------->8-------->8-------->8-------->8----

give me the output, and then this:
----8<--------8<--------8<--------8<--------8<--------8<--------8<----
proxy_obj = bus.get_object("org.freedesktop.NetworkManager",
    "/org/freedesktop/NetworkManager/Devices/eth0_5f_clashed")
dbus_iface = dbus.Interface(proxy_obj, "org.freedesktop.NetworkManager")
dbus_iface.getProperties()
---->8-------->8-------->8-------->8-------->8-------->8-------->8----

and provide the output.

It shouldn't take more than a few seconds, so if you can do that when
you get this mail, that'd be great!

Thanks,

Scott
--
Scott James Remnant
<email address hidden>

ok, found my problem https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/31502

would it make sense for this to be duped to #31502 and a new bug to be started for NM not liking interface names like "eth0_clas"

Scott, I'll run those scripts but I'm only able to report back later because I left my laptop at home.

Ok, no problem.

For the record, here I'm seeing Network Manager behave just fine and show up that card. The only reason it doesn't appear enabled for me is because I haven't got a network cable plugged into it.

Hi Scott,

for script #1 the output is:
>>> dbus_iface.getDevices()
['/org/freedesktop/NetworkManager/Devices/eth0',
'/org/freedesktop/NetworkManager/Devices/eth0_5f_clashed']

and for #2:
>>> dbus_iface.getProperties() Introspect error: The requested network
device does not exist.
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.4/site-packages/dbus/proxies.py", line 79, in
__call__
    reply_message = self._connection.send_with_reply_and_block(message,
timeout) File "dbus_bindings.pyx", line 458, in
dbus_bindings.Connection.send_with_reply_and_block
dbus_bindings.DBusException: The requested network device does not
exist.

and for #3:
>>> dbus_iface.getProperties()
['/org/freedesktop/NetworkManager/Devices/eth0', u'eth0', 1,
u'/org/freedesktop/Hal/devices/net_00_c0_9f_a2_98_fa', False, 0,
u'0.0.0.0', u'0.0.0.0', u'0.0.0.0', u'00:C0:9F:A2:98:FA', u'0.0.0.0',
u'0.0.0.0', u'0.0.0.0', 0, -1, False, 3, u'', []]

Here's the output for eth0:

>>> dbus_iface.getProperties()
['/org/freedesktop/NetworkManager/Devices/eth0', u'eth0', 1,
u'/org/freedesktop/Hal/devices/net_00_c0_9f_a2_98_fa', False, 0,
u'0.0.0.0', u'0.0.0.0', u'0.0.0.0', u'00:C0:9F:A2:98:FA', u'0.0.0.0',
u'0.0.0.0', u'0.0.0.0', 0, -1, False, 3, u'', []]

It's quite a surprise that eth0 and eth0_clashed are exactly the same
cards and the other NIC (cable LAN) doesn't show up.

Cheers,
Celso

Ok, I think I see the problem...

getDevices() shows an eth0_5f_clashed interface, but if you try and use that object string, it reports that the device doesn't exist.

You have to ask for eth0_clashed itself, and then the properties say the path is eth0_5f_clashed again.

In other words, getDevices is escaping stuff it shouldn't or the device information objects aren't being unescaped when they should

I'll file this one upstream

If I'm not mistaken, you've disabled the _clashed renaming now for Dapper, and so there should be no more surprising interface names, even if there is a conflict

Users can still give custom names for devices, so we should still make sure this is fixed.

See the upstream bugzilla report for a fix, the problem is in NetworkManager, not udev

Thanks Crispin, have applied this patch and uploaded