From: James Prestwood <prestwoj@gmail.com>
To: iwd@lists.linux.dev
Cc: James Prestwood <prestwoj@gmail.com>
Subject: [PATCH 10/21] offchannel: add support to issue multiple offchannel requests
Date: Thu, 12 Oct 2023 13:01:39 -0700 [thread overview]
Message-ID: <20231012200150.338401-11-prestwoj@gmail.com> (raw)
In-Reply-To: <20231012200150.338401-1-prestwoj@gmail.com>
There was nothing which prevented this, but due to the behavior of
some drivers multiple offchannel requests on the same channel
resulted in the second request never starting and eventually timing
out. This is because some drivers combine offchannel requests if
they are on the same channel and this ultimately results in the
netlink ACK coming after the ROC started event. This patch fixes
some logic to allow for this case.
The motivation to support this is so modules can start offchannel
work items for short durations and wait for a response, if a frame
is received the offchannel request can be canceled/restarted for
a longer duration.
This could also be done instead by using a long duration initially
and an extra timer to cancel, but its more convenient if offchannel
supports this natively. In addition, this driver quirk should be
supported regardless (e.g. if two IWD modules happen to issue ROC's
on the same channel).
Furthermore, the offchannel module was only looking up requests by
wdev_id which could result in the wrong request being found.
Instead the request should be looked up by both wdev_id and cookie
(when possible), or the ID in the case of canceling.
---
src/offchannel.c | 55 ++++++++++++++++++++++++++++++++++++++++++------
1 file changed, 48 insertions(+), 7 deletions(-)
diff --git a/src/offchannel.c b/src/offchannel.c
index b9cdc117..6a705092 100644
--- a/src/offchannel.c
+++ b/src/offchannel.c
@@ -54,15 +54,34 @@ struct offchannel_info {
bool needs_cancel : 1;
};
+struct match_data {
+ uint64_t wdev_id;
+ uint64_t cookie;
+};
+
static struct l_genl_family *nl80211;
static struct l_queue *offchannel_list;
-static bool match_wdev(const void *a, const void *user_data)
+static bool match_info(const void *a, const void *user_data)
+{
+ const struct match_data *match = user_data;
+ const struct offchannel_info *info = a;
+
+ if (match->wdev_id != info->wdev_id)
+ return false;
+
+ if (!match->cookie)
+ return true;
+
+ return match->cookie == info->roc_cookie;
+}
+
+static bool match_id(const void *a, const void *user_data)
{
+ const uint32_t *id = user_data;
const struct offchannel_info *info = a;
- const uint64_t *wdev_id = user_data;
- return info->wdev_id == *wdev_id;
+ return *id == info->work.id;
}
static void offchannel_cancel_roc(struct offchannel_info *info)
@@ -191,7 +210,8 @@ void offchannel_cancel(uint64_t wdev_id, uint32_t id)
else if (ret == false)
goto work_done;
- info = l_queue_find(offchannel_list, match_wdev, &wdev_id);
+
+ info = l_queue_find(offchannel_list, match_id, &id);
if (!info)
return;
@@ -246,6 +266,7 @@ work_done:
static void offchannel_mlme_notify(struct l_genl_msg *msg, void *user_data)
{
struct offchannel_info *info;
+ struct match_data match = {0};
uint64_t wdev_id;
uint64_t cookie;
uint8_t cmd;
@@ -261,12 +282,32 @@ static void offchannel_mlme_notify(struct l_genl_msg *msg, void *user_data)
NL80211_ATTR_UNSPEC) < 0)
return;
- info = l_queue_find(offchannel_list, match_wdev, &wdev_id);
+ match.wdev_id = wdev_id;
+ match.cookie = cookie;
+
+ info = l_queue_find(offchannel_list, match_info, &match);
+ if (!info) {
+ /* Try again without cookie */
+ match.cookie = 0;
+ info = l_queue_find(offchannel_list, match_info, &match);
+ }
+
if (!info)
return;
- /* ROC must have been started elsewhere, not by IWD */
- if (info->roc_cookie != cookie)
+ /*
+ * If the cookie is zero this could be from the ACK callback coming out
+ * of order which can happen when there is an ongoing offchannel request
+ * that is canceled (but no ROC_CANCEL event yet) and another is issued
+ * on the same frequency. Some drivers will combine these two requests
+ * and the ACK ends up coming after the ROC started event.
+ *
+ * If the cookie is set but does not match, this ROC request came from
+ * outside IWD.
+ */
+ if (!info->roc_cookie) {
+ info->roc_cookie = cookie;
+ } else if (info->roc_cookie != cookie)
return;
switch (cmd) {
--
2.25.1
next prev parent reply other threads:[~2023-10-12 20:02 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-12 20:01 [PATCH 00/21] DPP PKEX Changes James Prestwood
2023-10-12 20:01 ` [PATCH 01/21] crypto: remove label from prf_plus, instead use va_args James Prestwood
2023-10-17 15:18 ` Denis Kenzior
2023-10-12 20:01 ` [PATCH 02/21] dpp-util: fix typo "COMMIT_REVEAP_RESPONSE" James Prestwood
2023-10-17 15:19 ` Denis Kenzior
2023-10-12 20:01 ` [PATCH 03/21] dpp: rename auth_addr to peer_addr James Prestwood
2023-10-17 15:21 ` Denis Kenzior
2023-10-12 20:01 ` [PATCH 04/21] dpp: rename dpp_presence_timeout to be generic James Prestwood
2023-10-17 15:31 ` Denis Kenzior
2023-10-12 20:01 ` [PATCH 05/21] dpp: move/store max_roc setting into dpp_create James Prestwood
2023-10-17 15:32 ` Denis Kenzior
2023-10-12 20:01 ` [PATCH 06/21] dpp: fix retransmits if on operating channel James Prestwood
2023-10-17 15:36 ` Denis Kenzior
2023-10-12 20:01 ` [PATCH 07/21] dpp-util: allow for mutual authentication in i/r_auth James Prestwood
2023-10-19 14:34 ` Denis Kenzior
2023-10-12 20:01 ` [PATCH 08/21] dpp-util: allow mutual auth in dpp_derive_ke James Prestwood
2023-10-12 20:01 ` [PATCH 09/21] unit: update test-dpp with API changes James Prestwood
2023-10-12 20:01 ` James Prestwood [this message]
2023-10-19 14:51 ` [PATCH 10/21] offchannel: add support to issue multiple offchannel requests Denis Kenzior
2023-10-19 19:35 ` James Prestwood
2023-10-19 19:55 ` Denis Kenzior
2023-10-19 20:05 ` James Prestwood
2023-10-19 21:42 ` Denis Kenzior
2023-10-19 21:47 ` James Prestwood
2023-10-20 19:10 ` James Prestwood
2023-10-12 20:01 ` [PATCH 11/21] doc: PKEX support for DPP James Prestwood
2023-10-19 14:59 ` Denis Kenzior
2023-10-19 15:23 ` James Prestwood
2023-10-19 15:36 ` Denis Kenzior
2023-10-19 15:45 ` James Prestwood
2023-10-19 16:17 ` Denis Kenzior
2023-10-19 16:42 ` James Prestwood
2023-10-19 18:56 ` Denis Kenzior
2023-10-19 20:00 ` James Prestwood
2023-10-19 21:47 ` Denis Kenzior
2023-10-19 22:22 ` James Prestwood
2023-10-19 23:12 ` Denis Kenzior
2023-10-23 13:49 ` James Prestwood
2023-10-24 14:40 ` Denis Kenzior
2023-10-24 12:05 ` James Prestwood
2023-10-24 15:03 ` Denis Kenzior
2023-10-24 15:19 ` James Prestwood
2023-10-25 2:46 ` Denis Kenzior
2023-10-12 20:01 ` [PATCH 12/21] dpp-util: add crypto for PKEX James Prestwood
2023-10-19 15:13 ` Denis Kenzior
2023-10-19 15:27 ` James Prestwood
2023-10-12 20:01 ` [PATCH 13/21] dpp-util: add __DPP_STATUS_MAX James Prestwood
2023-10-19 15:16 ` Denis Kenzior
2023-10-23 12:35 ` James Prestwood
2023-10-12 20:01 ` [PATCH 14/21] dpp: support mutual authentication James Prestwood
2023-10-12 20:01 ` [PATCH 15/21] dpp: allow enrollee to be authentication initiator James Prestwood
2023-10-12 20:01 ` [PATCH 16/21] dbus: add SharedCodeDeviceProvisioning interface definition James Prestwood
2023-10-12 20:01 ` [PATCH 17/21] dpp: initial version of PKEX enrollee support James Prestwood
2023-10-12 20:01 ` [PATCH 18/21] dpp: initial version of PKEX configurator support James Prestwood
2023-10-12 20:01 ` [PATCH 19/21] auto-t: add utils for wpa_supplicant PKEX James Prestwood
2023-10-12 20:01 ` [PATCH 20/21] auto-t: add APIs for PKEX James Prestwood
2023-10-12 20:01 ` [PATCH 21/21] auto-t: add DPP PKEX tests James Prestwood
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20231012200150.338401-11-prestwoj@gmail.com \
--to=prestwoj@gmail.com \
--cc=iwd@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox