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