[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#495676: marked as done (hw-detect: hw-detect new device detection misbehaves with wlan* devices)

Your message dated Sun, 23 May 2010 11:59:58 +0200
with message-id <20100523095958.GU4937@login1.uio.no>
and subject line Re: hw-detect: hw-detect new device detection misbehaves with wlan* devices
has caused the Debian Bug report #495676,
regarding hw-detect: hw-detect new device detection misbehaves with wlan* devices
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
495676: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=495676
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: hw-detect
Version: 1.65
Severity: important

Hi!

While testing a daily image on a Lenovo R61 with a manually updated
2.6.26 image, I was puzzled when I was asked "Do you intend to use
FireWire Ethernet?" on a machine which has both wired and wireless LAN
cards.

2.6.26 kernels re-introduced the old FireWire stack.  So we are back
having the eth1394 module available, and thus FireWire ethernet.  That's
why the following issue did not pop up before.

After digging through the logs, I eventually found that every single
card was listed as "FireWire ethernet" in /etc/network/devnames.  Next
step was figuring out why could make that happen.

More tests later, I eventually found that this was due to the way
hw-detect finds a new network interface after loading a module.

The list of available interface is known by snapshot_devs()
after sorting the content of the first column in /proc/net/dev,
e.g. "lo eth0".

This list is kept while a new module is loaded, then snapshot_devs() is
called again to get something like "lo eth0 eth1".  To compare those
lists and get the new interfaces, compare_devs() is used.

compare_devs() basically currently works by doing:
  echo ${devs#$olddevs}

In the previous case, as ethX interfaces are always added at the end,
both lists have the same start, and so compare_devs() nicely output
"eth1".

Unfortunately, thanks to new Wi-Fi stacks, we now have interfaces that
are not named "ethX".  On this laptop we get the following:

  compare_devs "lo eth0 wlan0 wmaster0" "lo eth0 eth1 wlan0 wmaster0"
                                                 ^^^^
                                       not inserted at the end!

I see two possible fixes here:

 * Stop sorting devices in snapshot_devs() anymore.  I don't see why
   the kernel would reorder the content of /proc/net/dev when new
   modules are inserted.  From my tests, this nicely solved the issue.
 * Make compare_dev() able to detect the addition in the middle of the
   device list.  For the record, modifying compare_devs to use the
   following did the trick:

     sed="$(echo $olddevs | sed -e 's#\([a-z0-9]\+\) *#s/\1 *//;#g')"
     echo $devs | sed -e "$sed"

I tried to dig the history of the repository in order to figure out why
snapshot_dev() used "sort" in the first place, but I was not able to get
any meaningful result.  Do anyone have an idea?

Otherwise, removing the sorting sounds like the best option to me.

Cheers,
-- 
Jérémy Bobbio                        .''`. 
lunar@debian.org                    : :Ⓐ  :  # apt-get install anarchism
                                    `. `'` 
                                      `-

Attachment: signature.asc
Description: Digital signature


--- End Message ---
--- Begin Message --- 
Version: 1.66

This bug was fixed in 2008.  No idea why this changelog entry by
Jeremy Babbio failed to close it.

  * Fix ethdetect and hw-detect for NICs named differently than ethX.
    (Closes: #495676)
    Thanks to Frans Pop for suggesting a better implementation.

Closing it now.

Happy hacking,
-- 
Petter Reinholdtsen

--- End Message ---
Reply to: