linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ronald Wahl <ronald.wahl@raritan.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: linux-wireless@vger.kernel.org
Subject: Re: Occasional truncated scan results
Date: Tue, 28 Feb 2012 16:15:50 +0100	[thread overview]
Message-ID: <4F4CEFA6.2090005@raritan.com> (raw)
In-Reply-To: <1330440166.3368.7.camel@jlt3.sipsolutions.net>

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

  reply	other threads:[~2012-02-28 15:15 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2012-02-28 15:24     ` Johannes Berg
2012-02-28 15:35       ` Ronald Wahl
2012-02-29  8:36         ` Kalle Valo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F4CEFA6.2090005@raritan.com \
    --to=ronald.wahl@raritan.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).