Before requesting a scan, check the time threshold
AcceptedPublic

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

Details

Reviewers
jgrulich
Group Reviewers
Plasma
Summary

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 :
https://developer.gnome.org/NetworkManager/stable/gdbus-org.freedesktop.NetworkManager.Device.Wireless.html#gdbus-method-org-freedesktop-NetworkManager-Device-Wireless.RequestScan
10 seconds request scan threshold in NetworkManager :
https://github.com/NetworkManager/NetworkManager/blob/master/src/devices/wifi/nm-device-wifi.c#L1204

Depends on D23576

Diff Detail

Repository
R116 Plasma Network Management Applet
Branch
arcpatch-D23578
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 17504
Build 17522: 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.Tue, Sep 17, 7:43 AM
applet/contents/ui/main.qml
77

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?

libs/handler.cpp
553

This timer never gets deleted.

meven added inline comments.Tue, Sep 17, 9:27 AM
libs/handler.cpp
553

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.Wed, Sep 18, 7:35 AM
applet/contents/ui/main.qml
77

What about this?

libs/handler.cpp
553

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.Thu, Oct 10, 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.Thu, Oct 10, 10:29 AM
applet/contents/ui/main.qml
77

I removed this because

1:
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.

2:
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.