If an SSID is configured iwn(4) instructs the firmware to do an active scan.
An active scan sends probe requests which contain the configured SSID.
The idea is that APs will send probe responses immediately and the
client won't have to wait for a full beacon interval on each channel
in order to find an AP with an SSID it wants to connect to.
(At present, we don't actually make use of this optimization and always
run a full scan anyway.)
The firmware sends probe requests based on a template provided by the driver.
The decision whether to send the probe request is made inside the firmware.
An apparent problem is how this interacts with the way iwn(4) firmware
implements regulatory domain restrictions. On some channels the firmware
waits until it sees a (any) beacon before sending any frames. This makes
active scanning somewhat pointless as an optimization.
The exact interactions are unclear. I don't know how the firmware handles
this internally. What I do know from studying visible behaviour is:
- the firmware often fails to actually send a probe request to my 5 GHz AP
- scan results often omit other known APs on 5 GHz channels
When this happens net80211 does not receive a beacon or probe response
and the 5GHz AP does not show up in the candidate list.
With passive scanning the AP does not always show up either, but it
shows up a lot more often than not. Using passive scanning on 5 GHz
seems to be a lot more reliable.
I suspect that iwn_limit_dwell() is responsible for the remaining
5Ghz scan failures because it limits the channel dwell time to less
than a full beacon interval. This means the firmware may not dwell
on a channel long enough to passively receive a beacon.
However, simply removing a call to this function results in some scans
never completing, so I stopped there. Fixing the remaining failures
requires additional investigation.
As a first step, I would like to disable active scans with iwn(4)
on the 5 GHz band, i.e. always scan this band in passive mode.
We have always been using passive scans if no SSID is configured
so it seems unlikely that this could break anything.
ok?
Index: if_iwn.c
===================================================================
RCS file: /cvs/src/sys/dev/pci/if_iwn.c,v
retrieving revision 1.192
diff -u -p -r1.192 if_iwn.c
--- if_iwn.c 4 Sep 2017 09:12:35 -0000 1.192
+++ if_iwn.c 5 Sep 2017 13:22:10 -0000
@@ -4749,9 +4749,13 @@ iwn_scan(struct iwn_softc *sc, uint16_t
/*
* If we're scanning for a specific SSID, add it to the command.
+ *
+ * We do not use active scanning on 5GHz because it is too unreliable.
+ * It seems the firmware's radar detection often gets in the way of
+ * sending probe requests on channels which are passive by default.
*/
essid = (struct iwn_scan_essid *)(tx + 1);
- if (ic->ic_des_esslen != 0) {
+ if (ic->ic_des_esslen != 0 && (flags & IEEE80211_CHAN_2GHZ)) {
essid[0].id = IEEE80211_ELEMID_SSID;
essid[0].len = ic->ic_des_esslen;
memcpy(essid[0].data, ic->ic_des_essid, ic->ic_des_esslen);
