Dynamic VLANs Broken, Possible GTK Issue

[corrideat]

I’m running LEDE 17.01.2 on an Archer C7 v2 using the ath10k-ct firmware and driver. I have my network setup to use WPA2 with 802.1X authentication and dynamic VLANs. Unfortunately, there seems to be some issue in the GTK setup for this use case, which I’m suspecting is related to the ath10k driver. The issue is at https://bugs.lede-project.org/index.php?do=details&task_id=488, and the discussions at https://lists.infradead.org/pipermail/ath10k/2016-May/007525.html and https://lists.infradead.org/pipermail/ath10k/2016-May/007525.html are most enlightening.

This is what happens:

1. If using the latest hostapd (2016-12-19-ad02e79d-3) and the latest drivers, the AP won’t let stations connect, because it will fail to create the interface for the VLAN. In my testing some time ago, if I tried to make hostapd create the VLANs ahead of time (using the vlan_file directive), it would then refuse to start.
2. If using the stock ath10k driver and firmware (not the CT version) but an older hostapd version (2015-03-25-1), the APs can connect, but GTK is somehow broken, so stations cannot talk to each other, and multicast works only in one direction (stations to AP.)
3. If using the CT ath10k driver and firmware (firmware-2-ct-non-commercial-full-htt-mgt-18.bin) but an older hostapd version (2015-03-25-1), the APs can connect, but GTK is somehow broken in a different way. In this case, the stations can talk to each other and multicast works in both directions, but the VLANs are not isolated. As a result, stations in one VLAN will receive SLAAC IPv6 addresses corresponding to all possible (active) VLANs. Obviously, this also has privacy implications as well.
4. If using a slightly patched (attached) CT ath10k driver and firmware (and possibly the stock firmware as well) and the latest hostapd (2016-12-19-ad02e79d-3), the situation is very much as 2.
5. If using the latest ath10k driver and firmware and the latest hostapd but with HW encryption disabled, everything works as expected, except that performance is greatly degraded (maxing out at around 35Mbps in my tests vs ~300Mbps, possibly more, with hardware encryption).

I am submitting two test log files, using the ath10k (stock, version 2017-01-31) and ath10k-ct (version 2017-01-26), and using the Candela firmware version 10.1-ct-8x-__fW-019-395e9f1, firmware-2-ct-full-community.bin anc firmware-2-ct-full-htt-mgt-community.bin, respectively.

999_ath10k_swmode_if_disabled_hwmode.patch
kmod-ath10k-ct+10.1-ct-8x-__fH-019-395e9f1.log (firmware-2-ct-full-htt-mgt-community.bin)
kmod-ath10k+10.1-ct-8x-__fW-019-395e9f1.txt (firmware-2-ct-full-community.bin)

[greearb]

After reading through the hostapd thread linked, I suspect this is more than just a firmware issue. Maybe a potential fix is to modify my firmware (and probably the driver) to send some VLAN broadcast frames as raw software-encrypted frames, and normal peer traffic as 'hardware-crypted' frames. This is not a simple task, and I will most likely not try to work on this until I find some customer wanting to pay for this or similar features.

[corrideat]

Thanks for taking the time to review this. I was afraid that the issue was going to be complicated to resolve. If it indeed is (to some extent, at least) a firmware issue, as it appears, it is also pretty much impossible to fix without someone with access to the firmware sources.

As for your proposed solution, wouldn't multicast traffic then have to be software encrypted? That seems like a downside, although it's still better than the current situation.

I understand that this won't be prioritised for fixing, especially if it's a complicated procedure. I also don't think that I'm prepared to sponsor the entire cost of developing this feature, as acquiring equipment from some other vendor (like Broadcom chipsets) is going to be cheaper and more reliable in the short term. However, perhaps a Kickstarter campaign could be set up for developing this or related features?

Thank you,

[greearb]

On 09/05/2017 11:24 AM, Ricardo Iván Vieitez Parra wrote: Thanks for taking the time to review this. I was afraid that the issue was going to be complicated to resolve. If it indeed is (to some extent, at least) a firmware issue, as it appears, it is also pretty much impossible to fix without someone with access to the firmware sources. As for your proposed solution, wouldn't multicast traffic then have to be software encrypted? That seems like a downside, although it's still better than the current situation. I understand that this won't be prioritised for fixing, especially if it's a complicated procedure. I also don't think that I'm prepared to sponsor the entire cost of developing this feature, as acquiring equipment from some other vendor (like Broadcom chipsets) is going to be cheaper and more reliable in the short term. However, perhaps a Kickstarter campaign <http://www.candelatech.com/ath10k_kickstarter.php> could be set up for developing this or related features?

I got a quite small amount of interest in the last kickstarter, and this feature is probably even more obscure. sw-crypt for just a few broadcast frames is likely trivial amount of CPU, but the amount of work involved is probably multiple weeks of effort, and that is not cheap. If you have another vendor that provides the needed features, that is probably your best option at this point. Thanks, Ben

…

-- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com

[enryIT]

Could this possible be related to the WDS (4addr) issue? 4addr mode can't be set, the wlanX.staY doesn't get created nor added to the bridge.

Should I open a new issue?

[greearb]

Yes, if you have more specific details based on more recent software/firmware, please do open a new bug. Let me know what CT FW you are using, platform, etc. And, whether stock driver/firmware has the same issue.