dynamic vlan with ath10k not working - regression

[Guenther Kelleter]

> -----Original Message-----
> From: Michal Kazior [mailto:michal.kazior at tieto.com]
> Sent: Friday, May 20, 2016 8:27 AM
> To: Guenther Kelleter
> Cc: hostap at lists.infradead.org
> Subject: Re: dynamic vlan with ath10k not working - regression
> 
> On 19 May 2016 at 13:45, Guenther Kelleter <Guenther.Kelleter at devolo.de>
> wrote:
> > Hi
> >
> >
> >> -----Original Message-----
> >> From: Hostap [mailto:hostap-bounces at lists.infradead.org] On Behalf Of M.
> Braun
> >> Sent: Sunday, May 15, 2016 4:45 PM
> >> To: hostap at lists.infradead.org
> >> 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