wicd can't detect wireless interface

[Jun Inoue]

Hi, I recently migrated to a new laptop, and wicd had trouble detecting the wireless interface on it. I'm using Debian sid on a Toshiba dynabook RX2/T7J.

GetWirelessInterfaces() in wnettools.py looks for /sys/class/net/*/wireless, but there's no such file on my system. Changing this function to invoke iwgetid on every interface and look at the exit code solved it (see attachment). It works, but it's rather inefficient. Speaking of which, should the detection code be moved to backends? There could be an ioctl version of iface detection. That may or may not be useful since this is a one-shot thing that gets run at startup, and besides, there are only so many interfaces to check....

I chose iwgetid over iwconfig because of this bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=526187
(Summary of the linked bug report: "iwconfig foo" returns 0 even if foo is not a wireless interface.)

There is a related bug, which is that the default values of the interfaces were never used. My wireless interface was in fact wlan0 (the hard-coded default), but wicd didn't try that interface. In WicdDaemon.ReadConfig(), a default is assigned when iface receives the value None, but this never happens because the WirelessDaemon.DetectWirelessInterface() applies str() before returning the value, and turns the object None into the string "None". Removing the str() hasn't caused a problem for me so far, but is it needed for some reason?

Finally, can wicd show a warning if it couldn't detect any wireless interfaces? I think the user should be alerted when there is a potential problem.

[Dan O'Reilly (oreilldf)]

What is in /sys/class/net/wlan0/ on your system? I'm surprised the wireless directory is missing.

The detection code could get moved to the backends. Right now it lives in wnettools.py right now because checking for a directory on the filesystem is pretty quick, and it just gets run twice at start up time (once for wired, once for wireless), so I didn't bother with an ioctl implementation for it.

Re: the default interface name not getting used, now that you mention it, we probably shouldn't be filling in a default interface at all. It will likely cause issues if we try to use a wireless interface we didn't actually detect and that probably doesn't exist.

I don't think removing the str() call from the return value of DetectWirelessInterface()/DetectWiredInterface() will work correctly unless you convert None to an empty string first. D-Bus can't return NoneType.

I think a warning should be getting logged when we don't detect a wireless interface. Bubbling it up to the GUI might get annoying for users who really don't have a wireless interface. Actually, that code gets executed so early in the daemon startup sequence that the UI probably won't even be running yet. We don't really have a system for queuing up messages in the daemon to send to the UI right now, so any signal we sent indicating the failure to detect the interface would likely be lost anyway. It's something to consider for wicd 2.0, though.

[Jun Inoue (jun-lambda)]

A listing of my /sys/class/net/wlan0 is attached.

It seems that DetectWirelessInterface()/DetectWiredInterface() are only used within the daemon. The daemon calls them directly without going through DBus, so that's probably why removing str() on them happened not to cause problems. Do these methods have to be available to the client? If a string must be returned, then the check in ReadConfig() should be changed to `if iface != "None"' from `if iface'.

There is indeed a warning being logged when an interface is not detected, and that's how I diagnosed the problem. I think your concern about annoying users who really don't have wireless is well-taken, and here's what I suggest in light of it. If no wireless is detected, then in the list of networks show a grayed-out pseudo-network that says "No wireless interface found." This way, it becomes clear to the user what's going on if there really is a wireless interface, and users who don't want to see that pseudo-network can just turn off a relevant option. A "don't show this warning" button that toggles that option might be on the pseudo-network too.

About the last paragraph: the client can know that an interface is missing when it receives config information from the daemon. This should be thought of as detecting suspicious configuration rather than detecting an event.

[Faustus (orlovm)]

I believe the issue at hand is that /sys/class/net/*/wireless/ interface is deprecated, and is therefore disabled in some kernels:

config WIRELESS_EXT_SYSFS
    bool "Wireless extensions sysfs files"
    default y
    depends on WIRELESS_EXT && SYSFS
    help
      This option enables the deprecated wireless statistics
      files in /sys/class/net/*/wireless/. The same information
      is available via the ioctls as well.

      Say Y if you have programs using it, like old versions of
      hal.

By the way, /proc/net/wireless is not a good alternative, since:
   In recent kernels, interfaces that are not active will not appear in /proc/net/wireless.
according to http://slackblogs.blogspot.com/2010/01/new-kernel-and-toolchains.html

So the best solution right now is probably to enable WIRELESS_EXT_SYSFS in the kernel, or to use the relevant ioctls calls in wicd.

[Markus Fuchs (mfuchs13)]

WIRELESS_EXT_SYSFS has been removed in kernel 3.6, so the issue comes up, again.

see http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/net/wireless/Kconfig

[David Paleino (dpaleino)]

Ok, severity raised and target set to 1.7.3. Will look at this bug ASAP.

Thanks for pinging me,
David

[Markus Fuchs (mfuchs13)]

Rather than running "iwgetid" like proposed in the patch, I would suggest to classify the network device as WiFi

1. by looking at DEVTYPE in /sys/class/net/wlan0/uevent

$ cat /sys/class/net/wlan0/uevent
DEVTYPE=wlan
INTERFACE=wlan0
IFINDEX=3

(notice that DEVTYPE is not present for ethernet or dial-in devices).

or

2. looking if "/sys/class/net/wlan0/phy80211" is present

or

3. just listing all devices in /sys/class/ieee80211/phy0/device/net/

(2) and (3) would be as efficient as the current solution which stopped working.

Markus

[David Paleino (dpaleino)]

Yes, I know.

I already investigated possible paths a while ago:

http://www.hanskalabs.net/posts/network-devices-python-udev-reloaded/

The only problem has been I haven't yet had enough time to start such a big change.

[Markus Fuchs (mfuchs13)]

The attached patch does the job

[David Paleino (dpaleino)]

Does /sys/class/ieee80211/ require a minimum kernel version?

I'd need to document that somewhere.

[Markus Fuchs (mfuchs13)]

I'm sorry for the delay.
The sysfs patch I commited is not a clean solution. The sysfs seems to be full of workarounds. Because the kernel doc states that "Accessing /sys/class/net/eth0/device is a bug in the application." you should not use wicd-sysfs-wifi-detect.patch.

I further investigated how to detect wireless devices by looking at the wireless-tools source code. The proper way until the new nl80211 subsystem totally replaces wireless-extensions, is using ioctls like I have done in the attached patch.

According to http://wireless.kernel.org/en/developers/Documentation/Wireless-Extensions this won't stop working in the future.

Wireless-Extensions are pretty old, so using this method should be compatible with kernels >= 2.6.13 (if not even older versions)

Markus

[David Paleino (dpaleino)]

Thanks for the patch.

Why are you looping over all those socket.*? It doesn't seem like you're using "t" anywhere inside the loop.

[David Paleino (dpaleino)]

Maybe:

  sk = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

should instead be:

  sk = socket.socket(t, socket.SOCK_DGRAM)

?

[David Paleino (dpaleino)]

Also, shouldn't:

  if sk is not None: break

rather be:

  if sk is None: continue

?

[David Paleino (dpaleino)]

Patch with above edits committed.

http://bazaar.launchpad.net/~wicd-devel/wicd/experimental/revision/830

[Rossana Kantor (rokud-ole-urlubu)]

I had a similar problem. Was not the firmware of wifi and wicd started without it. After installing the firmware and able to activate the wifi manually, wicd not yet exhibited the wifis networks. Some time, searching the configuration files, I noticed that the manager-settings.conf with wireless_interface = wan0 when it should be = wlan0.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Mantas Kriaučiūnas (mantas)]

Baltix distribution doesn't use wicd

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "wicd-sysfs-wifi-detect.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]