- The scan task refactoring stuff circa 2014-2016 broke the blocking task into a taskqueue with some async bits, but it apparently broke scans being interrupted by traffic.
Notably - the new "field" SCAN_PAUSE sets both SCAN_INTERRUPT and SCAN_CANCEL, and a bunch of existing code was checking for SCAN_CANCEL only and breaking the scan. Unfortunately it was then (a) cancelling the scan entirely and (b) not notifying userland that scan was done.
So:- Update the calls to scan_end() to only pass in 1 (saying the scan is complete) if SCAN_CANCEL is set WITHOUT SCAN_INTERRUPT. If both are set then yes, the scan is interrupted, but it isn't canceled - it's just paused.
- Update the "did the scan flags change whilst the driver was called" logic to check for canceled scans, not interrupted scans.
- the "scan done" logic now explicitly checks for either interrupted or completed scans. This accounts for the situation where a scan is being aborted via traffic but it ALSO happens to have finished (ie the last channel was checked.)
This doesn't ENTIRELY fix scanning as the resume function is broken
due to incorrect ticks math. Thus, the second half of this patch
changes the ieee80211_ticks_*() macros to use int instead of long,
matching the logic that the TCP code does with ticks and handles
wrapping / negative ticks values. If cast to long then the wrapping
math wouldn't work right (ie, if ticks was actually negative,
ie, after the system has been up for a while.)
This allows contbgscan() to correctly calculate if a scan should
continue based on ticks and ic_lastdata .