Re: Passive Scanning Bugreport

Zhu Yi <[email protected]>
Newsgroups gmane.linux.drivers.ipw2100.devel
Organization Intel Corp.
Message-ID <[email protected]>
On Tue, 2006-08-01 at 18:51 +0200, Thomas King wrote:
> So, my question is: does the execution of passive scans depend on any
> data the access point is setting inside the host's firmware???

Yes, the DTIM setting in your AP. A scan is handled differently while
the STA is in the associated state and unassociated state. In an
unassociated state, the STA is free to scan all the channels till a
succesfully scan completion or abort. But in the assoicated state, the
STA can switch to other channels to listen beacons but it has to return
to the current associated channel before the next DTIM frame arrives.

> Did you try to install my patch and did you perform passive scans with
> different access points? What is your result??? 

Yes, I tried your patch. I can always get a scan completed notification
when the STA is associated. It could be either a succesfully scan
completed notification or a scan abort notification depending on the
dwell time and the DTIM setting from my AP (Asus WL-500g-X).

passive_dwell	DTIM	scaned_channels		found_APs
120ms		1	1 (abort)		1
30ms		1	5~11 (abort)		1~7
120ms		10	23 (successfully)       13
30ms		10	23 (successfully)       9

>From above results, set the dwell time to 120ms is more reasonable
because the default beacon interval is 100ms. Otherwise we are likely to
lose the beacon frames because we are not stay long enough on each
channel. On the other hand, because some APs set the default DTIM value
to a relative short period, we are unlikely to get the full scan result
when the STA is associated. I think this is OK since we are already
associated so we don't care much about other APs. Otherwise we should
use the active scan.


For your problem that you get the scan watchdog kicked off on some of
your APs, it might be a bug that the firmware is stuck somewhere. I'm
not sure because I cannot reproduce the problem. But I can give you a
suggestion on how to workaround it. You can change the scan watchdog
behaviour so that it sends a "scan abort" command if you don't receive a
scan complete event in, say 5 * HZ, and only kicks the adapter_restart
if you still don't receive a scan complete event in, say 10 * HZ. This
way, the firmware is more likely to send back the scan notification.
Would you like to implement this and see if it fixes your problem?

Thanks,
-yi

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.