Hi Johannes,
On 01/02/2018 07:30 AM, Johannes Berg wrote:
On Thu, 2017-12-28 at 11:58 -0600, Denis Kenzior wrote:
This commit implements the TX side of NL80211_CMD_CONTROL_PORT_FRAME.
Userspace provides the raw EAPoL frame using NL80211_ATTR_FRAME. A
skbuf is built and then injected onto the netdev of the wireless device.
The CONTROL_PORT_ETHERTYPE_NO_ENCRYPT will still in theory be honored by
You mean CONTROL_PORT_NO_ENCRYPT :-)
Right
the underlying TX path code.
I think this isn't good enough.
That was my thinking as well
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?
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?
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.
Regards,
-Denis
