On Thu, Feb 5, 2009 at 11:52 AM, Jouni Malinen <j@xxxxx> wrote: > On Thu, Feb 05, 2009 at 10:44:07AM +0200, Jouni Malinen wrote: >> Trying to use 131072 byte buffer is actually a bug in wpa_supplicant and >> even the previous attempt of 65536 is not valid. I did not realize >> this before, but it was pointed out to me some time ago that the length >> field in struct iw_point is only 16 bits, so there is actually a strict >> limit of 65535 bytes of data available through SIOCGIWSCAN. >> >> 65536 ends up being truncated into zero, so I would assume the largest >> buffer wpa_supplicant tries to use in practice is 32768 bytes. I'll fix >> this so that the next doubling is actually limited to 65535 (assuming it >> works with WEXT code in kernel). I would hope that this helps quite a >> bit as far as wpa_supplicant is concerned (almost doubling the maximum >> results buffers). > > This moved the maximum from 88 BSSes (using IEEE 802.11g with WPA2 as an > example here; smaller number for 802.11n etc. extensions) to 177 BSSes > (or 178, but the last one was truncated, I think; the returned buffer > was 65534 bytes long). After that, things get bad, though, since there > is no way for the user space to fetch the buffer (at least with mac80211 > scan reporting). > >> As far as a possible workaround in kernel code is concerned, >> length=65535 could be considered a special case. Since it is clear that >> userspace cannot provide a larger buffer, there is not much point in >> returning -E2BIG. Instead, the results could be truncated after the last >> BSS that fit into the buffer and that would be returned to userspace. >> This is likely going to be much more useful than not being able to >> receive any result. > > This should have helped with the test above when the number of BSSes > went past 178. Sure, all BSSes would not be reported, but should the > driver do any sorting based on BSS preference (e.g., signal strength), > this would likely work for most use cases. Just a thought If user space will be able to merge 2 scan results we can then split then in 2 separate reports.... Tomas -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
