I hope it's not too inappropriate to ask a support question here. I've tried at my distro's forum to no avail.
Please, how do I make "sudo iwlist <iface> scanning" display only results from current scan? Cached prior scan results (including no-longer-available hotspots) often show up in the output, which breaks one of my shell scripts.
If iwlist does not include an option to ignore old scan results, a workaround would be to first flush the results of old scan, then scan. The problem is that I can't figure out where prior scan results stored. Surely one of you guys would know? The only way I've found to flush old scan results is to unload then reload the wireless interface's kernel module, but this approach seems heavy-handed when a simple "cat /dev/null > somefile" might be sufficient if I knew where old scan results are kept.
Thanks a million for any insights.
-Bruno
P.S. Here are some possibly relevant details about my system:
- OS: Tiny Core Linux 11 64-bit
- linux kernel version: 5.4.3
- wireless card: Atheros AR928X
- wireless driver: ath9k
- iwlist version: 29
On Thu, 2020-05-28 at 11:48 -0400, Bruno Dantas wrote:
> I hope it's not too inappropriate to ask a support question here. I've
> tried at my distro's forum to no avail.
>
> Please, how do I make "sudo iwlist <iface> scanning" display only
> results from current scan? Cached prior scan results (including no-
> longer-available hotspots) often show up in the output, which breaks
> one of my shell scripts.
You cannot.
You should use 'iw' instead of 'iwlist', which does have options for
flushing the cache.
johannes
> You should use 'iw' instead of 'iwlist', which does have options for
> flushing the cache.
Thank you, Johannes.
I tried iw but it has the same issue (the "AndroidAP-bd" SSID is non-existent because my phone is physically turned off, but it shows up in the output):
$ sudo iw dev wlan0 scan flush
...
TSF: 42037885 usec (0d, 00:00:42)
freq: 2412
beacon interval: 100 TUs
capability: ESS Privacy ShortSlotTime (0x0411)
signal: -31.00 dBm
last seen: 11447 ms ago
Information elements from Probe Response frame:
SSID: AndroidAP-bd
Supported rates: 1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0
DS Parameter set: channel 1
ERP: <no flags>
Extended supported rates: 6.0 9.0 12.0 48.0
RSN: * Version: 1
...
Am I not issuing the appropriate iw command?
On Thu, 2020-05-28 at 12:48 -0400, Bruno Dantas wrote:
> > You should use 'iw' instead of 'iwlist', which does have options for
> > flushing the cache.
>
> Thank you, Johannes.
>
> I tried iw but it has the same issue (the "AndroidAP-bd" SSID is
> non-existent because my phone is physically turned off,
Well, that _should_ work.
> but it shows up in the output):
>
> $ sudo iw dev wlan0 scan flush
> ...
> TSF: 42037885 usec (0d, 00:00:42)
> freq: 2412
> beacon interval: 100 TUs
> capability: ESS Privacy ShortSlotTime (0x0411)
> signal: -31.00 dBm
> last seen: 11447 ms ago
Does it go away if you wait long enough for the "last seen" to go above
30 seconds (30000ms)? You should use "iw wlan0 scan dump" (no need for
sudo, and don't scan again) to check.
Because if not, then there's a bug in the references, and the entry is
just being kept alive by ... something. Did you previously connect to
it? Does it also happen if you never connect? Then I guess we'll need to
know what the kernel version is too. :)
johannes
> Does it go away if you wait long enough for the "last seen" to go above
> 30 seconds (30000ms)? You should use "iw wlan0 scan dump" (no need for
> sudo, and don't scan again) to check.
>
> Because if not, then there's a bug in the references, and the entry is
> just being kept alive by ... something. Did you previously connect to
> it? Does it also happen if you never connect? Then I guess we'll need to
> know what the kernel version is too. :)
Yes, it goes way if I wait 30 seconds. Whether I had connected to the hotspot or not makes no difference. Kernel version is 5.4.3.
I thought discovering *currently-available* hotspots would be a common need. I'm a bit surprised that getting this information is tricky.
Like I said, reloading the wireless interface's kernel module does the trick. I was just hoping that there'd be a more elegant solution. Thanks for the help, anyway.
On Thu, 2020-05-28 at 14:57 -0400, Bruno Dantas wrote:
> > Does it go away if you wait long enough for the "last seen" to go above
> > 30 seconds (30000ms)? You should use "iw wlan0 scan dump" (no need for
> > sudo, and don't scan again) to check.
> >
> > Because if not, then there's a bug in the references, and the entry is
> > just being kept alive by ... something. Did you previously connect to
> > it? Does it also happen if you never connect? Then I guess we'll need to
> > know what the kernel version is too. :)
>
> Yes, it goes way if I wait 30 seconds. Whether I had connected to the
> hotspot or not makes no difference. Kernel version is 5.4.3.
So at least it's not completely stuck.
> I thought discovering *currently-available* hotspots would be a common
> need. I'm a bit surprised that getting this information is tricky.
That's why 'flush' exists :)
> Like I said, reloading the wireless interface's kernel module does the
> trick.
Obviously. But still, now I'm wondering if there's a bug?
But then again, I think we use this a lot in the hwsim tests and rely on
it for a quick succession of tests to not find previous APs, and
"scan_for_auth" seems to be a fairly direct test for this as well?
Hmm. Not sure. What driver are you using?
johannes
> That's why 'flush' exists :)
Alas, mine seems to be clogged :)
> Obviously. But still, now I'm wondering if there's a bug?
> What driver are you using?
My adapter is Atheros AR928X which uses the ath9k driver.
-Bruno
On Thu, 2020-05-28 at 15:06 -0400, Bruno Dantas wrote:
> > That's why 'flush' exists :)
> Alas, mine seems to be clogged :)
Evidently :)
> > Obviously. But still, now I'm wondering if there's a bug?
> > What driver are you using?
> My adapter is Atheros AR928X which uses the ath9k driver.
Hm. That should be fine.
Well, I don't know. It's weird because the timeout and flush are
basically exactly the same thing!
If you want to debug it, I guess you could start with something like
this:
diff --git a/net/wireless/scan.c b/net/wireless/scan.c
index 74ea4cfb39fb..6fe609f6cd0e 100644
--- a/net/wireless/scan.c
+++ b/net/wireless/scan.c
@@ -483,6 +483,7 @@ void ___cfg80211_scan_done(struct cfg80211_registered_device *rdev,
if (!request->info.aborted &&
request->flags & NL80211_SCAN_FLAG_FLUSH) {
/* flush entries from previous scans */
+ printk(KERN_DEBUG "flushing at %ld, start was %ld\n", jiffies, request->scan_start);
spin_lock_bh(&rdev->bss_lock);
__cfg80211_bss_expire(rdev, request->scan_start);
spin_unlock_bh(&rdev->bss_lock);
Unless maybe it got into the aborted case?
Maybe before you even do this, run "iw event -t" while doing the scan
with flush.
johannes