Thread: [Madwifi-devel] passive scan timeout
Status: Beta
Brought to you by:
otaku
From: Mathieu L. <Mat...@so...> - 2003-12-24 07:26:32
|
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 ? regards, Mathieu -- Mathieu Lacage <mat...@so...> |
From: Michael S. <rin...@a-...> - 2003-12-24 09:34:13
|
On Wed, Dec 24, 2003 at 08:26:12AM +0100, Mathieu Lacage wrote: > - 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. In that case, I would opt to not use the Linux re-transmission watchdog for something it was not meant to be used for, and implement our own watchdog mechanism - if we need a watchdog to supervise scanning at all. Does stopping the network interface have any other side effects on higher layers? I am thinking about the case when we lose connectivity and start scanning again - when we are again associated to the AP, I want TCP connections pick up where they left. If taking the interface down makes higher layers drop TCP connections, then we should not do that. cu Michael -- "The Board views the endemic use of PowerPoint briefing slides instead of technical papers as an illustration of the problematic methods of technical communication at NASA." -- Columbia Accident Investigation Board Report |
From: hqian <hq...@co...> - 2003-12-24 23:56:12
|
> -----Original Message----- > From: mad...@li... > [mailto:mad...@li...] On Behalf > Of Michael Schwingen > Sent: Wednesday, December 24, 2003 4:30 AM > To: madwifi > Subject: Re: [Madwifi-devel] passive scan timeout > > > On Wed, Dec 24, 2003 at 08:26:12AM +0100, Mathieu Lacage wrote: > > - 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. > > In that case, I would opt to not use the Linux > re-transmission watchdog for something it was not meant to be > used for, and implement our own watchdog mechanism - if we > need a watchdog to supervise scanning at all. > > Does stopping the network interface have any other side > effects on higher layers? > > I am thinking about the case when we lose connectivity and > start scanning again - when we are again associated to the > AP, I want TCP connections pick up where they left. You raised a good point. A workaround is to set the channel first. So it won't re-scan at the reset. In other cases we might need re-scan when the current channel setting is not available anymore. Henry If taking > the interface down makes higher layers drop TCP connections, > then we should not do that. > > cu > Michael > -- > "The Board views the endemic use of PowerPoint briefing > slides instead of technical papers as an illustration of the > problematic methods of technical communication at NASA." -- > Columbia Accident Investigation Board Report > > > ------------------------------------------------------- > 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 > |
From: Michael S. <rin...@a-...> - 2003-12-27 11:32:50
|
On Wed, Dec 24, 2003 at 06:55:15PM -0500, hqian wrote: > > > > I am thinking about the case when we lose connectivity and > > start scanning again - when we are again associated to the > > AP, I want TCP connections pick up where they left. > > You raised a good point. A workaround is to set the channel first. So > it won't re-scan at the reset. In other cases we might need re-scan > when the current channel setting is not available anymore. In Germany (and probably throughout most of Europe), when using 802.11a with DFS, the access point is required to switch channels upon receiving a radar pulse signature, so we *definitely* need to be able to re-scan all channels when we lose connectivity, and in the normal case, it should be seamless (except for a pause until the new channel is found) regarding higher layers. cu Michael -- "The Board views the endemic use of PowerPoint briefing slides instead of technical papers as an illustration of the problematic methods of technical communication at NASA." -- Columbia Accident Investigation Board Report |
From: Mathieu L. <Mat...@so...> - 2004-01-05 08:51:10
|
On Wed, 2003-12-24 at 10:30, Michael Schwingen wrote: > On Wed, Dec 24, 2003 at 08:26:12AM +0100, Mathieu Lacage wrote: > > - 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. > > In that case, I would opt to not use the Linux re-transmission watchdog for > something it was not meant to be used for, and implement our own watchdog > mechanism - if we need a watchdog to supervise scanning at all. Yes, that would be my question: do we need a watchdog for passive scanning ? If so, what kind of watchdog ? > > Does stopping the network interface have any other side effects on higher > layers? No. It is simply a flag which signals that the network interface is temporarily unavailable for transmission. "Stopping" is probably a badly choosen verb here. Mathieu -- Mathieu Lacage <mat...@so...> |
From: hqian <hq...@co...> - 2003-12-24 23:32:52
|
> -----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 > |
From: Mathieu L. <Mat...@so...> - 2004-01-05 08:49:41
|
Hi, On Thu, 2003-12-25 at 00:32, hqian wrote: > What does dev->trans = jiffies do is petting watchdog, which is a Ok, my english is quite good but I did not know this expression. "to pet a watchdog"... Bwaaah :) > 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. Nothing else in madwifi "pets the watchdog" to disable it. The two other locations which do this do it because a packet was successfully sent which means the watchdog must be restarted. This has nothing to do with disabling the watchdog. I don't understand why you believe restarting continuously the watchdog is the right way to fix this problem. As I said, this feels like a kludge to avoid having to deal with the relatively long scanning time. However, maybe I am completely wrong and maybe this kind of thing is customary. I will probably checkin a similar fix tomorow in the WLAN2 branch. Mathieu -- Mathieu Lacage <mat...@so...> |