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 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?
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
