From: James Prestwood <prestwoj@gmail.com>
To: iwd@lists.linux.dev
Cc: James Prestwood <prestwoj@gmail.com>
Subject: [PATCH v2 2/4] netdev: disconnect rather than deauth in FT association failure
Date: Mon, 18 Aug 2025 07:30:39 -0700 [thread overview]
Message-ID: <20250818143041.283887-2-prestwoj@gmail.com> (raw)
In-Reply-To: <20250818143041.283887-1-prestwoj@gmail.com>
After CSA IE parsing was added to the kernel this opened up the
possibility that associations could be rejected locally based on
the contents of this CSA IE in the AP's beacons. Overall, it was
always possible for a local rejection but this case was never
considered by IWD. The CSA-based rejection is something that can
and does happen out in the wild.
When this association rejection happens it desync's IWD and the
kernel's state:
1. IWD begins an FT roam. Authenticates successfully, then proceeds
to calling netdev_ft_reassociate().
2. Immediately IWD transitions to a ft-roaming state and waits for
an association response.
3. CMD_ASSOCIATE is rejected by the kernel in the ACK which IWD
handles by sending a deauthenticate command to the kernel (since
we have a valid authentication to the new BSS).
4. Due to a bug IWD uses the target BSSID to deauthenticate which
the kernel rejects since it has no knowledge of this auth. This
error is not handled or logged.
5. IWD proceeds, assuming its deauthenticated, and transitions to a
disconnected state. The kernel remains "connected" which of course
prevents any future connections.
A simple fix for this is to address the bug (4) in IWD that deauths
using the current BSS roam target. This is actually legacy behavior
from back when IWD used CMD_AUTHENTICATE. Today the kernel is unaware
that IWD authenticated so a deauth is not going to be effective.
Instead we can issue a CMD_DISCONNECT. This is somewhat of a large
hammer, but since the handshake and internal state has already been
modified to use the new target BSS we cannot go back and maintain the
existing connect (though it is _possible_, see the TODO in the
patch).
---
src/netdev.c | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/src/netdev.c b/src/netdev.c
index ca8bfea0..d896c907 100644
--- a/src/netdev.c
+++ b/src/netdev.c
@@ -2993,13 +2993,26 @@ static void netdev_cmd_ft_reassociate_cb(struct l_genl_msg *msg,
void *user_data)
{
struct netdev *netdev = user_data;
+ int err = l_genl_msg_get_error(msg);
netdev->connect_cmd_id = 0;
- if (l_genl_msg_get_error(msg) >= 0)
+ l_debug("%d", err);
+
+ if (err >= 0)
return;
- netdev_deauth_and_fail_connection(netdev,
+ /*
+ * TODO: It is possible to not trigger a disconnect here and maintain
+ * the current connection. The issue is that IWD has already
+ * modified the handshake and we've lost all reference to the old
+ * BSS keys.
+ *
+ * This could be remedied in the future by creating an entirely
+ * new handshake_state object for the association and only when
+ * the ack indicates success do we clear out the old object.
+ */
+ netdev_disconnect_and_fail_connection(netdev,
NETDEV_RESULT_ASSOCIATION_FAILED,
MMPDU_STATUS_CODE_UNSPECIFIED);
}
--
2.34.1
next prev parent reply other threads:[~2025-08-18 14:30 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-18 14:30 [PATCH v2 1/4] netdev: check connected in channel switch event James Prestwood
2025-08-18 14:30 ` James Prestwood [this message]
2025-08-18 14:30 ` [PATCH v2 3/4] auto-t: make waiting for channel switch configurable James Prestwood
2025-08-18 14:30 ` [PATCH v2 4/4] auto-t: add test for channel switch during roam James Prestwood
2025-08-20 16:20 ` [PATCH v2 1/4] netdev: check connected in channel switch event Denis Kenzior
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=20250818143041.283887-2-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