* Occasional truncated scan results
@ 2012-02-28 14:29 Ronald Wahl
2012-02-28 14:42 ` Johannes Berg
0 siblings, 1 reply; 6+ messages in thread
From: Ronald Wahl @ 2012-02-28 14:29 UTC (permalink / raw)
To: linux-wireless
Hi,
some time ago I had an issue with a wireless device that it couldn't
associate to the AP over some time. I found out that the BSS with the
corresponding SSID was the last in the scan list and was truncated - all
the IEs were missing and so the supplicant did not detect that it
supports WPA2 and hence ignored it.
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?
- ron
--
Ronald Wahl - ronald.wahl@raritan.com - 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Occasional truncated scan results
2012-02-28 14:29 Occasional truncated scan results Ronald Wahl
@ 2012-02-28 14:42 ` Johannes Berg
2012-02-28 15:15 ` Ronald Wahl
0 siblings, 1 reply; 6+ messages in thread
From: Johannes Berg @ 2012-02-28 14:42 UTC (permalink / raw)
To: Ronald Wahl; +Cc: linux-wireless
Hi,
> 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.
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.
johannes
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Occasional truncated scan results
2012-02-28 14:42 ` Johannes Berg
@ 2012-02-28 15:15 ` Ronald Wahl
2012-02-28 15:24 ` Johannes Berg
0 siblings, 1 reply; 6+ messages in thread
From: Ronald Wahl @ 2012-02-28 15:15 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
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@raritan.com - 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Occasional truncated scan results
2012-02-28 15:15 ` Ronald Wahl
@ 2012-02-28 15:24 ` Johannes Berg
2012-02-28 15:35 ` Ronald Wahl
0 siblings, 1 reply; 6+ messages in thread
From: Johannes Berg @ 2012-02-28 15:24 UTC (permalink / raw)
To: Ronald Wahl; +Cc: linux-wireless
On Tue, 2012-02-28 at 16:15 +0100, Ronald Wahl wrote:
> >> 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.
Ok. Yes, this could be fixed by making sure that a single BSS is
atomically written or not written -- probably simply by rolling back at
the end of the function if it didn't fit and returning an error etc. If
you wanted to work on this, I'd review & accept the patch, but I have no
intention whatsoever to do this myself :-)
johannes
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Occasional truncated scan results
2012-02-28 15:24 ` Johannes Berg
@ 2012-02-28 15:35 ` Ronald Wahl
2012-02-29 8:36 ` Kalle Valo
0 siblings, 1 reply; 6+ messages in thread
From: Ronald Wahl @ 2012-02-28 15:35 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
On 28.02.2012 16:24, Johannes Berg wrote:
> On Tue, 2012-02-28 at 16:15 +0100, Ronald Wahl wrote:
>> 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.
>
> Ok. Yes, this could be fixed by making sure that a single BSS is
> atomically written or not written -- probably simply by rolling back at
> the end of the function if it didn't fit and returning an error etc. If
> you wanted to work on this, I'd review& accept the patch, but I have no
> intention whatsoever to do this myself :-)
I'll first check if I can use the nl80211 interface in all cases. If not
I'll probably come up with a patch. Thanks!
- ron
--
Ronald Wahl - ronald.wahl@raritan.com - 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Occasional truncated scan results
2012-02-28 15:35 ` Ronald Wahl
@ 2012-02-29 8:36 ` Kalle Valo
0 siblings, 0 replies; 6+ messages in thread
From: Kalle Valo @ 2012-02-29 8:36 UTC (permalink / raw)
To: Ronald Wahl; +Cc: Johannes Berg, linux-wireless
Ronald Wahl <ronald.wahl@raritan.com> writes:
>> Ok. Yes, this could be fixed by making sure that a single BSS is
>> atomically written or not written -- probably simply by rolling back at
>> the end of the function if it didn't fit and returning an error etc. If
>> you wanted to work on this, I'd review& accept the patch, but I have no
>> intention whatsoever to do this myself :-)
>
> I'll first check if I can use the nl80211 interface in all cases. If
> not I'll probably come up with a patch. Thanks!
Even if switching to nl80211 would require a lot of effort from you I
still strongly recommend switching. That will save you a lot of
time in the future and the investment will surely pay back. PHBs like
that :)
--
Kalle Valo
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-02-29 8:36 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-02-28 14:29 Occasional truncated scan results Ronald Wahl
2012-02-28 14:42 ` Johannes Berg
2012-02-28 15:15 ` Ronald Wahl
2012-02-28 15:24 ` Johannes Berg
2012-02-28 15:35 ` Ronald Wahl
2012-02-29 8:36 ` Kalle Valo
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).