Before requesting a scan, check the time threshold

Authored by meven on Aug 30 2019, 12:07 PM.



Currently we don't follow the documented way to check requestScan results and if it has succeeded.
This ends up generating, retries and warning such as :

plasma-nm: Wireless scan on "wlp2s0" failed: "Scanning not allowed immediately following previous scan"

This patch checks if the device has not finished a scan within the last 10 seconds and that the last scan finished before allowing more scans to be requested.

RequestScan Doc :
10 seconds request scan threshold in NetworkManager :

Depends on D23576

Diff Detail

R116 Plasma Network Management Applet
No Linters Available
No Unit Test Coverage
Build Status
Buildable 15845
Build 15863: arc lint + arc unit
meven created this revision.Aug 30 2019, 12:07 PM
Restricted Application added a project: Plasma. · View Herald TranscriptAug 30 2019, 12:07 PM
Restricted Application added a reviewer: jgrulich. · View Herald Transcript
Restricted Application added a subscriber: plasma-devel. · View Herald Transcript
meven requested review of this revision.Aug 30 2019, 12:07 PM
meven edited the summary of this revision. (Show Details)Aug 30 2019, 12:08 PM
meven updated this revision to Diff 64985.Aug 30 2019, 12:08 PM

remove a space

meven updated this revision to Diff 65003.Aug 30 2019, 2:46 PM

Account for method name change in networkmanager-qt

jgrulich accepted this revision.Sep 10 2019, 8:37 AM
This revision is now accepted and ready to land.Sep 10 2019, 8:37 AM
meven updated this revision to Diff 66015.Sep 13 2019, 11:26 PM

Improve code and make it cleaner

meven updated this revision to Diff 66060.Sep 14 2019, 3:09 PM

Add a timer per interface allowing to scan devices as soon as technically possible, rescheduling wifi scan for when it will be possible

meven added a comment.Sep 14 2019, 3:15 PM

@jgrulich if you could have a second look, I improved this because my previous code could have prevented requestScan to be fired.

jgrulich added inline comments.Sep 17 2019, 7:43 AM
77 ↗(On Diff #66060)

I wonder whether the timer in the applet itself should be running if we fail to scan, I think it should be stopped when we fail and resumed again when a successful scan was done. If I do get it correctly and we fail to do a scan, we schedule a new one in e.g. 5 seconds, after 5 seconds we perform a successful one, but after another 5 seconds this timer will perform a new one and fail again. Stopping this timer when we fail to scan and resuming it later will result into higher ration of successful scans, am I right?


This timer never gets deleted.

meven added inline comments.Sep 17 2019, 9:27 AM

timer will be one of the value of hash m_wirelessScanRetryTimer, which are cleaned line 516.
I could be missing a delete there though such as delete m_wirelessScanRetryTimer.remove(interface)

jgrulich added inline comments.Sep 18 2019, 7:35 AM
77 ↗(On Diff #66060)

What about this?


You remove it just from the map, but it doesn't get deleted, you would need to do something like

delete m_wirelessScanRetryTime.take(interface);
meven updated this revision to Diff 67595.Oct 10 2019, 10:29 AM
meven marked 5 inline comments as done.

Rebase, clean wirelessScanTimerEnabled, better use delete m_wirelessScanRetryTimer.take to clean m_wirelessScanRetryTimer hashmap, add some comments

meven added inline comments.Oct 10 2019, 10:29 AM
77 ↗(On Diff #66060)

I removed this because

Request scan failure should never happen anymore because the handler makes sure never to call requestScan too often.
The timer can just constantly ask for request scans it does not impact the "real" requestScan sent.

Now the scans are per interface, meaning we check the interface states by interface and they could have different state.
It does not match well with this timer : if an interface fails, should we stop to scan the others ? I believe not.
A solution would be to have timer by interface, but we already have this in the handler anyway so it seems overkill to do it here.

meven added inline comments.Oct 16 2019, 1:02 PM
77 ↗(On Diff #66060)

@jgrulich Any feedback ?
You approved this a while back but we still have this point to deal with.

jgrulich accepted this revision.Oct 17 2019, 10:14 AM

Alright, I believe you are correct.

meven updated this revision to Diff 68120.Oct 17 2019, 10:52 AM


This revision was automatically updated to reflect the committed changes.