11:06 a.m.
An earlier patch fixed a problem where a queued quick scan would
be triggered and fail once already connected, resulting in a state
transition from connected --> autoconnect_full. This fixed the
Connect() path but this could also happen via autoconnect. Starting
from a connected state, the sequence goes:
- DBus scan is triggered
- AP disconnects IWD
- State transition from disconnected --> autoconnect_quick
- Queue quick scan
- DBus scan results come in and used to autoconnect
- A connect work item is inserted ahead of all others, transition
from autoconnect_quick --> connecting.
- Connect completes, transition from connecting --> connected
- Quick scan can finally get triggered, which the kernel fails to
do since IWD is connected, transition from connected -->
autoconnect_full.
This can be fixed by checking for a pending quick scan in the
autoconnect path.
---
src/station.c | 7 +++++++
1 file changed, 7 insertions(+)
v3:
* Moved check into the autoconnect path rather than
__station_connect_network
diff --git a/src/station.c b/src/station.c
index 8288916f..2a7025ef 100644
--- a/src/station.c
+++ b/src/station.c
@@ -196,6 +196,13 @@ static void station_autoconnect_next(struct station *station)
if (!r) {
station_enter_state(station, STATION_STATE_CONNECTING);
+
+ if (station->quick_scan_id) {
+ scan_cancel(netdev_get_wdev_id(station->netdev),
+ station->quick_scan_id);
+ station->quick_scan_id = 0;
+ }
+
return;
}
}
--
2.26.2
11:06 a.m.
New subject: [PATCH v3 2/2] auto-t: fix wait_for_object_condition to work with any object
After recent changes fixing wait_for_object_condition it was accidentally
made to only work with classes, not other types of objects. Instead
create a minimal class to hold _wait_timed_out so it doesnt rely on
'obj' holding the boolean.
---
autotests/util/iwd.py | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/autotests/util/iwd.py b/autotests/util/iwd.py
index 4fa26517..6b153ea7 100755
--- a/autotests/util/iwd.py
+++ b/autotests/util/iwd.py
@@ -1009,23 +1009,26 @@ class IWD(AsyncOpAbstract):
@staticmethod
def _wait_for_object_condition(obj, condition_str, max_wait = 50):
- obj._wait_timed_out = False
+ class TimeoutData:
+ _wait_timed_out = False
- def wait_timeout_cb():
- obj._wait_timed_out = True
+ data = TimeoutData()
+
+ def wait_timeout_cb(data):
+ data._wait_timed_out = True
return False
try:
- timeout = GLib.timeout_add_seconds(max_wait, wait_timeout_cb)
+ timeout = GLib.timeout_add_seconds(max_wait, wait_timeout_cb, data)
context = ctx.mainloop.get_context()
while not eval(condition_str):
context.iteration(may_block=True)
- if obj._wait_timed_out and ctx.args.gdb == None:
+ if data._wait_timed_out and ctx.args.gdb == None:
raise TimeoutError('[' + condition_str + ']'\
' condition was not met in '\
+ str(max_wait) + ' sec')
finally:
- if not obj._wait_timed_out:
+ if not data._wait_timed_out:
GLib.source_remove(timeout)
def wait_for_object_condition(self, *args, **kwargs):
--
2.26.2
1:57 p.m.
New subject: [PATCH v3 1/2] station: move scan cancelation to
__station_connect_network
Hi James,
On 2/4/21 6:06 PM, James Prestwood wrote:
An earlier patch fixed a problem where a queued quick scan would
be triggered and fail once already connected, resulting in a state
transition from connected --> autoconnect_full. This fixed the
Connect() path but this could also happen via autoconnect. Starting
from a connected state, the sequence goes:
- DBus scan is triggered
- AP disconnects IWD
- State transition from disconnected --> autoconnect_quick
- Queue quick scan
- DBus scan results come in and used to autoconnect
- A connect work item is inserted ahead of all others, transition
from autoconnect_quick --> connecting.
- Connect completes, transition from connecting --> connected
- Quick scan can finally get triggered, which the kernel fails to
do since IWD is connected, transition from connected -->
autoconnect_full.
This can be fixed by checking for a pending quick scan in the
autoconnect path.
---
src/station.c | 7 +++++++
1 file changed, 7 insertions(+)
Both applied, thanks.
Regards,
-Denis
590
days inactive
590
days old
2 comments
2 participants
participants (2)
-
Denis Kenzior -
James Prestwood