dynamic vlan with ath10k not working - regression

[Guenther Kelleter]

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. 

from net/mac80211/key.c:ieee80211_key_enable_hw_accel() of mac-80211
Thats why set_key() fails:

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))         // ! This condition is true
                        goto out_unsupported;
        }
[...]
out_unsupported:
        switch (key->conf.cipher) {
        case WLAN_CIPHER_SUITE_WEP40:
        case WLAN_CIPHER_SUITE_WEP104:
        case WLAN_CIPHER_SUITE_TKIP:
        case WLAN_CIPHER_SUITE_CCMP:
        case WLAN_CIPHER_SUITE_CCMP_256:
        case WLAN_CIPHER_SUITE_AES_CMAC:
        case WLAN_CIPHER_SUITE_BIP_CMAC_256:
        case WLAN_CIPHER_SUITE_BIP_GMAC_128:
        case WLAN_CIPHER_SUITE_BIP_GMAC_256:
        case WLAN_CIPHER_SUITE_GCMP:
        case WLAN_CIPHER_SUITE_GCMP_256:
                /* all of these we can do in software - if driver can */
                if (ret == 1)
                        return 0;
                if (ieee80211_hw_check(&key->local->hw, SW_CRYPTO_CONTROL))    // ! this condition also true 
-------->               return -EINVAL;
                return 0;
        default:
                return -EINVAL;
        }
}



Günther


> 
> Please also note that also with dynamic vlans, there might be some
> time (and protocol steps) between hostapd creating the new AP_VLAN
> interface but not yet binding the station there.
> 
> > then could be received by all the stations which are associated to
> > the same SSID but assigned to another VLAN.
> 
> The stations should not accept those packets because they should expect
> all frames to be encrypted. But those packets could be sniffed by any
> possibly unconnected station and thus leak data.
> 
> > How can I check if an AP_VLAN has a group key? I want to make sure
> > that the dynamic VLANs are properly encrypted when I'm patching this
> > to work on ath10k.
> 
> You can hook into the set_key function and debug print it.
> Or you generate some packets on that interface (e.g. with some
> distinguishing source mac address ) and then sniff it. As the mac
> address is not encrypted, you can easily filter for these packets and
> inspect them for encryption.
> 
> Properly encrypted would also require the keys used to be sufficiently
> random, thought that cannot be verified that easily.
> 
> > How to check if a GTK-rekey is executed for all AP_VLANs? (In debug
> > log I only see " daemon.debug hostapd: wlan0: WPA rekeying GTK" but
> > not e.g. " daemon.debug hostapd: wlan0.20: WPA rekeying GTK" for the
> > tagged wlan interface.
> 
> see src/ap/wpa_auth.c function wpa_rekey_gtk which creates that debug
> print. It iterates over all struct wpa_group ( aka VLAN ) of that BSS
> and triggers rekeying. So the main point for making sure WPA rekeying
> happens for all VLANs is by ensuring that for each AP_VLAN interface,
> there is a corresponding struct wpa_group entry.
> This is also how 7cebc8e2 fixed its issue.
> Of course you can just add debug statements into that loop.
> 
> > Finally, is there any useful doc about those complex internals of
> > hostapd? It's really difficult to know this by only looking at the
> > code. And 802.11 doesn't mention how VLANs fit into it at all.
> 
> Hostapd has doxygen docs [1]. Apart of that, I have been reading the
> source of hostapd and mac80211 for some years now.
> 
> Regards,
>  M. Braun
> 
> [1] http://w1.fi/wpa_supplicant/devel/
> 
> 
> _______________________________________________
> Hostap mailing list
> Hostap at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/hostap