iwi: Possibly wrong interpretation of beacon->number in if_iwi.c?

[Andre Albsmeier]

I am currently using iwi in a rather difficult WLAN
environment (multiple APs on the same channel and weak
signals).

While trying to find out why iwi0 reassociates every 10 to
60 seconds I used sysctl debug.iwi=5 and logged (among
others) these messages:

...
Beacon state (1, 18941446)
Beacon miss: 18941446 >= 254
Beacon state (1, 18941703)
Beacon miss: 18941703 >= 254
Beacon state (1, 18941446)
...

Trying to understand what this means, I found the corresponding
code in /sys/dev/iwi/if_iwi.c:

  if (le32toh(beacon->number) >= ic->ic_bmissthreshold) {
          DPRINTF(("Beacon miss: %u >= %u\n",
              le32toh(beacon->number),
              ic->ic_bmissthreshold));
          ieee80211_beacon_miss(ic);
  }

le32toh(beacon->number) seems to be the number of missed
beacons. However, I have no idea how it can be that high
after an uptime of only a few minutes.

Could it be that only the LSB of this value is meaningful?

I added some debug code to if_iwi.c:

iwi0: Beacon miss: 19006982 1220606
iwi0: Beacon miss: 19006982 1220606
iwi0: Beacon miss: 19007239 1220707
iwi0: Beacon miss: 19007496 1220808
iwi0: Beacon miss: 19269126 1260606
iwi0: Beacon miss: 19269383 1260707
iwi0: Beacon miss: 19269640 1260808
iwi0: Beacon miss: 19269126 1260606
iwi0: Beacon miss: 19269383 1260707
iwi0: Beacon miss: 19269640 1260808
iwi0: Beacon miss: 19269897 1260909
iwi0: Beacon miss: 19270154 1260a0a
iwi0: Beacon miss: 19270411 1260b0b
iwi0: Beacon miss: 19269126 1260606
iwi0: Beacon miss: 19006982 1220606
iwi0: Beacon miss: 19006982 1220606
iwi0: Beacon miss: 19007239 1220707
iwi0: Beacon miss: 19006982 1220606
iwi0: Beacon miss: 19007239 1220707
iwi0: Beacon miss: 19007496 1220808
iwi0: Beacon miss: 19007753 1220909
iwi0: Beacon miss: 19008010 1220a0a
iwi0: Beacon miss: 19006982 1220606
iwi0: Beacon miss: 19007239 1220707
iwi0: Beacon miss: 19007496 1220808
iwi0: Beacon miss: 19007753 1220909

The second value is le32toh(beacon->number) converted to
hex and we see that the two least significant bytes are
always the same. This, and the fact that bmissthreshold
must be in the range 1 to 255, makes me assume that we
possibly should ignore the upper 24 bits.

I am now using this patch to if_iwi.c:

--- if_iwi.c.ORI	2009-12-07 16:17:46.000000000 +0100
+++ if_iwi.c	2009-12-07 16:20:10.000000000 +0100
@@ -1497,7 +1497,7 @@
 		/* XXX check struct length */
 		beacon = (struct iwi_notif_beacon_state *)(notif + 1);
 
-		DPRINTFN(5, ("Beacon state (%u, %u)\n",
+		DPRINTFN(5, ("Beacon state (%u, 0x%x)\n",
 		    beacon->state, le32toh(beacon->number)));
 
 		if (beacon->state == IWI_BEACON_MISS) {
@@ -1508,9 +1508,9 @@
 			 * 802.11 layer.
 			 * XXX try to roam, drop assoc only on much higher count
 			 */
-			if (le32toh(beacon->number) >= ic->ic_bmissthreshold) {
+			if ((le32toh(beacon->number) & 0xFF) >= ic->ic_bmissthreshold) {
 				DPRINTF(("Beacon miss: %u >= %u\n",
-				    le32toh(beacon->number),
+				    le32toh(beacon->number) & 0xFF,
 				    ic->ic_bmissthreshold));
 				ieee80211_beacon_miss(ic);
 			}

and things got a lot better. After rising bmissthreshold to
50, which would be perfectly acceptable here, I got no more
problems.

All this is on a fresh 7.2-STABLE, however, I have upgraded
the fw in /sys/contrib/dev/iwi from V3.0 to V3.1 manually
(this has no effect on the problem mentioned above).

What do people think?

Thanks,

	-Andre