2020-04-14 13:22:25

by James Prestwood

[permalink] [raw]
Subject: [PATCH] nl80211: fix PORT_AUTHORIZED wording to reflect behavior

The CMD_PORT_AUTHORIZED event was described as an event which indicated
a successfully completed 4-way handshake. But the behavior was
not as advertized. The only driver which uses this is brcmfmac, and
this driver only sends the event after a successful 8021x-FT roam.

This prevents userspace applications from knowing if the 4-way completed
on:

1. Normal 8021x connects
2. Normal PSK connections
3. FT-PSK roams

wpa_supplicant handles this incorrect behavior by just completing
the connection after association, before the 4-way has completed.
If the 4-way ends up failing it disconnects at that point.

Since this behavior appears to be expected (wpa_s handles it this
way) I have changed the wording in the API description to reflect the
actual behavior.

Signed-off-by: James Prestwood <[email protected]>
---
include/uapi/linux/nl80211.h | 20 +++++++-------------
1 file changed, 7 insertions(+), 13 deletions(-)

diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 5eab191607f8..42161d985004 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -611,13 +611,9 @@
* authentication/association or not receiving a response from the AP.
* Non-zero %NL80211_ATTR_STATUS_CODE value is indicated in that case as
* well to remain backwards compatible.
- * When establishing a security association, drivers that support 4 way
- * handshake offload should send %NL80211_CMD_PORT_AUTHORIZED event when
- * the 4 way handshake is completed successfully.
* @NL80211_CMD_ROAM: Notification indicating the card/driver roamed by itself.
- * When a security association was established with the new AP (e.g. if
- * the FT protocol was used for roaming or the driver completed the 4 way
- * handshake), this event should be followed by an
+ * When a security association was established on an 8021x network using
+ * fast transition, this event should be followed by an
* %NL80211_CMD_PORT_AUTHORIZED event.
* @NL80211_CMD_DISCONNECT: drop a given connection; also used to notify
* userspace that a connection was dropped by the AP or due to other
@@ -1027,13 +1023,11 @@
* @NL80211_CMD_DEL_PMK: For offloaded 4-Way handshake, delete the previously
* configured PMK for the authenticator address identified by
* %NL80211_ATTR_MAC.
- * @NL80211_CMD_PORT_AUTHORIZED: An event that indicates that the 4 way
- * handshake was completed successfully by the driver. The BSSID is
- * specified with %NL80211_ATTR_MAC. Drivers that support 4 way handshake
- * offload should send this event after indicating 802.11 association with
- * %NL80211_CMD_CONNECT or %NL80211_CMD_ROAM. If the 4 way handshake failed
- * %NL80211_CMD_DISCONNECT should be indicated instead.
- *
+ * @NL80211_CMD_PORT_AUTHORIZED: An event that indicates an 8021x FT roam was
+ * completed successfully. Drivers that support 4 way handshake offload
+ * should send this event after indicating 8021x FT assocation with
+ * %NL80211_CMD_ROAM. If the 4 way handshake failed %NL80211_CMD_DISCONNECT
+ * should be indicated instead.
* @NL80211_CMD_CONTROL_PORT_FRAME: Control Port (e.g. PAE) frame TX request
* and RX notification. This command is used both as a request to transmit
* a control port frame and as a notification that a control port frame
--
2.21.1


2020-05-26 13:11:23

by Johannes Berg

[permalink] [raw]
Subject: Re: [PATCH] nl80211: fix PORT_AUTHORIZED wording to reflect behavior

Arend,

On Mon, 2020-04-13 at 09:20 -0700, James Prestwood wrote:
> The CMD_PORT_AUTHORIZED event was described as an event which indicated
> a successfully completed 4-way handshake. But the behavior was
> not as advertized. The only driver which uses this is brcmfmac, and
> this driver only sends the event after a successful 8021x-FT roam.
>
> This prevents userspace applications from knowing if the 4-way completed
> on:
>
> 1. Normal 8021x connects
> 2. Normal PSK connections
> 3. FT-PSK roams
>
> wpa_supplicant handles this incorrect behavior by just completing
> the connection after association, before the 4-way has completed.
> If the 4-way ends up failing it disconnects at that point.

Can you comment on this?

We do have an (still out-of-tree, and probably will remain that way
since the firmware never really took off) driver that sends it in all
the cases that we documented ...

johannes