Re: [RFC 4/4] nl80211: Implement TX of control port frames

[Johannes Berg <johannes@sipsolutions.net>]

On Tue, 2018-01-02 at 12:22 -0600, Denis Kenzior wrote:

> > There are cases where CONTROL_PORT_ETHERTYPE_NO_ENCRYPT should be
> > unset, but specific frames still shouldn't be encrypted.
> > 
> > So I think for this particular path it would be better to deprecate
> > CONTROL_PORT_ETHERTYPE_NO_ENCRYPT entirely, and have a separate per-
> > frame flag.
> > 
> > That also means that we can't really implement it fully in cfg80211,
> > but have to provide some functionality for the driver to do things to
> > be able to honour such flags.
> 
> Here's another thought I had while poking around.  Given the above I 
> don't want to pursue it too seriously unless you think it might work:
> 
> We already have the IEEE80211_TX_INTFL_DONT_ENCRYPT flag on the skb and 
> some drivers seem to honor this.  At least that seems to be the intent 
> as the CONTROL_PORT_NO_ENCRYPT flag ends up being translated to this 
> somewhere in net/mac80211/tx.c.  Are the drivers supposed to honor that 
> flag?

Drivers don't have a choice, and don't need to check the flag. What
happens internally in mac80211 is that either txinfo->control.key is
assigned, or not, and drivers make encryption decisions based on that.

> If so, can we do something like what ieee80211_process_sa_query_req in 
> net/mac80211/rx.c or ieee80211_tdls_prep_mgmt_packet in 
> net/mac80211/tdls.c do?  E.g. use ieee80211_tx_skb or 
> __ieee80211_subif_start_xmit or similar to inject the skb with the 
> DONT_ENCRYPT flag?

Yes, this will work - but like I said, it requires more control over
the SKB than cfg80211 has today, and than you can get through the
regular netdev xmit.

> > Perhaps a new operation, where we pass a pre-built SKB and control
> > flags?

> 
> This would likely mean that legacy behavior would still have to be 
> supported for quite some time (forever?) for drivers that don't get 
> around to implementing this, which would be unfortunate.

What do you mean by "legacy behaviour"? *Drivers* don't really need to
do anything one way or the other, and mac80211 is the only thing
implementing control port encrypt/ethertype right now, I suspect.

johannes