On 28.02.2012 15:42, Johannes Berg wrote:
After some playing with different wireless devices I discovered that
this is not limited to specific drivers so I digged a bit in the scan
code in net/wireless/scan.c and found the culprit: The scan result is
put together with the iwe_stream_* functions that place data into a
provided buffer if enough space is available in the buffer. Otherwise
the functions do just nothing. Before a BSS is added there is a check if
some minimum space is available but after the BSS has been added it is
not clear how many data actually has been placed into the buffer. So
especially (but not neccessarily only) the last BSS is prone to be
incomplete. I my case all the IEs were missing and this was persistent
over some time (the persitence behavior seems to differs between drivers
- probably depends on how the scanning is implemented).
Currently I implemented a heuristic that checks if some minimum space
(currently 256 bytes) is still free _after_ adding a BSS and otherwise
return -E2BIG so the user space can provide a larger buffer but this is
a crappy hack.
Can the code be changed in some way to more reliably detect if some data
did not fit into the buffer and report this to user space?
Unfortunately not. The maximum buffer size userspace can provide is
limited to 64k. In busy environments, this size can be exceeded. As a
result, if we do this, you can't get *any* scan results in such
environments. I believe the current code is almost the best we can do
for wireless extensions, but it may be possible to implement never
truncating a single BSS entry.
My problem is not that the scan results are larger than 64k. The user
space is coded so that it provides a small buffer that is doubled in
size until the data fits into the buffer. But the kernel code does not
always detect the case that the buffer is almost full and just starts
skipping some data without notifying user space with E2BIG.
That said, there's a very simple fix for this. Since you're talking
about net/wireless/scan.c, you're obviously using a driver with cfg80211
support. Ditch wireless extensions completely and use nl80211 instead,
you'll be much happier overall as it has no such limitations and more
features.
Thanks for the hint. I will have a look into this.
- ron
--
Ronald Wahl - ronald.wahl@xxxxxxxxxxx - Phone +49 375271349-0 Fax -99
Raritan Deutschland GmbH, Kornmarkt 7, 08056 Zwickau, Germany
USt-IdNr. DE813094160, Steuer-Nr. 227/117/01749
Amtsgericht Chemnitz HRB 23605
Geschäftsführung: Stuart Hopper, Burkhard Wessler
--
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
