dynamic vlan with ath10k not working - regression
diff mbox

Message ID EF6DF72779EE294A8A2425E8DA3BC0CC54351E0E@Pallas.devolo.intern
State Not Applicable
Headers show

Commit Message

Günther Kelleter May 12, 2016, 3:28 p.m. UTC
Replying to my own message:

> -----Original Message-----
> From: Hostap [mailto:hostap-bounces@lists.infradead.org] On Behalf Of Guenther
> Kelleter
> Sent: Thursday, May 12, 2016 12:25 PM
> To: hostap@lists.infradead.org
> Subject: RE: dynamic vlan with ath10k not working - regression
> 
> Hi
> 
> At first please excuse my ignorance but I'm new to WiFi and hostapd and don't
> know yet how all this is working.
> 
> > -----Original Message-----
> > From: michael-dev [mailto:michael-dev@fami-braun.de]
> > Sent: Thursday, May 12, 2016 3:03 AM
> > To: Guenther Kelleter
> > Cc: hostap@lists.infradead.org
> > Subject: Re: dynamic vlan with ath10k not working - regression
> >
> > Hi,
> >
> > Am 11.05.2016 16:25, schrieb Guenther Kelleter:
> > > Since commit 7cebc8e2100626dc6981a3f53301058452953b9b, "Fix init of
> > > group state machine for static VLANs" dynamic VLAN isn't working with
> > > atk10k radio anymore. Parent commit works as expected.
> >
> > basically this fix added wpa group key initialization during ap_vlan
> > interface creation, that is before any station is assigned to the
> > driver.
> > This is required for static VLANs with WPA where AP_VLAN interfaces are
> > created possibly long before any station connects.
> 
> 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?
> 
> >
> > > Symptom is that neither wlanX-Y.<VLAN-ID> nor the corresponding
> > > vlan-bridge is created. Association fails.
> >
> > The driver refuses to accept the key. Therefore that per VLAN wpa_group
> > enters state FATAL_FAILURE, thus stations cannot complete group keying.
> >
> > Solutions
> > a) make ath10k accept group keys without any station connected
> 
> I understand even less of the driver than of hostapd :-) It's a pitch black
> box...
> 
> > b) let hostapd skip set_key without any stations connected if this is a
> > dynamic vlan. This means static VLANs will continue to not work with
> > ath10k.
> 
> Hmmm... looking at the code I'm not sure how to do that
> Prevent calling wpa_group_setkeysdone?

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 unsure which would be best?
> >
> > > I tried the same with ath9k radio: works as expected with both
> > > versions.
> > >
> > > This is the relevant debug log of hostapd:
> > >
> > > wlan0-2: STA 78:7e:61:61:15:a3 RADIUS: VLAN ID 20
> >
> > so we add the new ap_vlan interface due to a station needing it.
> >
> > > nl80211: New interface wlan0-2.20 created: ifindex=60
> >
> > that interface has ifindex=60 assigned
> >
> > > VLAN: Set interface wlan0-2.20 up
> >
> > and is configured ifconfig_up
> >
> > > WPA: Add group state machine for VLAN-ID 20
> >
> > now wpa group keying starts before the station was assigned to the
> > driver
> >
> > > wpa_driver_nl80211_set_key: ifindex=60 (wlan0-2.20) alg=3
> > > addr=0x496be4 key_idx=1 set_tx=1 seq_len=0 key_len=16
> >
> > a wpa group key shall be configured to the wireless driver
> >
> > > nl80211: set_key failed; err=-22 Invalid argument)
> >
> > but the driver does not like it. I don't know why. It should not.
> >
> > > WPA: group state machine entering state FATAL_FAILURE
> >
> > so the group state machine blocks and
> >
> > > WPA initialization for VLAN 20 failed (-1)
> >
> > interface initialization is declared failing
> >
> > Regards,
> > M. Braun
> 
> 
> Günther
> 
> _______________________________________________
> Hostap mailing list
> Hostap@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/hostap

Comments

Michael Braun May 13, 2016, 7:18 a.m. UTC | #1
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
Günther Kelleter May 13, 2016, 11:46 a.m. UTC | #2
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
Michael Braun May 15, 2016, 2:44 p.m. UTC | #3
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/
Günther Kelleter May 19, 2016, 11:45 a.m. UTC | #4
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
Michal Kazior May 20, 2016, 6:26 a.m. UTC | #5
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ł
Günther Kelleter May 20, 2016, 1:16 p.m. UTC | #6
> -----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
Michael Braun May 22, 2016, 12:25 p.m. UTC | #7
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
Michal Kazior May 23, 2016, 5:30 a.m. UTC | #8
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ł
Günther Kelleter May 25, 2016, 12:35 p.m. UTC | #9
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ł

Patch
diff mbox

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);