[PATCH] ipw2200: rework scan handling while associated

[PATCH] ipw2200: rework scan handling while associated

[Helmut Schaa]

This patch touches three different aspects:

1) If the firmware does not notify the driver about the scan completion withing
   the timeout, do not restart the firmware but simply cancel the scan. Hence,
   the association isn't dropped.

2) If one beacon was missed during a scan the driver will cancel the scan
   immediately. Hence, while associated most scans will not finish
   successfully (although the firmware tries to switch back to the operating
   channel at TBTT). Increase the number of allowed beacon misses to 3 to
   improve scanning while associated.

3) Fix passive a-band scanning timeout (only 2915). During a scan (while
   associated) the firmware will switch back to the operating channel to
   receive the beacon frame at each TBTT. The driver passes the times to the
   firmware how long it has to stay on a scanned channel depending on the
   channel flags (active vs. passive). The dwell time for passive channels
   is currently set to 120 (TUs). However, if the beacon interval is smaller
   than 120 the firmware will switch back to the operating channel before it
   stayed on the channel for 120 TUs. Thereupon the firmware will scan the
   same channel again but will again not be able to stay on that channel for
   120 TUs and enters an infinite loop until either the scan is canceled or
   the firmware gets restarted (that's my interpretation of what I was able
   to notice while sniffing the traffic).

   In order to avoid that infinite loop this patch adapts the dwell time for
   passive channels to beacon_interval - 10 if the card is in associated state.
   Of course the probability for finding an AP on a passive channel is reduced
   but it allows the scan to finish sucessfully even while associated.

Signed-off-by: helmut.schaa@googlemail.com
---

Could somebody please review the patch?
Should I split the patch into three single patches?
Thanks.

