[PATCH] ath10k: add dynamic vlan support
mpubbise at codeaurora.org
Tue Aug 14 05:53:05 PDT 2018
On 5/23/2018 3:20 PM, Johannes Berg wrote:
> On Mon, 2018-05-21 at 12:12 +0530, Manikanta Pubbisetty wrote:
>>> Do you know why it actually broke it? I mean, we should've turned off
>>> the strict requirement for sw crypto control only for the GTK, and that
>>> shouldn't matter so much?
>> With the change db3bdcb9c3ff, AP/VLAN support is advertised by the
>> driver conditionally; the primary reason for doing this is to support
>> VLAN operations on sw crypto controlled devices.
> Right, or, well *not* supporting it.
>> AP also creates AP/VLAN devices for supporting 4-addr clients and since
>> the driver now advertises AP/VLAN support conditionally, the 4-addr
>> operation which has no relation to the VLANs(Per VLAN GTKs) was broken
>> on some ath10k devices.
> Right. Like I said, splitting those two capabilities somehow would be
>>>> + * @IEEE80211_HW_SUPPORTS_SW_ENCRYPT: Device is capable of transmitting
>>>> + * frames encrypted in software, only valid when SW_CRYPTO_CONTROL
>>>> + * is enabled. Based on this flag, mac80211 can allow/disallow VLAN
>>>> + * operations in the BSS.
>>> Based on the name and initial description, this sounds equivalent to
>>> just turning off SW_CRYPTO_CONTROL. I think that's not the intent, but
>>> would need some renaming.
>> I can rename it to something which is very specific to VLAN support on
>> sw crypto controlled devices if that is okay.
> I don't think that makes sense. If we split the capability of AP_VLAN
> and AP_VLAN_FOR_4ADDR at the "root", then we don't need to play with all
> these things. Yes, this is slightly awkward for userspace, and perhaps
> with the interface combination checks, but I'd like you to look at that.
I was working on splitting the 4-addr functionality from AP/VLAN iftype;
I have introduced a new iftype NL80211_IFTYPE_AP_4ADDR and moved the
4-addr handling from AP/VLAN to this new iftype. But this approach
breaks the backward compatibility with older userspace applications.
Since I am completely moving the 4-addr handling to the new type, older
applications which do not understand this new type will simply fail and
4-addr mode will be completely broken.
Currently, whenever a 4-addr client attempts a connection, hostapd just
creates a AP/VLAN interface and moves the 4-addr client to the AP/VLAN
iface; there are no other checks. I had no other option other than going
with a new iftype for 4-addr handling.
Is there a way we can maintain backward compatibility with this
approach? Retaining the 4-addr handling in AP/VLAN and duplicating the
same functionality to the new iftype seems will work but I am not sure
if this is the right approach.
More information about the ath10k