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
best.
+ * @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.
Hi Johannes,
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.
Thanks,
Manikanta
