wicd can't detect wireless interface

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.

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.

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.

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

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

Thanks for pinging me,
David

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

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.

The attached patch does the job

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

I'd need to document that somewhere.

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

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.

Maybe:

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

should instead be:

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

?

Also, shouldn't:

  if sk is not None: break

rather be:

  if sk is None: continue

?

Patch with above edits committed.

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

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.

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

Baltix distribution doesn't use wicd

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.]