Bug 534003 - Allocation failure scanning for APs
Summary: Allocation failure scanning for APs
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: wireless-tools
Version: 17
Hardware: All
OS: Linux
medium
urgent
Target Milestone: ---
Assignee: Dan Williams
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-11-10 01:22 UTC by Derek Atkins
Modified: 2013-08-01 18:16 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-08-01 18:16:49 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
BSS list (82.13 KB, text/plain)
2009-11-11 07:46 UTC, Derek Atkins
no flags Details

Description Derek Atkins 2009-11-10 01:22:55 UTC
Description of problem:

I'm at the IETF sitting around with hundreds of APs around me (I'm guessing, I can't tell).  Network Manager failed to connect to anything, and when I try to determine why I get:

[root@pgpdev warlord]# iwlist wlan0 scan
print_scanning_info: Allocation failed

I can manually ifup and iwconfig to get on the network, but not being able to scan is a MAJOR issue.

Version-Release number of selected component (if applicable):

wireless-tools-29-2.fc9.i386
NetworkManager-0.7.1-1.fc10.i386
wpa_supplicant-0.6.4-3.fc10.i386
compat-wireless-2.6.31-rc4
iwl3954 driver

How reproducible:

Well, it's certainly 100% reproducible as I'm sitting here in Orchid East at the IETF.

Steps to Reproduce:
1. Sit in this seat
2. Run iwlist wlan0 scan
3.
  
Actual results:

[root@pgpdev warlord]# iwlist wlan0 scan
print_scanning_info: Allocation failed


Expected results:

Valid scan information.

Additional info:

Is there some limited buffer size of #scan results that arbitrarily limits the scan results?

