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. 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@xxxxxxxxxxxxxxxxxxx > http://lists.infradead.org/mailman/listinfo/hostap _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
