RE: [Madwifi-devel] passive scan timeout

[hqian <hq...@co...>]

> -----Original Message-----
> From: mad...@li... 
> [mailto:mad...@li...] On Behalf 
> Of Mathieu Lacage
> Sent: Wednesday, December 24, 2003 2:26 AM
> To: madwifi
> Cc: Henry Qian
> Subject: [Madwifi-devel] passive scan timeout
> 
> 
> hi all, Henry,
> 
> Recently, I decided to look into a patch you checked in one 
> or two months ago: the patch which adds a dev->trans = 
> jiffies; into ieee80211_newstate when the state is switched 
> from S_SCAN to S_SCAN. It took me a bit of time to figure out 
> exactly what kind of problem this patch fixed. Here is a summary:
> 	- when the driver is loaded and the associated network 
> interface is started, the driver starts a passive scan on the network.
> 	- Before starting the passive scan, the driver stops 
> the network interface (at this point, the linux network stack 
> will trigger a transmit watchdog about 5 seconds later if no 
> successful transmission occured). The reason for doing so 
> (rather than just refuse all packet transmission during 
> scanning) is that we want to re-use the transmission watchdog 
> machinery of the linux networking stack.
> 	- The small problem with this approach is that, 
> unfortunatly, 5 seconds is too short to do a passive scan on 
> all available channels (if you spend 200ms in each channel 
> since ath_dwelltime is set to 200ms). This means the 
> networking stack triggers the transmission watchdog during 
> each passive scan before it is completed. While the 
> transmission watchdog per se is not really a problem (5 
> seconds for a scan is, indeed a long time and I understand 
> why the networking stack would want to re-initialize us), the 
> problem is that the driver data structures are flushed 
> (including the list of APs found). A side effect of this 
> flushing is that the passive scan restarts but fails again 
> due to the timeout. It can never succeed.
> 
> Your current patch basically disables completely the 
> transmission timeout during passive scans by resetting the 
> watchdog every 200ms. This feels like a kludge I must say. I 
> can see four other solutions:
> 	- increase scan watchdog timeout duration to a value 
> bigger than ath_dwelltime*nb_channels.
> 	- decrease ath_dwelltime
> 	- disable watchdog timeout completely during passive 
> scans (by setting a scarigly long watchdog timeout duration 
> for example)
> 	- implement passive scan timeout with another mechanism 
> and forget about the facility provided by the linux networking stack.
> 
> I have implemented the first solution: it works pretty well. 
> Do you think we should implement something else ?
> 

Very well written summary.

What does dev->trans = jiffies do is petting watchdog, which is a
traditional way to get this kind of job done and it is widely used in
embedded systems.  But maybe we can have an inline function or a macro
like ieee80211_pet_watchdog() to make it more readable.  To me
"dev->trans = jiffies" is good enough.  I saw somewhere else in madwifi
also uses this.

Merry Christmas,

Henry


> regards,
> Mathieu
> -- 
> Mathieu Lacage <mat...@so...>
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign 
> up for IBM's Free Linux Tutorials.  Learn everything from the 
> bash shell to sys admin. Click now! 
> http://ads.osdn.com/?ad_id=1278&alloc_id=> 3371&op=click
> 
> 
> _______________________________________________
> Madwifi-devel mailing list
> Mad...@li...
> https://lists.sourceforge.net/lists/listinfo/madwifi-devel
>