| Message ID | EF6DF72779EE294A8A2425E8DA3BC0CC54351E0E@Pallas.devolo.intern |
|---|---|
| State | Not Applicable |
| Headers | show |
Hi, Am 12.05.2016 um 17:28 schrieb Guenther Kelleter: >> What exactly is not working in the static VLAN case? >> I can configure an SSID to be part of a non-dynamic vlan in OpenWrt, >> i.e. that all stations are put in the configured vlan-bridge. This >> doesn't create a wlan0.<VLAN-ID> interface but uses the plain wlan0. >> I can't see anything not working in this case before this fix was >> added. >> Maybe you're talking about a different thing? When configuring non-wildcard vlans with config option vlan_file , hostapd will create the AP_VLAN (= wlan0.xyz) interfaces during process startup and possibly add them to a bridge. This is what I call "static" VLANs, as their AP_VLAN interfaces are present all the time while hostapd runs. That way the (static) AP_VLAN interfaces might already transmit broadcast or multicast frames even when there is no station associated in this VLAN. If hostapd does not configure any WPA group key to the AP_VLAN interface, it will transmit unencrypted. > Adding this patch the station can associate again and the tagged wlan interface is created and put into the vlan-bridge. But I don't know what negative consequences it could cause: I guess it basically makes hostapd believe it already configured a group key to the AP_VLAN interface and thus nullifies the fix. I might as well also break other things. Regards, M. Braun
Hi > -----Original Message----- > From: Hostap [mailto:hostap-bounces@lists.infradead.org] On Behalf Of M. Braun > Sent: Friday, May 13, 2016 9:19 AM > To: hostap@lists.infradead.org > Subject: Re: dynamic vlan with ath10k not working - regression > > Hi, > > Am 12.05.2016 um 17:28 schrieb Guenther Kelleter: > >> What exactly is not working in the static VLAN case? > >> I can configure an SSID to be part of a non-dynamic vlan in OpenWrt, > >> i.e. that all stations are put in the configured vlan-bridge. This > >> doesn't create a wlan0.<VLAN-ID> interface but uses the plain wlan0. > >> I can't see anything not working in this case before this fix was > >> added. > >> Maybe you're talking about a different thing? > > When configuring non-wildcard vlans with config option vlan_file , > hostapd will create the AP_VLAN (= wlan0.xyz) interfaces during process > startup and possibly add them to a bridge. This is what I call > "static" VLANs, as their AP_VLAN interfaces are present all the time > while hostapd runs. > That way the (static) AP_VLAN interfaces might already transmit > broadcast or multicast frames even when there is no station associated > in this VLAN. > If hostapd does not configure any WPA group key to the AP_VLAN > interface, it will transmit unencrypted. > > > Adding this patch the station can associate again and the tagged wlan > interface is created and put into the vlan-bridge. But I don't know what > negative consequences it could cause: > > I guess it basically makes hostapd believe it already configured a group > key to the AP_VLAN interface and thus nullifies the fix. I might as well > also break other things. > > Regards, > M. Braun > Let me sum up what I did understand so far: An AP_VLAN interface is created with every VLAN on a specific SSID. There is always an AP_VLAN with ID 0 created for the base interface of an SSID. When more VLANs are configured, either by static configuration in a vlan_file or by dynamic assignment through 802.1X RADIUS, an extra AP_VLAN interface is created per configured VLAN. All AP_VLANs of an SSID must use their own group keys, to separate broadcast and multicast traffic. If they had no group key set broadcasts from lets say VLAN-1 would be transmitted unencrypted and then could be received by all the stations which are associated to the same SSID but assigned to another VLAN. Is this correct? 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. 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. 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. Thanks, Günther
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. 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/
Hi > -----Original Message----- > From: Hostap [mailto:hostap-bounces@lists.infradead.org] On Behalf Of M. Braun > Sent: Sunday, May 15, 2016 4:45 PM > To: hostap@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@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/hostap
On 19 May 2016 at 13:45, Guenther Kelleter <Guenther.Kelleter@devolo.de> wrote: > Hi > > >> -----Original Message----- >> From: Hostap [mailto:hostap-bounces@lists.infradead.org] On Behalf Of M. Braun >> Sent: Sunday, May 15, 2016 4:45 PM >> To: hostap@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=fa7e1fbcb52cc9efab394526a566d80fb31529bb 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. Be vary that this will impact performance (both airtime efficiency and CPU consumption for various reasons). Michał
> -----Original Message----- > From: Michal Kazior [mailto:michal.kazior@tieto.com] > Sent: Friday, May 20, 2016 8:27 AM > To: Guenther Kelleter > Cc: hostap@lists.infradead.org > Subject: Re: dynamic vlan with ath10k not working - regression > > On 19 May 2016 at 13:45, Guenther Kelleter <Guenther.Kelleter@devolo.de> > wrote: > > Hi > > > > > >> -----Original Message----- > >> From: Hostap [mailto:hostap-bounces@lists.infradead.org] On Behalf Of M. > Braun > >> Sent: Sunday, May 15, 2016 4:45 PM > >> To: hostap@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
Am 20.05.2016 um 15:16 schrieb Guenther Kelleter: > 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(?) We need different GTK per AP/AP_VLAN netdev in order to achieve per-VLAN isolation. So the correct correct GTK when encrypting the broadcast/multicast frame must be choosen. As AP_VLAN is within a single BSS, BSSID cannot be used to select here. As GTK is for broadcast/multicast frames, destination mac address cannot be used as well. So there is nothing except the AP_VLAN ifindex here to make the driver or firmware choose the correct GTK. Passing all GTK to the AP interface will essentially not allow for multiple (per VLAN) GTK to be stored/used. Instead, the GTK for one VLAN would override the one for another VLAN. > 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? As PTK is used for unicast traffic, the correct key can be selected using the destination mac address (station). Thus AP_VLAN does not matter with PTK. Regards, M. Braun
On 20 May 2016 at 15:16, Guenther Kelleter <Guenther.Kelleter@devolo.de> wrote: > >> -----Original Message----- >> From: Michal Kazior [mailto:michal.kazior@tieto.com] >> Sent: Friday, May 20, 2016 8:27 AM >> To: Guenther Kelleter >> Cc: hostap@lists.infradead.org >> Subject: Re: dynamic vlan with ath10k not working - regression >> >> On 19 May 2016 at 13:45, Guenther Kelleter <Guenther.Kelleter@devolo.de> >> wrote: >> > Hi >> > >> > >> >> -----Original Message----- >> >> From: Hostap [mailto:hostap-bounces@lists.infradead.org] On Behalf Of M. >> Braun >> >> Sent: Sunday, May 15, 2016 4:45 PM >> >> To: hostap@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 10.2.4.70.42-2 does advertise raw-mode. > [ 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 But you didn't enable sw crypto in this case (see "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 10.2.4.97 does not support raw-mode. > [ 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) And you can see driver telling you it doesn't support sw crypto without raw mode support. Michał
Hi > -----Original Message----- > From: Michal Kazior [mailto:michal.kazior@tieto.com] > Sent: Monday, May 23, 2016 7:31 AM > To: Guenther Kelleter > Cc: hostap@lists.infradead.org > Subject: Re: dynamic vlan with ath10k not working - regression > > On 20 May 2016 at 15:16, Guenther Kelleter <Guenther.Kelleter@devolo.de> > wrote: > > > >> -----Original Message----- > >> From: Michal Kazior [mailto:michal.kazior@tieto.com] > >> Sent: Friday, May 20, 2016 8:27 AM > >> To: Guenther Kelleter > >> Cc: hostap@lists.infradead.org > >> Subject: Re: dynamic vlan with ath10k not working - regression > >> > >> On 19 May 2016 at 13:45, Guenther Kelleter <Guenther.Kelleter@devolo.de> > >> wrote: > >> > Hi > >> > > >> > > >> >> -----Original Message----- > >> >> From: Hostap [mailto:hostap-bounces@lists.infradead.org] On Behalf Of M. > >> Braun > >> >> Sent: Sunday, May 15, 2016 4:45 PM > >> >> To: hostap@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 > > 10.2.4.70.42-2 does advertise raw-mode. > > > > [ 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 > > But you didn't enable sw crypto in this case (see "raw 0 hwcrypto 1"). My bad. I overlooked the features list and interpreted "raw 0" to mean unsupported. Now I tried rawmode or hwcrypto, but both turn out to be completely broken since I can't associate even with the crude workaround from further above this thread (disabling GTK installation for the dynamic VLAN). Can't figure out what's happening though. Now I'm desperately searching for some docs on AP_VLAN and key handling of mac80211. But the kernel-docbooks are empty w.r.t. this subject. Looking at the code to find out how this works seems really useless. And docs about ath10k FW would be fine too, this must be top secret matter. Not even changelogs seem to exist. Günther > > > > > > > > [ 14.366027] ath10k_pci 0000:00:00.0: firmware ver 10.2.4.97 api 5 > features no-p2p crc32 f91e34f2 > > 10.2.4.97 does not support raw-mode. > > > [ 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) > > And you can see driver telling you it doesn't support sw crypto > without raw mode support. > > > Michał
diff --git a/src/ap/wpa_auth.c b/src/ap/wpa_auth.c index 9c136ef..bca8573 100644 --- a/src/ap/wpa_auth.c +++ b/src/ap/wpa_auth.c @@ -361,7 +361,7 @@ static struct wpa_group * wpa_group_init(struct wpa_authenticator *wpa_auth, if (group == NULL) return NULL; - group->GTKAuthenticator = TRUE; + group->GTKAuthenticator = FALSE; group->vlan_id = vlan_id; group->GTK_len = wpa_cipher_key_len(wpa_auth->conf.wpa_group);