Hi Johannes,
<snip>
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.
So, I'm a bit lost here. You're saying this will work but then it
won't. Are you saying this would only work for mac80211 based devices
(e.g. ones that implement ieee80211_ops) but not ones that implement
cfg80211_ops? I presume because those provide their own net_device_ops?
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.
When I say legacy I mean 'over netdev', e.g. not over nl80211.
Okay, so what you're saying is that the current CONTROL_PORT_* stuff
doesn't work on anything besides mac80211 since drivers can completely
ignore stuff inside cfg80211_connect_params. And there's no way for
userspace to know this ahead of time?
So essentially we'd need a new operation in cfg80211_ops that would
accept the control port frame data and some control flags. Do we want
to pass in an skb with all the 802.11 headers set or a 802.3 formatted
skb (since that is what other data frames look like initially on the
netdev).
Regards,
-Denis