diff --git a/drivers/net/wireless/ipw2x00/ipw2200.c b/drivers/net/wireless/ipw2x00/ipw2200.c
index c73173a..f17b5b2 100644
--- a/drivers/net/wireless/ipw2x00/ipw2200.c
+++ b/drivers/net/wireless/ipw2x00/ipw2200.c
@@ -2310,10 +2310,10 @@ static void ipw_scan_check(void *data)
 {
 	struct ipw_priv *priv = data;
 	if (priv->status & (STATUS_SCANNING | STATUS_SCAN_ABORTING)) {
-		IPW_DEBUG_SCAN("Scan completion watchdog resetting "
-			       "adapter after (%dms).\n",
+		IPW_DEBUG_SCAN("Scan completion watchdog: aborting "
+			       "scan after (%dms).\n",
 			       jiffies_to_msecs(IPW_SCAN_CHECK_WATCHDOG));
-		queue_work(priv->workqueue, &priv->adapter_restart);
+		queue_work(priv->workqueue, &priv->abort_scan);
 	}
 }
 
@@ -4346,7 +4346,8 @@ static void ipw_handle_missed_beacon(struct ipw_priv *priv,
 		return;
 	}
 
-	if (priv->status & STATUS_SCANNING) {
+	if (priv->status & STATUS_SCANNING &&
+	    missed_count > priv->cancel_scan_threshold) {
 		/* Stop scan to keep fw from getting
 		 * stuck (only if we aren't roaming --
 		 * otherwise we'll never scan more than 2 or 3
@@ -6281,6 +6282,18 @@ static void ipw_add_scan_channels(struct ipw_priv *priv,
 	}
 }
 
+static int ipw_passive_dwell_time(struct ipw_priv *priv)
+{
+	/* staying on passive channels longer than the beacon interval causes
+	 * the firmware to enter an infinite loop. Hence, don't stay on passive
+	 * longer than the beacon interval.
+	 */
+	if (priv->status & STATUS_ASSOCIATED && priv->assoc_network->beacon_interval > 10)
+		return priv->assoc_network->beacon_interval - 10;
+	else
+		return 120;
+}
+
 static int ipw_request_scan_helper(struct ipw_priv *priv, int type, int direct)
 {
 	struct ipw_scan_request_ext scan;
@@ -6327,7 +6340,7 @@ static int ipw_request_scan_helper(struct ipw_priv *priv, int type, int direct)
 	  	IPW_DEBUG_WX("use passive scanning\n");
 	  	scan_type = IPW_SCAN_PASSIVE_FULL_DWELL_SCAN;
 		scan.dwell_time[IPW_SCAN_PASSIVE_FULL_DWELL_SCAN] =
-			cpu_to_le16(120);
+			cpu_to_le16(ipw_passive_dwell_time(priv));
 		ipw_add_scan_channels(priv, &scan, scan_type);
 		goto send_request;
 	}
@@ -6343,7 +6356,8 @@ static int ipw_request_scan_helper(struct ipw_priv *priv, int type, int direct)
 	scan.dwell_time[IPW_SCAN_ACTIVE_BROADCAST_AND_DIRECT_SCAN] =
 		cpu_to_le16(20);
 
-  	scan.dwell_time[IPW_SCAN_PASSIVE_FULL_DWELL_SCAN] = cpu_to_le16(120);
+  	scan.dwell_time[IPW_SCAN_PASSIVE_FULL_DWELL_SCAN] =
+		cpu_to_le16(ipw_passive_dwell_time(priv));
 	scan.dwell_time[IPW_SCAN_ACTIVE_DIRECT_SCAN] = cpu_to_le16(20);
 
 #ifdef CONFIG_IPW2200_MONITOR
@@ -8628,6 +8642,7 @@ static int ipw_sw_reset(struct ipw_priv *priv, int option)
 
 	priv->disassociate_threshold = IPW_MB_DISASSOCIATE_THRESHOLD_DEFAULT;
 	priv->roaming_threshold = IPW_MB_ROAMING_THRESHOLD_DEFAULT;
+	priv->cancel_scan_threshold = IPW_MB_SCAN_CANCEL_THRESHOLD;
 
 	priv->rts_threshold = DEFAULT_RTS_THRESHOLD;
 	priv->short_retry_limit = DEFAULT_SHORT_RETRY_LIMIT;
diff --git a/drivers/net/wireless/ipw2x00/ipw2200.h b/drivers/net/wireless/ipw2x00/ipw2200.h
index 0a84d52..ec133b9 100644
--- a/drivers/net/wireless/ipw2x00/ipw2200.h
+++ b/drivers/net/wireless/ipw2x00/ipw2200.h
@@ -245,6 +245,7 @@ enum connection_manager_assoc_states {
 #define HOST_NOTIFICATION_S36_MEASUREMENT_REFUSED       31
 
 #define HOST_NOTIFICATION_STATUS_BEACON_MISSING         1
+#define IPW_MB_SCAN_CANCEL_THRESHOLD                    3
 #define IPW_MB_ROAMING_THRESHOLD_MIN                    1
 #define IPW_MB_ROAMING_THRESHOLD_DEFAULT                8
 #define IPW_MB_ROAMING_THRESHOLD_MAX                    30
@@ -1218,6 +1219,7 @@ struct ipw_priv {
 	u32 hcmd_seq;		  /**< sequence number for hcmd */
 	u32 disassociate_threshold;
 	u32 roaming_threshold;
+	u32 cancel_scan_threshold;
 
 	struct ipw_associate assoc_request;
 	struct ieee80211_network *assoc_network;

Re: [Ipw2100-devel] [PATCH] ipw2200: rework scan handling while associated

[Zhu Yi]

On Thu, 2008-11-27 at 01:05 +0800, Helmut Schaa wrote:
> Could somebody please review the patch?
> Should I split the patch into three single patches?

Thank you for your patch. See my comments below.

> diff --git a/drivers/net/wireless/ipw2x00/ipw2200.c b/drivers/net/wireless/ipw2x00/ipw2200.c
> index c73173a..f17b5b2 100644
> --- a/drivers/net/wireless/ipw2x00/ipw2200.c
> +++ b/drivers/net/wireless/ipw2x00/ipw2200.c
> @@ -2310,10 +2310,10 @@ static void ipw_scan_check(void *data)
>  {
>  	struct ipw_priv *priv = data;
>  	if (priv->status & (STATUS_SCANNING | STATUS_SCAN_ABORTING)) {
> -		IPW_DEBUG_SCAN("Scan completion watchdog resetting "
> -			       "adapter after (%dms).\n",
> +		IPW_DEBUG_SCAN("Scan completion watchdog: aborting "
> +			       "scan after (%dms).\n",
>  			       jiffies_to_msecs(IPW_SCAN_CHECK_WATCHDOG));
> -		queue_work(priv->workqueue, &priv->adapter_restart);
> +		queue_work(priv->workqueue, &priv->abort_scan);
>  	}
>  }

We need something like the network Tx watchdog to prevent the firmware
stick forever when something is wrong during scan. At this time, no
command (include ABORT_SCAN) is going to be processed. We need something
can really move the firmware back to the correct state, that is the
adapter_restart. If you do see the watchdog files a lot, increasing
IPW_SCAN_CHECK_WATCHDOG should be the way to go.

> @@ -4346,7 +4346,8 @@ static void ipw_handle_missed_beacon(struct ipw_priv *priv,
>  		return;
>  	}
>  
> -	if (priv->status & STATUS_SCANNING) {
> +	if (priv->status & STATUS_SCANNING &&
> +	    missed_count > priv->cancel_scan_threshold) {
>  		/* Stop scan to keep fw from getting
>  		 * stuck (only if we aren't roaming --
>  		 * otherwise we'll never scan more than 2 or 3

I'm OK with this. Since you don't change priv->cancel_scan_threadhold
anywhere, can you use IPW_MB_SCAN_CANCEL_THRESHOLD directly? 

> @@ -6281,6 +6282,18 @@ static void ipw_add_scan_channels(struct ipw_priv *priv,
>  	}
>  }
>  
> +static int ipw_passive_dwell_time(struct ipw_priv *priv)
> +{
> +	/* staying on passive channels longer than the beacon interval causes
> +	 * the firmware to enter an infinite loop. Hence, don't stay on passive
> +	 * longer than the beacon interval.
> +	 */
> +	if (priv->status & STATUS_ASSOCIATED && priv->assoc_network->beacon_interval > 10)
> +		return priv->assoc_network->beacon_interval - 10;
> +	else
> +		return 120;
> +}

Is it still a problem with the above IPW_MB_SCAN_CANCEL_THRESHOLD used?
We assume most APs use 100ms beacon interval. But in case you are
associated with an AP which uses 20ms beacon interval, do you want to
set the passive_dwell time to 10ms here? 120ms makes sure we can at
least receive a beacon for normal APs.

BTW, another thing might help to resolve the scan-while-associate
problem. Currently we scan 5GHz band channels first, then 2.4GHz band
(see ipw_add_scan_channels). Normally most channels in 5GHz band are
passive ones. Thus they use longer dwell time. If we change to scan
2.4GHz band channels first, we can get more scan result before a scan
abort. Can you please try it?

Thanks,
-yi

Re: [Ipw2100-devel] [PATCH] ipw2200: rework scan handling while associated

[Helmut Schaa]

Am Freitag, 28. November 2008 schrieb Zhu Yi:
> On Thu, 2008-11-27 at 01:05 +0800, Helmut Schaa wrote:
> > Could somebody please review the patch?
> > Should I split the patch into three single patches?
> 
> Thank you for your patch. See my comments below.
> 
> > diff --git a/drivers/net/wireless/ipw2x00/ipw2200.c b/drivers/net/wireless/ipw2x00/ipw2200.c
> > index c73173a..f17b5b2 100644
> > --- a/drivers/net/wireless/ipw2x00/ipw2200.c
> > +++ b/drivers/net/wireless/ipw2x00/ipw2200.c
> > @@ -2310,10 +2310,10 @@ static void ipw_scan_check(void *data)
> >  {
> >  	struct ipw_priv *priv = data;
> >  	if (priv->status & (STATUS_SCANNING | STATUS_SCAN_ABORTING)) {
> > -		IPW_DEBUG_SCAN("Scan completion watchdog resetting "
> > -			       "adapter after (%dms).\n",
> > +		IPW_DEBUG_SCAN("Scan completion watchdog: aborting "
> > +			       "scan after (%dms).\n",
> >  			       jiffies_to_msecs(IPW_SCAN_CHECK_WATCHDOG));
> > -		queue_work(priv->workqueue, &priv->adapter_restart);
> > +		queue_work(priv->workqueue, &priv->abort_scan);
> >  	}
> >  }
> 
> We need something like the network Tx watchdog to prevent the firmware
> stick forever when something is wrong during scan. At this time, no
> command (include ABORT_SCAN) is going to be processed.

Hmm, I was able to reproduce the firmware looping endlessly reasonably
reliable (turned off the beacon-miss-cancels-scan-behaviour and increased the
scan watchdog timeout) and the ABORT_SCAN command was processed in that case
and canceled the scan which resulted in a
HOST_NOTIFICATION_STATUS_SCAN_COMPLETED notification with status 2 (not sure
if it really was 2). So, at least the failure I noticed here could be corrected
by aborting the scan instead of restarting the adapter.

What about the following:
After the first scan timeout we try to cancel the scan and if that does not
succeed in a few seconds we can still restart the fw.

> We need something 
> can really move the firmware back to the correct state, that is the
> adapter_restart. If you do see the watchdog files a lot, increasing
> IPW_SCAN_CHECK_WATCHDOG should be the way to go.

I see the timeout because the firmware will never stop scanning until either
the beacon miss notification cancels the scan or the IPW_SCAN_CHECK_WATCHDOG
timeout restarts the adapter. I already tried a scan timeout of 25 seconds but
the firmware insists on scanning the first passive channel (in my setup 52)
over and over again.

> > @@ -4346,7 +4346,8 @@ static void ipw_handle_missed_beacon(struct ipw_priv *priv,
> >  		return;
> >  	}
> >  
> > -	if (priv->status & STATUS_SCANNING) {
> > +	if (priv->status & STATUS_SCANNING &&
> > +	    missed_count > priv->cancel_scan_threshold) {
> >  		/* Stop scan to keep fw from getting
> >  		 * stuck (only if we aren't roaming --
> >  		 * otherwise we'll never scan more than 2 or 3
> 
> I'm OK with this. Since you don't change priv->cancel_scan_threadhold
> anywhere, can you use IPW_MB_SCAN_CANCEL_THRESHOLD directly? 

Right.

> > @@ -6281,6 +6282,18 @@ static void ipw_add_scan_channels(struct ipw_priv *priv,
> >  	}
> >  }
> >  
> > +static int ipw_passive_dwell_time(struct ipw_priv *priv)
> > +{
> > +	/* staying on passive channels longer than the beacon interval causes
> > +	 * the firmware to enter an infinite loop. Hence, don't stay on passive
> > +	 * longer than the beacon interval.
> > +	 */
> > +	if (priv->status & STATUS_ASSOCIATED && priv->assoc_network->beacon_interval > 10)
> > +		return priv->assoc_network->beacon_interval - 10;
> > +	else
> > +		return 120;
> > +}
> 
> Is it still a problem with the above IPW_MB_SCAN_CANCEL_THRESHOLD used?

Yes, it is. If the passive channel dwell time is larger than the beacon
interval the firmware will be stuck at the first passive channel. Thus the
scan will never succeed.

> We assume most APs use 100ms beacon interval. But in case you are
> associated with an AP which uses 20ms beacon interval, do you want to
> set the passive_dwell time to 10ms here? 

Yes, either that or just leaving all channels out that need to be scanned
for a longer period than the beacon interval. In case of a 20ms beacon interval
I'm pretty sure the active scan on all other channels will results in a
endless scan loop in the fw too.

> 120ms makes sure we can at 
> least receive a beacon for normal APs.

Yes, but I'd favour a successful scan that does not find every AP on passive
channels over a canceled scan.

> BTW, another thing might help to resolve the scan-while-associate
> problem. Currently we scan 5GHz band channels first, then 2.4GHz band
> (see ipw_add_scan_channels). Normally most channels in 5GHz band are
> passive ones. Thus they use longer dwell time. If we change to scan
> 2.4GHz band channels first, we can get more scan result before a scan
> abort. Can you please try it?

That's true but in case the scan is canceled the results are not forwarded
to user space as they may be incomplete.

Thanks,
Helmut

Re: [Ipw2100-devel] [PATCH] ipw2200: rework scan handling while associated

[Zhu Yi]

On Fri, 2008-11-28 at 17:31 +0800, Helmut Schaa wrote:
> Hmm, I was able to reproduce the firmware looping endlessly reasonably
> reliable (turned off the beacon-miss-cancels-scan-behaviour and increased the
> scan watchdog timeout) and the ABORT_SCAN command was processed in that case
> and canceled the scan which resulted in a
> HOST_NOTIFICATION_STATUS_SCAN_COMPLETED notification with status 2 (not sure
> if it really was 2). 

'2' is SCAN_COMPLETED_STATUS_ABORTED.

> So, at least the failure I noticed here could be corrected
> by aborting the scan instead of restarting the adapter.
>
> What about the following:
> After the first scan timeout we try to cancel the scan and if that does not
> succeed in a few seconds we can still restart the fw.

A watchdog is used to prevent unpredictable firmware hangs. In your
report, the firmware hang has a predictable pattern. We should focus on
resolving the real problem than workaround this issue.

> I see the timeout because the firmware will never stop scanning until either
> the beacon miss notification cancels the scan or the IPW_SCAN_CHECK_WATCHDOG
> timeout restarts the adapter. I already tried a scan timeout of 25 seconds but
> the firmware insists on scanning the first passive channel (in my setup 52)
> over and over again.

>From what you are saying, it looks like we have a real bug here. Why the
firmware keep sticking in the passive channel if dwell >
beacon_interval? I didn't see this in our testing environment. Normally
my scan for 24 channels takes about 1 second.

[...]

> Yes, it is. If the passive channel dwell time is larger than the beacon
> interval the firmware will be stuck at the first passive channel. Thus the
> scan will never succeed.
> 
> > We assume most APs use 100ms beacon interval. But in case you are
> > associated with an AP which uses 20ms beacon interval, do you want to
> > set the passive_dwell time to 10ms here? 
> 
> Yes, either that or just leaving all channels out that need to be scanned
> for a longer period than the beacon interval. In case of a 20ms beacon interval
> I'm pretty sure the active scan on all other channels will results in a
> endless scan loop in the fw too.
> 
> > 120ms makes sure we can at 
> > least receive a beacon for normal APs.
> 
> Yes, but I'd favour a successful scan that does not find every AP on passive
> channels over a canceled scan.

See above. I ack your idea 2. But 1 and 3 are workaround for a firmware
stuck problem on scan. Let's try to solve the real problem before
considering these workarounds. Looks like you are the only one reported
this problem. Would you like to test some debug patches?

> > BTW, another thing might help to resolve the scan-while-associate
> > problem. Currently we scan 5GHz band channels first, then 2.4GHz band
> > (see ipw_add_scan_channels). Normally most channels in 5GHz band are
> > passive ones. Thus they use longer dwell time. If we change to scan
> > 2.4GHz band channels first, we can get more scan result before a scan
> > abort. Can you please try it?
> 
> That's true but in case the scan is canceled the results are not forwarded
> to user space as they may be incomplete.

We only send an empty scan event when the scan is completed successfully
(vs. aborted). But user is still able to read the partial scan result
even if the scan is aborted. The ieee->network_list is updated anyway.

Thanks,
-yi

Re: [Ipw2100-devel] [PATCH] ipw2200: rework scan handling while associated

[Helmut Schaa]

Am Montag, 1. Dezember 2008 schrieb Zhu Yi:
> On Fri, 2008-11-28 at 17:31 +0800, Helmut Schaa wrote:
> > Hmm, I was able to reproduce the firmware looping endlessly reasonably
> > reliable (turned off the beacon-miss-cancels-scan-behaviour and increased the
> > scan watchdog timeout) and the ABORT_SCAN command was processed in that case
> > and canceled the scan which resulted in a
> > HOST_NOTIFICATION_STATUS_SCAN_COMPLETED notification with status 2 (not sure
> > if it really was 2). 
> 
> '2' is SCAN_COMPLETED_STATUS_ABORTED.

Right. That's what I got.

> > So, at least the failure I noticed here could be corrected
> > by aborting the scan instead of restarting the adapter.
> >
> > What about the following:
> > After the first scan timeout we try to cancel the scan and if that does not
> > succeed in a few seconds we can still restart the fw.
> 
> A watchdog is used to prevent unpredictable firmware hangs. In your
> report, the firmware hang has a predictable pattern. We should focus on
> resolving the real problem than workaround this issue.

Agreed. This part of the patch should not be necessary when either the third
part of the patch is applied or the firmware's behavior is fixed.

> > I see the timeout because the firmware will never stop scanning until either
> > the beacon miss notification cancels the scan or the IPW_SCAN_CHECK_WATCHDOG
> > timeout restarts the adapter. I already tried a scan timeout of 25 seconds but
> > the firmware insists on scanning the first passive channel (in my setup 52)
> > over and over again.
> 
> >From what you are saying, it looks like we have a real bug here. Why the
> firmware keep sticking in the passive channel if dwell >
> beacon_interval? I didn't see this in our testing environment. Normally
> my scan for 24 channels takes about 1 second.

That only happens while associated. Scanning while not associated works like
a charm.

Here are some more informations:
If I load the unmodified module with debug=0x3FFF I get the following log
when triggering a scan while associated:

ipw2200: U ipw_wx_set_scan Start scan
00000000 03 00 00 00 0D 24 28 2C  30 34 38 3C 40 95 99 9D   .....$(, 048<@...
00000010 A1 A5 4A 02 03 04 05 06  07 08 09 0A 0B 00 00 00   ..J..... ........
00000020 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
00000030 00 00 00 00 00 00 00 00  00 00 03 33 31 11 13 33   ........ ...31..3
00000040 33 03 33 33 33 33 30 00  00 00 00 00 00 00 00 00   3.33330. ........
00000050 00 00 00 00 00 00 00 00  78 00 14 00 14 00 14 00   ........ x.......
martian source 255.255.255.255 from 149.44.170.156, on dev eth1
ll header: ff:ff:ff:ff:ff:ff:00:19:99:28:58:5b:08:00
ipw2200: I ipw_rx_notification type = 12 (46 bytes)
ipw2200: I ipw_rx_notification Scan result for channel 36
ipw2200: I ipw_rx_notification type = 12 (46 bytes)
ipw2200: I ipw_rx_notification Scan result for channel 40
ipw2200: I ipw_rx_notification type = 12 (46 bytes)
ipw2200: I ipw_rx_notification Scan result for channel 44
ipw2200: I ipw_rx_notification type = 25 (4 bytes)
ipw2200: I ipw_rx_notification type = 12 (46 bytes)
ipw2200: I ipw_rx_notification Scan result for channel 48

The channels 36-48 are active 11a channels. The next channel would be 52 which
is a passive channel.

martian source 255.255.255.255 from 149.44.170.66, on dev eth1
ll header: ff:ff:ff:ff:ff:ff:00:0e:0c:aa:5c:c5:08:00
ipw2200: I ipw_rx_notification type = 25 (4 bytes)
ipw2200: I ipw_rx_notification type = 25 (4 bytes)
ipw2200: I ipw_rx_notification type = 25 (4 bytes)
ipw2200: I ipw_rx_notification type = 25 (4 bytes)
ipw2200: I ipw_rx_notification type = 25 (4 bytes)
ipw2200: I ipw_rx_notification type = 25 (4 bytes)
ipw2200: I ipw_rx_notification type = 17 (8 bytes)
ipw2200: I ipw_handle_missed_beacon Aborting scan with missed beacon.
ipw2200: I ipw_handle_missed_beacon Missed beacon: 1

Aha, the firmware noticed a beacon miss before the scan watchdog
restarts the firmware (the log is without timestamps, sorry).

ipw2200: I ipw_rx_notification type = 13 (4 bytes)
ipw2200: I ipw_rx_notification Scan completed: type 1, 5 channels, 2 status

Status 2 -> Scan aborted.

The log shows the lucky situation that a beacon is missed as otherwise the
firmware is restarted and the association is lost. However in most cases at
least one beacon is missed and therefore the association is not lost but of
course the scan results only contain APs on channel 36-48.

> See above. I ack your idea 2. But 1 and 3 are workaround for a firmware
> stuck problem on scan. Let's try to solve the real problem before 
> considering these workarounds.

Sure. However if it is not possible to fix the firmware the driver should work
around this issue.

> Would you like to test some debug patches?

Sure, no problem. 

> We only send an empty scan event when the scan is completed successfully
> (vs. aborted). But user is still able to read the partial scan result
> even if the scan is aborted. The ieee->network_list is updated anyway.

Right, but a user space application should not poll the scan results if the
driver normally reports the scan results.

Helmut

Re: [Ipw2100-devel] [PATCH] ipw2200: rework scan handling while associated

[Zhu Yi]

On Mon, 2008-12-01 at 18:10 +0800, Helmut Schaa wrote:
> That only happens while associated. Scanning while not associated
> works like
> a charm.
> 
> Here are some more informations:
> If I load the unmodified module with debug=0x3FFF I get the following
> log
> when triggering a scan while associated:
> 
> ipw2200: U ipw_wx_set_scan Start scan
> 00000000 03 00 00 00 0D 24 28 2C  30 34 38 3C 40 95 99 9D   .....$(,
> 048<@...
> 00000010 A1 A5 4A 02 03 04 05 06  07 08 09 0A 0B 00 00
> 00   ..J..... ........
> 00000020 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00
> 00   ........ ........
> 00000030 00 00 00 00 00 00 00 00  00 00 03 33 31 11 13
> 33   ........ ...31..3
> 00000040 33 03 33 33 33 33 30 00  00 00 00 00 00 00 00 00
> 3.33330. ........
> 00000050 00 00 00 00 00 00 00 00  78 00 14 00 14 00 14 00   ........
> x.......
> martian source 255.255.255.255 from 149.44.170.156, on dev eth1
> ll header: ff:ff:ff:ff:ff:ff:00:19:99:28:58:5b:08:00
> ipw2200: I ipw_rx_notification type = 12 (46 bytes)
> ipw2200: I ipw_rx_notification Scan result for channel 36
> ipw2200: I ipw_rx_notification type = 12 (46 bytes)
> ipw2200: I ipw_rx_notification Scan result for channel 40
> ipw2200: I ipw_rx_notification type = 12 (46 bytes)
> ipw2200: I ipw_rx_notification Scan result for channel 44
> ipw2200: I ipw_rx_notification type = 25 (4 bytes)
> ipw2200: I ipw_rx_notification type = 12 (46 bytes)
> ipw2200: I ipw_rx_notification Scan result for channel 48
> 
> The channels 36-48 are active 11a channels. The next channel would be
> 52 which
> is a passive channel.
> 
> martian source 255.255.255.255 from 149.44.170.66, on dev eth1
> ll header: ff:ff:ff:ff:ff:ff:00:0e:0c:aa:5c:c5:08:00
> ipw2200: I ipw_rx_notification type = 25 (4 bytes)
> ipw2200: I ipw_rx_notification type = 25 (4 bytes)
> ipw2200: I ipw_rx_notification type = 25 (4 bytes)
> ipw2200: I ipw_rx_notification type = 25 (4 bytes)
> ipw2200: I ipw_rx_notification type = 25 (4 bytes)
> ipw2200: I ipw_rx_notification type = 25 (4 bytes)
> ipw2200: I ipw_rx_notification type = 17 (8 bytes)
> ipw2200: I ipw_handle_missed_beacon Aborting scan with missed beacon.
> ipw2200: I ipw_handle_missed_beacon Missed beacon: 1
> 
> Aha, the firmware noticed a beacon miss before the scan watchdog
> restarts the firmware (the log is without timestamps, sorry).
> 
> ipw2200: I ipw_rx_notification type = 13 (4 bytes)
> ipw2200: I ipw_rx_notification Scan completed: type 1, 5 channels, 2
> status
> 
> Status 2 -> Scan aborted.

We will look at this.

Thanks,
-yi

Re: [Ipw2100-devel] [PATCH] ipw2200: rework scan handling while associated

[Zhu Yi]

On Wed, 2008-12-03 at 17:33 +0800, Zhu Yi wrote:
> On Mon, 2008-12-01 at 18:10 +0800, Helmut Schaa wrote:
> > That only happens while associated. Scanning while not associated
> > works like
> > a charm.
> > 
> > Here are some more informations:
> > If I load the unmodified module with debug=0x3FFF I get the following
> > log
> > when triggering a scan while associated:
> > 
> > ipw2200: U ipw_wx_set_scan Start scan
> > 00000000 03 00 00 00 0D 24 28 2C  30 34 38 3C 40 95 99 9D   .....$(,
> > 048<@...
> > 00000010 A1 A5 4A 02 03 04 05 06  07 08 09 0A 0B 00 00
> > 00   ..J..... ........
> > 00000020 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00
> > 00   ........ ........
> > 00000030 00 00 00 00 00 00 00 00  00 00 03 33 31 11 13
> > 33   ........ ...31..3
> > 00000040 33 03 33 33 33 33 30 00  00 00 00 00 00 00 00 00
> > 3.33330. ........
> > 00000050 00 00 00 00 00 00 00 00  78 00 14 00 14 00 14 00   ........
> > x.......
> > martian source 255.255.255.255 from 149.44.170.156, on dev eth1
> > ll header: ff:ff:ff:ff:ff:ff:00:19:99:28:58:5b:08:00
> > ipw2200: I ipw_rx_notification type = 12 (46 bytes)
> > ipw2200: I ipw_rx_notification Scan result for channel 36
> > ipw2200: I ipw_rx_notification type = 12 (46 bytes)
> > ipw2200: I ipw_rx_notification Scan result for channel 40
> > ipw2200: I ipw_rx_notification type = 12 (46 bytes)
> > ipw2200: I ipw_rx_notification Scan result for channel 44
> > ipw2200: I ipw_rx_notification type = 25 (4 bytes)
> > ipw2200: I ipw_rx_notification type = 12 (46 bytes)
> > ipw2200: I ipw_rx_notification Scan result for channel 48
> > 
> > The channels 36-48 are active 11a channels. The next channel would be
> > 52 which
> > is a passive channel.
> > 
> > martian source 255.255.255.255 from 149.44.170.66, on dev eth1
> > ll header: ff:ff:ff:ff:ff:ff:00:0e:0c:aa:5c:c5:08:00
> > ipw2200: I ipw_rx_notification type = 25 (4 bytes)
> > ipw2200: I ipw_rx_notification type = 25 (4 bytes)
> > ipw2200: I ipw_rx_notification type = 25 (4 bytes)
> > ipw2200: I ipw_rx_notification type = 25 (4 bytes)
> > ipw2200: I ipw_rx_notification type = 25 (4 bytes)
> > ipw2200: I ipw_rx_notification type = 25 (4 bytes)
> > ipw2200: I ipw_rx_notification type = 17 (8 bytes)
> > ipw2200: I ipw_handle_missed_beacon Aborting scan with missed beacon.
> > ipw2200: I ipw_handle_missed_beacon Missed beacon: 1
> > 
> > Aha, the firmware noticed a beacon miss before the scan watchdog
> > restarts the firmware (the log is without timestamps, sorry).
> > 
> > ipw2200: I ipw_rx_notification type = 13 (4 bytes)
> > ipw2200: I ipw_rx_notification Scan completed: type 1, 5 channels, 2
> > status
> > 
> > Status 2 -> Scan aborted.
> 
> We will look at this.

Sorry for the late reply.

We look at the firmware. If the dwell time is set longer than the time
remaining for firmware to switch back before DTIM TBTT, the firmware
will discard this request without feeding back any notifications. So if
we set passive dwell to 120, it is possible the scan request is ignored
by firmware (assume beacon interval is 100, DTIM for every other
beacon). But the firmware is not stuck in this case, it just won't send
us scan notifications any more.

So your patch is correct. Can you please remove the scan watchdog part
and resend it?

Thanks,
-yi

Re: [Ipw2100-devel] [PATCH] ipw2200: rework scan handling while associated

[Helmut Schaa]

Am Mittwoch, 10. Dezember 2008 schrieb Zhu Yi:
> On Wed, 2008-12-03 at 17:33 +0800, Zhu Yi wrote:
> > On Mon, 2008-12-01 at 18:10 +0800, Helmut Schaa wrote:
> > > That only happens while associated. Scanning while not associated
> > > works like
> > > a charm.
> > > 
> > > Here are some more informations:
> > > If I load the unmodified module with debug=0x3FFF I get the following
> > > log
> > > when triggering a scan while associated:
> > > 
> > > ipw2200: U ipw_wx_set_scan Start scan
> > > 00000000 03 00 00 00 0D 24 28 2C  30 34 38 3C 40 95 99 9D   .....$(,
> > > 048<@...
> > > 00000010 A1 A5 4A 02 03 04 05 06  07 08 09 0A 0B 00 00
> > > 00   ..J..... ........
> > > 00000020 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00
> > > 00   ........ ........
> > > 00000030 00 00 00 00 00 00 00 00  00 00 03 33 31 11 13
> > > 33   ........ ...31..3
> > > 00000040 33 03 33 33 33 33 30 00  00 00 00 00 00 00 00 00
> > > 3.33330. ........
> > > 00000050 00 00 00 00 00 00 00 00  78 00 14 00 14 00 14 00   ........
> > > x.......
> > > martian source 255.255.255.255 from 149.44.170.156, on dev eth1
> > > ll header: ff:ff:ff:ff:ff:ff:00:19:99:28:58:5b:08:00
> > > ipw2200: I ipw_rx_notification type = 12 (46 bytes)
> > > ipw2200: I ipw_rx_notification Scan result for channel 36
> > > ipw2200: I ipw_rx_notification type = 12 (46 bytes)
> > > ipw2200: I ipw_rx_notification Scan result for channel 40
> > > ipw2200: I ipw_rx_notification type = 12 (46 bytes)
> > > ipw2200: I ipw_rx_notification Scan result for channel 44
> > > ipw2200: I ipw_rx_notification type = 25 (4 bytes)
> > > ipw2200: I ipw_rx_notification type = 12 (46 bytes)
> > > ipw2200: I ipw_rx_notification Scan result for channel 48
> > > 
> > > The channels 36-48 are active 11a channels. The next channel would be
> > > 52 which
> > > is a passive channel.
> > > 
> > > martian source 255.255.255.255 from 149.44.170.66, on dev eth1
> > > ll header: ff:ff:ff:ff:ff:ff:00:0e:0c:aa:5c:c5:08:00
> > > ipw2200: I ipw_rx_notification type = 25 (4 bytes)
> > > ipw2200: I ipw_rx_notification type = 25 (4 bytes)
> > > ipw2200: I ipw_rx_notification type = 25 (4 bytes)
> > > ipw2200: I ipw_rx_notification type = 25 (4 bytes)
> > > ipw2200: I ipw_rx_notification type = 25 (4 bytes)
> > > ipw2200: I ipw_rx_notification type = 25 (4 bytes)
> > > ipw2200: I ipw_rx_notification type = 17 (8 bytes)
> > > ipw2200: I ipw_handle_missed_beacon Aborting scan with missed beacon.
> > > ipw2200: I ipw_handle_missed_beacon Missed beacon: 1
> > > 
> > > Aha, the firmware noticed a beacon miss before the scan watchdog
> > > restarts the firmware (the log is without timestamps, sorry).
> > > 
> > > ipw2200: I ipw_rx_notification type = 13 (4 bytes)
> > > ipw2200: I ipw_rx_notification Scan completed: type 1, 5 channels, 2
> > > status
> > > 
> > > Status 2 -> Scan aborted.
> > 
> > We will look at this.
> 
> Sorry for the late reply.

No problem.

> We look at the firmware. If the dwell time is set longer than the time
> remaining for firmware to switch back before DTIM TBTT, the firmware
> will discard this request without feeding back any notifications. So if
> we set passive dwell to 120, it is possible the scan request is ignored
> by firmware (assume beacon interval is 100, DTIM for every other
> beacon). But the firmware is not stuck in this case, it just won't send
> us scan notifications any more.

I see! Thanks for the explanation.

> So your patch is correct. Can you please remove the scan watchdog part
> and resend it?

Sure, will do.

Helmut