On Wed, Jan 3, 2018 at 6:17 PM, Denis Kenzior <denkenz@xxxxxxxxx> wrote: > 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? That is my assumption as well. >> >>>> 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). Our firmware expects EAPOL stuff to come in as 802.3 packet, which probably applies to the other full-mac devices as well. Is there any reason for passing 802.11 packets. Regards, Arend
