> -----Original Message----- > From: Michal Kazior [mailto:michal.kazior@xxxxxxxxx] > Sent: Friday, May 20, 2016 8:27 AM > To: Guenther Kelleter > Cc: hostap@xxxxxxxxxxxxxxxxxxx > Subject: Re: dynamic vlan with ath10k not working - regression > > On 19 May 2016 at 13:45, Guenther Kelleter <Guenther.Kelleter@xxxxxxxxx> > wrote: > > Hi > > > > > >> -----Original Message----- > >> From: Hostap [mailto:hostap-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of M. > Braun > >> Sent: Sunday, May 15, 2016 4:45 PM > >> To: hostap@xxxxxxxxxxxxxxxxxxx > >> Subject: Re: dynamic vlan with ath10k not working - regression > >> > >> Am 13.05.2016 um 13:46 schrieb Guenther Kelleter: > >> > Let me sum up what I did understand so far: > >> > ... > >> > Is this correct? > >> > >> Yes. > >> > >> To be more precise, that "base" interface is per BSS and has type "AP", > >> but that does not really make a difference here. > > > > Ah, but isn't this exactly the difference that matters here? > > According to a comment in mac80211 an AP_VLAN interface is not represented > by a vdev of the driver. And a key cannot be installed for a VLAN. Does > AP_VLAN encryption have to be handled in software? But the SW_CRYPTO_CONTROL > flag somehow prevents SW-crypto for ath10k. > > How is this VLAN encryption gonna work at all when for an AP_VLAN neither HW > nor SW- crypto are supported? > > I don't get it. > > Some drivers (i.e. ath10k in this case) don't use real 802.11 frames > when talking to device firmware hence it is impossible to pass through > things like IV and MIC unless both FW and HW fully support given > crypto mode. > > See: > https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/?id=fa7e1fbc > b52cc9efab394526a566d80fb31529bb > > What you can do is to try using raw mode in ath10k (I think recent > 10.2.4.x should do fine) by playing around with "cryptmode" and > "rawmode" ath10k_core module parameters. I tried that already, but neither 10.2.4.70.xx nor 10.2.4.97 support raw mode which the driver requires for cryptmode=1. [ 13.570000] ath10k_pci 0000:00:00.0: firmware ver 10.2.4.70.42-2 api 5 features no-p2p,raw-mode,mfp crc32 44f66eae [ 13.620000] ath10k_pci 0000:00:00.0: Direct firmware load for ath10k/QCA988X/hw2.0/board-2.bin failed with error -2 [ 13.630000] ath10k_pci 0000:00:00.0: Falling back to user helper [ 13.700000] firmware ath10k!QCA988X!hw2.0!board-2.bin: firmware_loading_store: map pages failed [ 13.720000] ath10k_pci 0000:00:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08 [ 14.860000] ath10k_pci 0000:00:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 cal file max-sta 128 raw 0 hwcrypto 1 [ 14.366027] ath10k_pci 0000:00:00.0: firmware ver 10.2.4.97 api 5 features no-p2p crc32 f91e34f2 [ 14.415333] ath10k_pci 0000:00:00.0: Direct firmware load for ath10k/QCA988X/hw2.0/board-2.bin failed with error -2 [ 14.425989] ath10k_pci 0000:00:00.0: Falling back to user helper [ 14.703039] firmware ath10k!QCA988X!hw2.0!board-2.bin: firmware_loading_store: map pages failed [ 14.732334] ath10k_pci 0000:00:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08 [ 14.739841] ath10k_pci 0000:00:00.0: cryptmode > 0 requires raw mode support from firmware [ 14.748279] ath10k_pci 0000:00:00.0: fatal problem with firmware features: -22 [ 14.755852] ath10k_pci 0000:00:00.0: could not probe fw (-22) However, I might be wrong, but I think that trying to set a HW-crypt key for an AP_VLAN vif the driver doesn't know about is wrong in the first place. The AP_VLAN's (I)GTK should be passed via the corresponding AP vif to ieee80211_key_enable_hw_accel() instead(?) Because static int ieee80211_key_enable_hw_accel(struct ieee80211_key *key) [...] if (sdata->vif.type == NL80211_IFTYPE_AP_VLAN) { /* * The driver doesn't know anything about VLAN interfaces. * Hence, don't send GTKs for VLAN interfaces to the driver. */ if (!(key->conf.flags & IEEE80211_KEY_FLAG_PAIRWISE)) goto out_unsupported; } it's an error to do this. Or is it only an ath10k defect and other drivers use SW-crypto on AP_VLAN? Can't we pass already encrypted frames to ath10k? Is the PTK for station on an AP_VLAN set on the corresponding AP vif resp. passed to AP's driver vdev? Or is AP_VLAN crypto not hw-accelerated? > > Be vary that this will impact performance (both airtime efficiency and > CPU consumption for various reasons). > > > Michał Günther _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
