Hi,

quoted

quoted

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?

Heh, yeah, badly phrased. It'll work to do it like process_sa_query or
similar code, for mac80211 drivers. What will *not* work is actually
building and submitting the SKB in cfg80211 though, since you can't
even set the DONT_ENCRYPT flag from there.

quoted

quoted

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.

We need to support that behaviour forever anyway, for existing versions
of userspace software.

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?

Yes, NL80211_ATTR_CONTROL_PORT_ETHERTYPE is an attribute set in the
wiphy info - see WIPHY_FLAG_CONTROL_PORT_PROTOCOL in the code.

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).

I think 802.3 format would be better - matches better for full-MAC
devices that might do all header conversion in the device, and getting
the BSSID might even be difficult from cfg80211, etc.

johannes