On 5/23/2018 4:09 PM, Johannes Berg wrote:
On Wed, 2018-05-23 at 16:09 +0530, Manikanta Pubbisetty wrote:
+ * @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.
Makes sense, I had this thought to split the VLAN and 4-addr
functionality, but since we need to fiddle with userspace, I refrained.
Anyways, I will check all the possibilities of splitting these
functionalities.
I'm not sure we really have to - it's likely that wpa_s/hostapd don't
check the capabilities?
johannes
IIUC, hostapd will just invoke a NL command to create the AP/VLAN
interface, the capabilities are checked mostly in cfg80211.
If we are planning to split the functionality, possibly something like
having two separate IF-TYPES(one for VLAN and one for 4-addr) instead of
one(which is the case now),
we should probably change the relevant areas in hostapd as well, not
really sure of the complexity of the work involved in userspace though.
