ipw2200 driver doesn't report any capabilities or wireless properties using the nl80211 interface to network-manager

Would it be possible for you to open an upstream bug report at bugzilla.kernel.org [1]? That will allow the upstream Developers to examine the issue, and may provide a quicker resolution to the bug.

If you are comfortable with opening a bug upstream, It would be great if you can report back the upstream bug number in this bug report. That will allow us to link this bug to the upstream report.

[1] https://wiki.ubuntu.com/Bugs/Upstream/kernel

Thank you for taking the time to file a bug report on this issue.

However, given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

We have noted that there is a newer version of the development kernel than the one you last tested when this issue was found. Please test again with the newer kernel and indicate in the bug if this issue still exists or not.

You can update to the latest development kernel by simply running the following commands in a terminal window:

    sudo apt-get update
    sudo apt-get dist-upgrade

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

If you want this bot to quit automatically requesting kernel tests, add a tag named: bot-stop-nagging.

 Thank you for your help, we really do appreciate it.

Filed an upstream bug: https://bugzilla.kernel.org/show_bug.cgi?id=43049
I didn't check with 22.35 but the changelog doesn't list any changes in wireless so I assume it was not fixed accidently.

Thanks for the rip regarding nl80211/wext - I modified the code to not try nl80211 first and just use wext.

seems to work. Uploading packages here - https://launchpad.net/~jools/+archive/ipw2200

Would be nice if network manager could have a workaround to check for this device and force wext or something, as I doubt the kernel fix will be done in time.

s/rip/tip

Also affects network-manager. We can try to play nice and special case ipw2200 as a distro patch if it's feasible. I'll look into the feasibility of doing this in the NM code; hopefully we have the necessary data to make this change.

Jools, since you already patched network-manager for your own use, would you mind testing the attached patch? I don't happen to have devices that use the ipw2100 or ipw2200 driver.

some compile errors with that patch. drvinfo.driver is a char[32] and brackets are mismatched.

wifi-utils.c: In function 'wifi_utils_init':
wifi-utils.c:76:17: error: incompatible types when assigning to type 'char[32]' from type 'void *'
wifi-utils.c:85:3: error: expected ')' before 'ret'
wifi-utils.c:95:1: error: expected expression before '}' token

the unbalanced brackets at 85

i've made some changes so it compiles, but im not 100% sure if it's correct (I'm a bit under the weather at the moment).

revised patch to test

Index: network-manager-0.9.4.0/src/wifi/wifi-utils.c
===================================================================
--- network-manager-0.9.4.0.orig/src/wifi/wifi-utils.c 2012-03-01 05:26:37.000000000 +0000
+++ network-manager-0.9.4.0/src/wifi/wifi-utils.c 2012-04-06 21:01:47.808432103 +0100
@@ -25,6 +25,11 @@
 #include <string.h>
 #include <glib.h>

+#include <sys/socket.h>
+#include <linux/sockios.h>
+#include <linux/if.h>
+#include <linux/ethtool.h>
+
 #include "wifi-utils.h"
 #include "wifi-utils-private.h"
 #include "wifi-utils-nl80211.h"
@@ -57,11 +62,30 @@
 wifi_utils_init (const char *iface, int ifindex, gboolean check_scan)
 {
  WifiData *ret;
+ struct ifreq ifr;
+ struct ethtool_drvinfo drvinfo;
+ int fd;

  g_return_val_if_fail (iface != NULL, NULL);
  g_return_val_if_fail (ifindex > 0, NULL);

- ret = wifi_nl80211_init (iface, ifindex);
+ fd = socket(AF_INET, SOCK_DGRAM, 0);
+
+ strcpy(ifr.ifr_name, iface);
+ drvinfo.cmd = ETHTOOL_GDRVINFO;
+ drvinfo.driver[0] = '\0';
+
+ ifr.ifr_data = &drvinfo;
+
+ ioctl(fd, SIOCETHTOOL, &ifr);
+
+ if (drvinfo.driver[0] &&
+ (strcmp (drvinfo.driver, "ipw2200") == 0) ||
+ (strcmp (drvinfo.driver, "ipw2100") == 0))
+ ret = NULL;
+ else
+ ret = wifi_nl80211_init (iface, ifindex);
+
  if (ret == NULL) {
 #if HAVE_WEXT
   ret = wifi_wext_init (iface, ifindex, check_scan);

sorry that should have been an attachment. my brain is totally non functional today.

patch seems to work. thanks for that.

ok that patch obviously solves the problem for all ipw2100 und ipw2200 owners but there are potentially some more drivers affected by the strange kernel behavior of not reporting a non nl80211 compliant driver to userspace (at least not in an way nm understands). If I assume that every driver that is nl80211 compatible doesn't need to supply information by means of an iw_range struct because this is done by wext-compat.c for it just grepping the kernel source for filling of this structure yields the following possibly affected drivers: ps3_gelic_wireless.c, wl3501_cs.c, atmel.c, zd1201.c, airo.c, ray_cs.c, hostap, prism54, r8180_wx.c, vt6655, rtl8712, wlags49_h2, vt6656, rtl8192u, rtl8192e. On the other hand does the patch also handle Intel Pro Wireless 2915 which is handled by ipw2200 too? What about checking if a wireless driver can encrypt at all for determining that nl80211 shouldn't be used? A wireless device that doesn't even support WEP is pretty useless I think.

I suggest this patch which doesn't rely on string comparison of driver names that much.

Looks like a patch that could go upstream too. if nl80211 reports no capabilities then try wext. and considering your list (appreciate your research here), it seems a good option. only recently nm added support for the nl80211 interface, so perhaps they are a bit ahead of the kernel in this respect.

Looks reasonable; but let's get upstream input on that patch before including it.

Just found this patch: http://article.gmane.org/gmane.linux.kernel.wireless.general/88613

That kernel patch will fix the encryption reporting and ruin my detection patch in any kernel where this will be incorportated. That makes things work to some extend, but you won't get any signal strength for the network you are connected.

Why not?

Omar, if signal strength also needs to be adjusted, please make sure this is clear in the upstream bug report. AFAIK there is no issue with signal level on ipw2x00 drivers.

I think there's a related bug here. network-manager grays out the WPA network when a card has no reported WPA capabilities. But I could still get at WEP networks, even if it wasn't letting me connect. Shouldn't WEP also get grayed out if the card has no WEP capabilities listed?

I think I saw some patch (ubuntu only?) that adds wep support even if nothing is advertised but only in certain cases. Nothing is added if you manually try to add a network.
I added a note to my upstream bug but I didn't mention this behavior I observed in my originial bug report upstream and I didn't do any research why there is no signal strength. Might be a nm bug because I'm connected to a network where the encryption is not supported or it might be something in the ipw2x00 drivers.

This bug was fixed in the package network-manager - 0.9.4.0-0ubuntu3

---------------
network-manager (0.9.4.0-0ubuntu3) precise; urgency=low

  * debian/patches/ipw2x00-no-nl80211.patch: workaround ipw2x00 drivers not
    reporting wireless encryption capabilities properly: if caps are 0 (none
    reported), then fail the nl80211 initialization and fallback to wext.
    Thanks to Omar Siam for the patch. (LP: #973241)
 -- Mathieu Trudel-Lapierre <email address hidden> Thu, 12 Apr 2012 11:23:37 -0400

Omar Siam, the upstream fix is available in Precise+ as per http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-precise.git;a=commit;h=a141e6a0097118bb35024485f1faffc0d9042f5c . Hence, this report is considered closed. However, if this is still reproducible, please reopen by executing the following in a terminal:
apport-collect -p linux 973241