On 12/28/2017 6:58 PM, Denis Kenzior wrote:
This patchset adds support for running 802.11 authentication mechanisms (e.g. 802.1X, 4-Way Handshake, etc) over NL80211 instead of putting them onto the network device. This has the advantage of fixing several long-standing race conditions that result from userspace operating on multiple transports in order to manage a 802.11 connection (e.g. NL80211 and wireless netdev, wlan0, etc) For example, userspace would sometimes see 4-Way handshake packets before NL80211 signaled that the connection has been established. Leading to ugly hacks or having the STA wait for retransmissions from the AP. To make this possible this patchset introduces a new NL80211 command and several new attributes. A userspace that is capable of processing EAPoL packets over NL80211 includes a new NL80211_ATTR_CONTROL_PORT_OVER_NL80211 attribute in its NL80211_CMD_ASSOCIATE or NL80211_CMD_CONNECT requests being sent to the kernel. The previously added NL80211_ATTR_SOCKET_OWNER attribute must also be included.
Does it make sense to require a combination of attributes. It is always a bit awkward so prefer to avoid it. Could we implicitly make the netlink unicast for notifications when NL80211_ATTR_CONTROL_PORT_OVER_NL80211 is provided by user-space.
The latter is used by the kernel to send NL80211_CMD_CONTROL_PORT_FRAME notifications back to userspace via a netlink unicast. If the NL80211_ATTR_CONTROL_PORT_OVER_NL80211 attribute is not specified, then legacy behavior is kept and control port packets continue to flow over the network interface.
[...]
Open Questions ============== 1. It is not clear whether all drivers provide information as to whether the control port frame was sent encrypted or not. Do they?
You mean in some tx status info. I think brcmfmac does not have that info available in the driver, but would need to verify.
2. It has been previously suggested that CMD_FRAME infrastructure is used to accomplish control port over nl80211 transport. However, it did not seem to be a good fit as the relevant code paths assume that only management frames are to be sent via this mechanism. Thoughts?
What are the issues coming from that assumption? Does it assume 802.11 header is present? What else?
Regards, Arend
