On Sat, Feb 24, 2018 at 08:54:47PM -0500, trondd wrote: > On Sat, February 24, 2018 4:05 pm, Stefan Sperling wrote: > > On Sat, Feb 24, 2018 at 03:21:14PM -0500, trondd wrote: > >> Went back to HEAD and reporduced the problem immediatly. Applied the > >> patch and > >> that seems to fix it. Running the patch without IWM_DEBUG for now to > >> verify > >> stability. > > > >> Feb 24 14:42:07 portabsd /bsd: iwm0: 0000001C | hcmd > > > > This "host command" code is the command used to transmit a frame: > > > > #define IWM_TX_CMD 0x1c > > > > So it seems the firmware is crashing during an attempt to send a frame > > while a background scan is in progress. > > It's unclear why this is happening. It could be a firmware bug, or it > > could be misuse of the firmware's API by the driver. > > > > Your observation that my diff fixes it means that setting the SSID of a > > an AP in the background scan command is somehow related to this crash. > > > > One possibility is that a firmware upgrade could fix this. > > But in any case, setting the SSID during a background scan is not > > necessary. > > So if my diff works, we can just commit it and stop worrying about the > > firwmare's problems. > > > > It's been running without any problems all day. Thanks Stefan. > > Tim.
There is one small downside to this change: Roaming between APs with a hidden SSID becomes impossible. However, I have verified that connecting to one such AP still works, and more importantly that we keep choosing this same AP after a background scan (i.e. we stay connected, rather than losing the AP). This is because a background scan keeps the AP in the 802.11 node cache, whereas a foreground scan would first delete this cache, and because the background scan will never find a better candidate AP with a matching SSID since the hidden essid appears in beacons with zero length. This means single-AP hidden SSID setups continue to operate fine, but without seamless roaming (of course we will still try to find a new AP when we lose link). I would hope that, in general, setups which encourage roaming do not hide their SSID. I have not seen hidden SSIDs being used at conferences or at multi-AP office networks. Hiding the SSID seems to be more common in single-AP home user setups (settting aside the fact that it provides no additional security which questions the usefulness of this feature in the first place, etc.) So I think this trade-off is acceptable.