Yes Sebastian, Your point is valid. This would break the 4-addr
operation on other ath10k devices which does not support the new WMI
service.
I have another approach to solve this problem, I will come with a small
patch and see what johannes has to say on that approach.
Manikanta
On 4/24/2018 2:39 PM, Sebastian Gottschall wrote:
consider my comment regarding vlan_ap.
this patch will break wds ap / wds sta support with latest mac80211
(see also my post on the wireless mailing list about the breaking
patch in mac80211)
so AP_VLAN must be masked always for all chipsets. otherwise wds
breaks and this is not just a guess. i tested it yesterday using this
patch and found
the cause of the issue
the following lines
+ if (test_bit(WMI_SERVICE_PER_PACKET_SW_ENCRYPT,
ar->wmi.svc_map)) {
+ ar->hw->wiphy->interface_modes |= BIT(NL80211_IFTYPE_AP_VLAN);
+ ar->hw->wiphy->software_iftypes |= BIT(NL80211_IFTYPE_AP_VLAN);
+ }
must be just
+ ar->hw->wiphy->interface_modes |= BIT(NL80211_IFTYPE_AP_VLAN);
+ ar->hw->wiphy->software_iftypes |= BIT(NL80211_IFTYPE_AP_VLAN);
everthing else will cause a regression
Am 24.04.2018 um 10:09 schrieb Kalle Valo:
Manikanta Pubbisetty <mpubb...@codeaurora.org> writes:
Mutlicast/broadcast traffic destined for a particular vlan group will
always be encrypted in software. To enable dynamic VLANs, it requires
driver support for sending software encrypted packets.
In ath10k, sending sw encrypted frames is allowed only when we insmod
the driver with cryptmode param set to 1, this configuration disables
hardware crypto and enables RAW mode implicitly. Since, enabling raw
mode has performance impact, this cannot be considered as an ideal
solution for supporting VLANs in the driver.
As an alternative take, in this approach, cryptographic keys for
unicast traffic(per peer PTKs) and keys for non-vlan group traffic
will be configured in hardware, allowing hardware encryption for
unicast
and non-vlan group traffic. Only vlan group traffic will be
encrypted in
software and pushed to the target with encap mode set to RAW in the TX
descriptors.
Not all firmwares can support this type of key configuration(having few
keys installed in hardware and few only in software); for this
purpose a
new WMI service flag "WMI_SERVICE_PER_PACKET_SW_ENCRYPT" is
introduced to
advertise this support.
Also, adding the logic required to send sw encrypted frames in raw
mode.
Tested this change on QCA9984(firmware version 10.4-3.5.3-00057).
Signed-off-by: Manikanta Pubbisetty <mpubb...@codeaurora.org>
Your name in patchwork is wrong and hence my script uses the wrong
name. Please fix it by registering to patchwork[1] where it's possible
to change your name during registration, but only one time. If that
doesn't work then send a request to helpd...@kernel.org and the admins
can fix it.
[1] https://patchwork.kernel.org/register/
