ipw2200: rework scan handling while associated

PATCH In review Helmut Schaa 2 participants 8 messages Nov 26, 2008 – Dec 10, 2008 Networking drivers (wireless)

lore

Share & tools

lore

Helmut Schaa

author

2008-11-26 17:13 UTC #0 lore raw

PATCH 1/1 ipw2200: rework scan handling while associated

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 [email protected]

---

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

drivers/net/wireless/ipw2x00/ipw2200.c +21 -6

index c73173a..f17b5b2 100644
@@ -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;

drivers/net/wireless/ipw2x00/ipw2200.h +2 -0

index 0a84d52..ec133b9 100644
@@ -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;

Zhu Yi

2008-11-28 08:50 UTC #1 lore raw

Quoted 2 lines · Helmut Schaa

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

Thank you for your patch. See my comments below.

Quoted 7 lines

drivers/net/wireless/ipw2x00/ipw2200.c +0 -0

index c73173a..f17b5b2 100644
@@ -2310,10 +2310,10 @@ static void ipw_scan_check(void *data)
 {
 	struct ipw_priv *priv = data;

drivers/net/wireless/ipw2x00/ipw2200.c static void ipw_scan_check(void *data) · line 2318

Quoted 10 lines

drivers/net/wireless/ipw2x00/ipw2200.c +3 -3

 	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.

drivers/net/wireless/ipw2x00/ipw2200.c static void ipw_handle_missed_beacon(struct ipw_priv *priv, · line 4353

Quoted 10 lines

drivers/net/wireless/ipw2x00/ipw2200.c +2 -1

@@ -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?

Quoted 5 lines

drivers/net/wireless/ipw2x00/ipw2200.c +1 -0

@@ -6281,6 +6282,18 @@ static void ipw_add_scan_channels(struct ipw_priv *priv,
 	}
 }
 
+static int ipw_passive_dwell_time(struct ipw_priv *priv)

drivers/net/wireless/ipw2x00/ipw2200.c static void ipw_add_scan_channels(struct ipw_priv *priv, · line 6295

Quoted 10 lines

drivers/net/wireless/ipw2x00/ipw2200.c +10 -0

+{
+	/* 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

Helmut Schaa

author

2008-11-28 09:31 UTC #2 lore raw

Am Freitag, 28. November 2008 schrieb Zhu Yi:

Quoted 19 lines · Helmut Schaa

Quoted 2 lines

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

Thank you for your patch. See my comments below.

Quoted 13 lines

drivers/net/wireless/ipw2x00/ipw2200.c +2 -2

index c73173a..f17b5b2 100644
@@ -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));

Quoted 8 lines

drivers/net/wireless/ipw2x00/ipw2200.c static void ipw_scan_check(void *data) · line 2318
Quoted 4 lines
drivers/net/wireless/ipw2x00/ipw2200.c +1 -1
-		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.

Quoted 4 lines

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.

Quoted 4 lines

Quoted 4 lines
drivers/net/wireless/ipw2x00/ipw2200.c +0 -0
@@ -4346,7 +4346,8 @@ static void ipw_handle_missed_beacon(struct ipw_priv *priv,
 		return;
 	}
 

Quoted 9 lines

drivers/net/wireless/ipw2x00/ipw2200.c static void ipw_handle_missed_beacon(struct ipw_priv *priv, · line 4353
Quoted 6 lines
drivers/net/wireless/ipw2x00/ipw2200.c +2 -1
-	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.

Quoted 4 lines

Quoted 4 lines
drivers/net/wireless/ipw2x00/ipw2200.c +0 -0
@@ -6281,6 +6282,18 @@ static void ipw_add_scan_channels(struct ipw_priv *priv,
 	}
 }
 

Quoted 13 lines

drivers/net/wireless/ipw2x00/ipw2200.c static void ipw_add_scan_channels(struct ipw_priv *priv, · line 6295
Quoted 11 lines
drivers/net/wireless/ipw2x00/ipw2200.c +11 -0
+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.

Quoted 3 lines

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.

Quoted 2 lines

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.

Quoted 6 lines

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

Zhu Yi

2008-12-01 02:57 UTC #3 lore raw

Quoted 6 lines · Helmut Schaa

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.

Quoted 6 lines

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.

Quoted 7 lines

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.

[...]

Quoted 13 lines

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.
Quoted 3 lines
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.

Quoted 5 lines

Quoted 2 lines
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?

Quoted 9 lines

Quoted 6 lines
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

Helmut Schaa

author

2008-12-01 10:10 UTC #4 lore raw

Am Montag, 1. Dezember 2008 schrieb Zhu Yi:

Quoted 9 lines · Helmut Schaa

Quoted 6 lines
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.

Quoted 10 lines

Quoted 6 lines
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.

Quoted 10 lines

Quoted 7 lines
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.

Quoted 3 lines

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.

Quoted 1 line

Would you like to test some debug patches?

Sure, no problem.

Quoted 3 lines

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

Zhu Yi

2008-12-03 09:32 UTC #5 lore raw

Quoted 50 lines · Helmut Schaa

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

Quoted 8 lines

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

Zhu Yi

2008-12-10 05:51 UTC #6 lore raw

Quoted 54 lines · Zhu Yi

Quoted 53 lines · Helmut Schaa
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).

Quoted 7 lines

Quoted 5 lines
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

Helmut Schaa

author

2008-12-10 09:12 UTC #7 lore raw

Am Mittwoch, 10. Dezember 2008 schrieb Zhu Yi:

Quoted 59 lines · Zhu Yi

Quoted 58 lines · Helmut Schaa
Quoted 57 lines
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

Quoted 5 lines

Quoted 3 lines
Quoted 1 line
Status 2 -> Scan aborted.
We will look at this.
Sorry for the late reply.

No problem.

Quoted 7 lines

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.

Quoted 2 lines

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

Sure, will do.

Helmut