Hi Arend, <snip>
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.
Agreed, requiring both attributes is less than ideal, but I tried to make the initial RFC as minimal as possible. It also helped that iwd uses SOCKET_OWNER by default. What can be done is to always set conn_owner_nlportid and introduce another flag that would indicate whether 'connection tear-down on application exit' was requested.
However, my opinion is that the current SOCKET_OWNER behavior should just be made default, especially for control port over nl80211 connections, even if SOCKET_OWNER was not requested. Once the controlling application dies, there's no hope of salvaging the connection, perform rekeys, etc.
<snip>
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 areto be sent via this mechanism. Thoughts?What are the issues coming from that assumption? Does it assume 802.11 header is present? What else?
Correct. There's also quite a bit of logic to figure out whether the frame is being sent offchannel or not; whether offchannel capability is present in the driver, etc. This can be ignored for control port frames, but makes the code path complicated.
The biggest issue was that each driver defines a set of management frames it can accept via this mechanism. The set is structured using management frame type as an identifier and the code checks this set prior to accepting the frame to be sent via CMD_FRAME. Since control port frames are data frames it would probably require quite a bit of surgery in the core mac80211/wireless code and the driver code to make it work.
Another issue is that cfg80211_mgmt_tx_params doesn't have a 'don't encrypt' setting. So that part would need to be added as well.
Regards, -Denis
