[PATCH 00/10] ANQP Refactor to use frame-xchg
by James Prestwood
I have included two of Andrews patches fixing the group zero bug
as well.
Andrew Zaborowski (2):
frame-xchg: Fix frame_watch_remove_by_handler for group 0
frame-xchg: Use frame_watch_group_match in frame_watch_group_get
James Prestwood (8):
frame-xchg: fix bug when starting new xchg from callback
anqp: refactor to use frame-xchg
station: add ANQP state watch API
network: delay connect if ANQP has not completed
hwsim: add new 'Delay' property to Rules
doc: document new 'Delay' property for hwsim Rules
auto-t: add 'Delay' property to hwsim python module
auto-t: add test for delayed ANQP response
autotests/testHotspot/anqp_delay_test.py | 83 +++++
autotests/util/hwsim.py | 8 +
doc/hwsim-rules-api.txt | 5 +
src/anqp.c | 449 +++++++----------------
src/anqp.h | 3 +-
src/frame-xchg.c | 62 ++--
src/network.c | 58 +++
src/station.c | 45 ++-
src/station.h | 13 +
tools/hwsim.c | 53 ++-
10 files changed, 414 insertions(+), 365 deletions(-)
create mode 100644 autotests/testHotspot/anqp_delay_test.py
--
2.21.1
2 years
[PATCH v3] scan: refactor start_next_scan_request to not send duplicate requests
by Alvin Šipraga
If start_scan_next_request() is called while a scan request
(NL80211_CMD_TRIGGER_SCAN) is still running, the same scan request will
be sent again. Add a check in the function to avoid sending a request if
one is already in progress. For consistency, check also that scan
results are not being requested (NL80211_CMD_GET_SCAN), before trying to
send the next scan request. Finally, remove similar checks at
start_next_scan_request() callsites to simplify the code.
This also fixes a crash that occurs if the following conditions are met:
- the duplicated request is the only request in the scan request
queue, and
- both scan requests fail with an error not EBUSY.
In this case, the first callback to scan_request_triggered() will delete
the request from the scan request queue. The second callback will find
an empty queue and consequently pass a NULL scan_request pointer to
scan_request_failed(), causing a segmentation fault.
---
src/scan.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/scan.c b/src/scan.c
index 8fc1f026..83804e57 100644
--- a/src/scan.c
+++ b/src/scan.c
@@ -842,6 +842,9 @@ static bool start_next_scan_request(struct scan_context *sc)
if (sc->state != SCAN_STATE_NOT_RUNNING)
return true;
+ if (sc->start_cmd_id || sc->get_scan_cmd_id)
+ return true;
+
while (sr) {
if (!scan_request_send_trigger(sc, sr))
return true;
@@ -1668,7 +1671,7 @@ static void scan_notify(struct l_genl_msg *msg, void *user_data)
/* An external scan may have flushed our results */
if (sc->started && scan_parse_flush_flag_from_msg(msg))
scan_finished(sc, -EAGAIN, NULL, sr);
- else if (sr && !sc->start_cmd_id)
+ else
send_next = true;
sr = NULL;
@@ -1719,7 +1722,7 @@ static void scan_notify(struct l_genl_msg *msg, void *user_data)
sc->triggered = false;
scan_finished(sc, -ECANCELED, NULL, sr);
- } else if (sr && !sc->start_cmd_id && !sc->get_scan_cmd_id) {
+ } else {
/*
* If this was an external scan that got aborted
* we may be able to now queue our own scan although
--
2.26.2
2 years
Race condition between iwd and systemd-udevd
by Daan De Meyer
Hi,
I've been having issues with systemd-udevd and iwd both trying to manage a
default wlan0 interface on boot which results in errors because iwd deletes
the default wlan0 interface while systemd-udevd is still busy with it.
Related systemd issue: https://github.com/systemd/systemd/issues/15691
Lennard Poettering suggests to wait with removing the wlan0 interface until
udev is done with it (which can be verified via the udev netlink interface).
I guess this would take some changes on iwd's side to check if udev is used
on the system and if so, wait until the relevant udev event before deleting
any default wlan0 interfaces. Would a patch implementing that be accepted?
Regards,
Daan De Meyer
2 years
Cannot get ap mode to work
by KeithG
I cannot get AP mode to function on my RPIs. If I try to do it by these
commands:
~# iwctl adapter phy0 show
Adapter: phy0
--------------------------------------------------------------------------------
Settable Property Value
--------------------------------------------------------------------------------
Name phy0
* Powered on
Vendor Broadcom Corp.
Model BCM43438 combo WLAN and Bluetooth Low Energy
(BLE)
SupportedModes ad-hoc station ap
~# iwctl device wlan0 show
Device: wlan0
--------------------------------------------------------------------------------
Settable Property Value
--------------------------------------------------------------------------------
Name wlan0
* Mode ap
* Powered on
Address b8:27:eb:52:cc:d0
Adapter phy0
~# iwctl ap wlan0 start "MyNet" "password"
On my Windows PC, I can select the SSID "MyNet" and attempt to connect but
every time, I get:
"Can't connect to this network"
From my android phone, I get a similar response: It tries to connect but
never negotiates a connection.
I have tried by running dnsmasq and then starting the iwd in AP mode (like
I do with hostapd), but still cannot connect.
Daniel on the connman list suggested I collect a log of the connection
attempt by running the commands suggested in the README:
https://git.kernel.org/pub/scm/network/wireless/iwd.git/tree/README
I tried before and got gibberish. I just did it again (by the book) and the
files are attached. This is on a RaspberryPi 3B+ running Arch Linux.
What is going wrong and how can I fix it? My goal is to ditch
hostapd/dnsmasq and use connman/iwd to allow the RPI to boot as an AP if it
does not have a 'known-network' that it can find.
Regards,
Keith
2 years
[PATCH] frame-xchg: fix bug when starting new xchg from callback
by James Prestwood
This bug is caused by the following behavior:
1. Start a frame-xchg, wait for callback
2. From callback start a new frame-xchg, same prefix.
The new frame-xchg request will detect that there is a duplicate watch,
which is correct behavior. It will then remove this duplicate from the
watchlist. The issue here is that we are in the watchlist notify loop
from the original xchg. This causes that loop to read from the now
freed watchlist item, causing an invalid read.
Instead of freeing the item immediately, check if the notify loop is in
progress and only set 'id' to zero and 'stale_items' to true. This will
allow the notify loop to finish, then the watchlist code will prune out
any stale items. If not in the notify loop the item can be freed as it
was before.
---
src/frame-xchg.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/src/frame-xchg.c b/src/frame-xchg.c
index 4c950fd3..71751ca4 100644
--- a/src/frame-xchg.c
+++ b/src/frame-xchg.c
@@ -532,7 +532,17 @@ static bool frame_watch_check_duplicate(void *data, void *user_data)
}
drop:
- /* Drop the existing watch as a duplicate of the new one */
+ /*
+ * Drop the existing watch as a duplicate of the new one. If we are in
+ * the watchlist notify loop, just mark this item as stale and it will
+ * be cleaned up afterwards
+ */
+ if (watch->group->watches.in_notify) {
+ super->id = 0;
+ watch->group->watches.stale_items = true;
+ return false;
+ }
+
frame_watch_free(&watch->super);
return true;
}
--
2.21.1
2 years
[PATCH 1/2] frame-xchg: Fix frame_watch_remove_by_handler for group 0
by Andrew Zaborowski
Don't match the default group's (group_id 0) wdev_id against the
provided wdev_id because the default group can be used on all wdevs and
its wdev_id is 0. Also match individual item's wdev_id in the group to
make up for this although it normally wouldn't matter.
---
src/frame-xchg.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/frame-xchg.c b/src/frame-xchg.c
index 4c950fd3..44711997 100644
--- a/src/frame-xchg.c
+++ b/src/frame-xchg.c
@@ -661,6 +661,7 @@ bool frame_watch_wdev_remove(uint64_t wdev_id)
}
struct frame_watch_handler_check_info {
+ uint64_t wdev_id;
frame_watch_cb_t handler;
void *user_data;
};
@@ -671,7 +672,8 @@ static bool frame_watch_item_remove_by_handler(void *data, void *user_data)
l_container_of(data, struct frame_watch, super);
struct frame_watch_handler_check_info *info = user_data;
- if (watch->super.notify != info->handler ||
+ if (watch->wdev_id != info->wdev_id ||
+ watch->super.notify != info->handler ||
watch->super.notify_data != info->user_data)
return false;
@@ -702,9 +704,9 @@ static bool frame_watch_remove_by_handler(uint64_t wdev_id, uint32_t group_id,
void *user_data)
{
struct watch_group_match_info group_info =
- { wdev_id, group_id };
+ { group_id == 0 ? 0 : wdev_id, group_id };
struct frame_watch_handler_check_info handler_info =
- { handler, user_data };
+ { wdev_id, handler, user_data };
struct watch_group *group = l_queue_find(watch_groups,
frame_watch_group_match,
&group_info);
--
2.25.1
2 years
connman integration
by KeithG
I currently use iwd with NetworkManager on a couple laptops running Arch
Linux. I also am working on an RPI project with connman/iwd managing
network interfaces. Currently, if we use the connman interface to scan with
iwd, we never get a return:
"connmanctl scan wifi" just hangs and requires a ctrlC.
This was noted on the Arch connman page:
https://wiki.archlinux.org/index.php/ConnMan#Error_/net/connman/technolog...
On my rpi project, we are using nginx/php to set it all up and we use the
'iwd station wlan0 scan' then 'connmanctl services' to select SSIDs. I
asked on the connman list and Daniel says that connman is waiting for a 0.
Scanning is supported with iwd. connmanctl scan is probably waiting for iwd
to respond with the scanning=0 signal. If iwd doesn't send out this signal
then this will hang.
Don't know if it is a connman or an iwd 'issue', but wanted to bring it up
here to see.
Keith
2 years, 1 month
Start iwd only after dbus
by dapolinario＠gmail.com
When iwd is not synchronized to start after dbus, NetworkManager often does not identify that the service is already running and does not manage the wireless interface.
I suggest adding the line "After=dbus.service" in "iwd.service" in the [Unit] section, so NetworkManager always identifies that iwd is working.
2 years, 1 month
[PATCH] scan: don't send the same scan request twice
by Alvin Šipraga
If start_scan_next_request() is called while a scan request
(NL80211_CMD_GET_SCAN) is still running, the same scan request will be
sent again by mistake. Add a check in the function to avoid sending a
request if one is already in progress.
This also fixes a crash that occurs if the following conditions are met:
- the duplicated request is the only request in the scan request
queue, and
- both scan requests fail with an error not EBUSY.
In this case, the first callback to scan_request_triggered() will delete
the request from the scan request queue. The second callback will find
an empty queue and consequently pass a NULL scan_request pointer to
scan_request_failed(), causing a segmentation fault.
---
src/scan.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/scan.c b/src/scan.c
index 718f7497..106fa81c 100644
--- a/src/scan.c
+++ b/src/scan.c
@@ -839,6 +839,9 @@ static bool start_next_scan_request(struct scan_context *sc)
if (sc->state != SCAN_STATE_NOT_RUNNING)
return true;
+ if (sc->start_cmd_id)
+ return true;
+
while (sr) {
if (!scan_request_send_trigger(sc, sr))
return true;
--
2.26.2
2 years, 1 month