Comment 1 Derek Atkins 2009-11-10 02:11:23 UTC
FYI, the IETF is in Japan (so I'm living strange hours from a US standpoint) and I'm only in this environment through Friday, which is why I marked it Urgent.  I'm happy to do any kind of testing.

Comment 2 John W. Linville 2009-11-10 14:46:59 UTC
Icky wireless_tools crud... :-(

Do you get acceptable results from "iw dev wlan0 scan" instead?

Comment 3 Derek Atkins 2009-11-10 15:47:23 UTC
Where can I find 'iw'?

which iw
/usr/bin/which: no iw in (/usr/sbin:/sbin:/usr/lib/qt-3.3/bin:/usr/kerberos/bin:/usr/lib/ccache:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin)


I'll note that I think it's more than just the wireless-tools -- NM/wpa_supplicant also seems to fail to scan.

Comment 4 John W. Linville 2009-11-10 16:03:04 UTC
Hmmm...it is available for F10 through yum, but the version in F10 may not have the scanning support.

The message you are reporting is coming from iwlist.  However it is certainly possible that wpa_supplicant has a similar problem related to the size of the scan report.  In fact, wireless extensions may have limitations involved here as well.  FWIW, I think modern APs tend to further complicate things by including more IEs in their beacons and probe responses as well...

Comment 5 John W. Linville 2009-11-10 16:07:24 UTC
Let's see if a more modern version still builds for F-10... :-)

   http://koji.fedoraproject.org/koji/taskinfo?taskID=1798606

Comment 6 Derek Atkins 2009-11-10 16:26:13 UTC
Well, I need some sleep.. I'll take a look at it tomorrow when I wake up and get back to the IETF and try to reproduce the problem.  Unfortunately it IS location dependent.  I saw it in Orchid East, but not in a different room.   So if your iw build works should I try that or the one that's in the current F10 repos?

Comment 7 John W. Linville 2009-11-10 16:33:50 UTC
I don't think the current F10 one supports scanning, so you'll need to try the one from the build in comment 5.

Anyway, that won't actually fix iwlist or wpa_supplicant.  But it might give you a work-around for now and shed light on the actual issue.

Comment 8 Derek Atkins 2009-11-11 00:17:01 UTC
I'm confused.  How will 'iw' give me a workaround to NetworkManager/wpa_supplicant not working?

Comment 9 John W. Linville 2009-11-11 00:36:44 UTC
"I can manually ifup and iwconfig to get on the network, but not being able to
scan is a MAJOR issue."

The iw tool should give you a way to scan.

Comment 10 Derek Atkins 2009-11-11 00:53:18 UTC
Ah, perhaps I should've been more clear meaning the the lack of an ability to scan means that NM cannot connect which means I cannot start my NM-controlled VPN which means I cannot get work done, and THAT is a Major issue. ;)

At least being able to scan with iw I'll be able to report how many stations I see, but I need wpa_supplicant/NM to scan in order to effectively work.  Being able to ifup is a partial workaround, enough to file this bug report, but isn't a full workaround.  On the other hand moving to a different location in the venue such that I don't hear as many APs is also a workaround, but it doesn't fix the underlying bug that there's a hard limit to the amount of scan data and past that the system loses completely instead of returning only partial scan data.

Comment 11 Derek Atkins 2009-11-11 07:44:31 UTC
FYI, iw does return data:

[root@pgpdev warlord]# iw dev wlan0 scan | grep ^BSS | wc
    149     596    4917

So, 149 APs...   I'll attach the output from 'iw dev wlan0 scan' so you can see.  Unfortunately NM croaked in this environment....  Not sure who's bug this is to fix, NM, wpa_supplicant, wireless-tools, ....  But they all fail in this environment.

Comment 12 Derek Atkins 2009-11-11 07:46:42 UTC
Created attachment 368996 [details]
BSS list

This is the output of "iw dev wlan0 scan" in the main room here at the IETF.

Comment 13 John W. Linville 2009-11-11 13:49:38 UTC
The common thread is likely the wireless extensions API, which is difficult/impossible to fix while maintaining backwards compatibility.  That's why "we" (i.e. the upstream wireless developers) have developed the nl80211 API used by the iw tool.

It's possible that wireless-tools could be fixed to at least deal with a subset of the available APs -- I found the error message, but didn't analyze the code too closely (I'm more of a kernel guy).  wpa_supplicant may be similarly fixable, but I don't know that code at all.  NM relies on wpa_supplicant, so it isn't really to blame.

Thanks for the report re: iw and the further explanation of the issue.  At least that points at the source of the problem.

Comment 14 Derek Atkins 2009-11-11 14:04:14 UTC
John, you're welcome for the report.  I figure that there's no way to get the code fixed if it doesn't get reported.  Pretty much there is only one set of rooms at the IETF where I can see all 149ish APs, so GENERALLY I'm okay, but it would still be nice to get this fixed at some point. 

It seems to be a general integration problem, so I was hoping to get the right cross section of people to see the issue and maybe find a workaround.  I was pretty sure it wasn't an issue in the kernel per-se, but more likely in the wireless extensions or the code that pulls the data out of the kernel.

Are there any other people that should be CC'd on this bug?

Comment 15 John W. Linville 2009-11-11 15:26:07 UTC
Well, between me and Dan I think the right people are "in the room". :-)  Dan probably knows better than I as to whether the wext driver to wpa_supplicant is fixable for this issue...

Comment 17 Derek Atkins 2009-11-12 00:13:10 UTC
Interesting.  So are those patches included in any F10 kernel?

Comment 18 Bug Zapper 2009-11-18 09:31:51 UTC
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 19 John W. Linville 2009-11-18 13:56:26 UTC
The first one was reverted due to userland ABI breakage.  The second one was the stopgap.  Incidentally, this is one of several similar cases where fixing wireless extensions without breaking something else became impossible.

Comment 20 Bug Zapper 2009-12-18 09:45:49 UTC
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 21 Henrique Martins 2012-09-15 17:50:53 UTC
It's almost three years later and 7 fedora versions and I'm sitting at my sister-in-law's apartment seeing 71 access points and not being able to connect to the network until I reboot under Windows 7.  How does one get around this problem?

Comment 22 Marko Myllynen 2012-09-17 09:57:52 UTC
Latest 30-pre upstream versions now contain a patch which fixes the issue, see:

https://bugs.archlinux.org/task/15363
http://mailman.archlinux.org/pipermail/arch-commits/2012-August/174852.html
http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html

Dan, any chances to include the patch in Fedora on top of v29?

Thanks.

Comment 23 Dan Williams 2013-02-23 09:30:21 UTC
(In reply to comment #21)
> It's almost three years later and 7 fedora versions and I'm sitting at my
> sister-in-law's apartment seeing 71 access points and not being able to
> connect to the network until I reboot under Windows 7.  How does one get
> around this problem?

The workaround is to use wpa_supplicant with the 'nl80211' driver (-D nl80211); if you want a manual scan, use 'iw dev wlan0 scan trigger' then 'iw dev wlan0 scan dump'.  We'll probably get around to fixing wireless-tools, but /sbin/iw and nl80211 are the way forward here, not wireless-tools and WEXT.

Comment 24 Dan Williams 2013-02-23 09:32:12 UTC
Note that NM uses wpa_supplicant's nl80211 driver since 0.9.4, so it shouldn't run into the WEXT allocation issue.

Comment 25 Fedora End Of Life 2013-07-04 06:41:12 UTC
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 26 Fedora End Of Life 2013-08-01 18:16:55 UTC
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.