summaryrefslogtreecommitdiffstats
path: root/sys/dev/usb/xhci.c
diff options
context:
space:
mode:
authorstsp <stsp@openbsd.org>2017-09-04 09:11:46 +0000
committerstsp <stsp@openbsd.org>2017-09-04 09:11:46 +0000
commit69759a962359ea62d91f1cc135fbc6f38b826d4d (patch)
tree1348f8055f74adf5173dc258f4b55ec7d62046fe /sys/dev/usb/xhci.c
parenttweak previous; (diff)
downloadwireguard-openbsd-69759a962359ea62d91f1cc135fbc6f38b826d4d.tar.xz
wireguard-openbsd-69759a962359ea62d91f1cc135fbc6f38b826d4d.zip
If a beacon is received in RUN state, reset the management timer.
Some wifi drivers send a probe request if the hardware reports "missed beacon" events. If the AP replies with a probe response it is still servicing us and there is no need to search for a new AP. However, the management timer was not reset if a beacon was received while in RUN state. So the interface watchdog always ended up putting the driver into SCAN state after a missed beacon event, even if the AP did respond to our probe request. Under some conditions this bug would cause spurious disconnects. Problem reported and fix tested by mlarkin@ (Using the management timer in RUN state is a new convention. Before support for missed beacons was added, this timer was only used during the association sequence to handle APs which don't respond to our assoc requests and such.)
Diffstat (limited to 'sys/dev/usb/xhci.c')
0 files changed, 0 insertions, 0 deletions