Re: [RFC 0/4] EAPoL over NL80211

[Denis Kenzior <denkenz@gmail.com>]

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