Bug 265395 – net-wireless/wireless-tools not detecting AP's in an rf dense environment

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Matthew 2009-04-08 03:00:40 UTC]

The length field of wext data (iw_point.data) is 16 bits. The largest
value is thus 65535. During the attempts to increase buffer size the
buffer starts at 4096 and is doubled after each failure to fill. From the
time this length reaches 65536 it is effectively zero. We thus loose all
potential space from 32768 to 65535.

This problem is clear when scanning in a RF dense environment.


Reproducible: Always

Steps to Reproduce:
1. Go to an environment with many (~>50) AP's (Uni libraries are a good start)
2. Try and scan
3. See scanning failure, usually with print_scanning_info: Allocation failed

Actual Results:  
print_scanning_info: Allocation failed

Expected Results:  
A list of the AP's

This is mostly copied/pasted from the ILW site.

Patch is here: http://www.intellinuxwireless.org/bugzilla/attachment.cgi?id=1825

[Comment 1 Gef 2009-09-13 16:04:46 UTC]

Thanks for the head up ; this patch is in upstream's 30_pre8 release :

from iwlist.c (line 803) :
>/* Check if buffer was too small (WE-17 only) */
>              if((errno == E2BIG) && (range.we_version_compiled > 16)
>                 && (buflen < 0xFFFF))
(and line 825) :
>                  /* wrq.u.data.length is 16 bits so max size is 65535 */
>                  if(buflen > 65535)
>                    buflen = 65535;


wireless-tools-30_pre8 version bump is being discussed in bug #264446.

What about closing this one ?

[Comment 2 Thilo Bangert (RETIRED) (RETIRED) 2009-10-20 09:06:02 UTC]

wireless-tools-30_pre8 is now in the tree. thanks for the report.