Re: [PATCH] ath10k: add dynamic vlan support

[Johannes Berg <johannes@sipsolutions.net>]

On Tue, 2018-08-14 at 18:23 +0530, Manikanta Pubbisetty wrote:

> > 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. 

Yeah ...

I'm confused and no longer sure what I was thinking, nor even what we're
trying to achieve here...

> 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.

I think we have to keep the 4-addr handling in AP_VLAN iftype either
way, to not break existing hostapd. We could introduce a separate
AP_VLAN_NO_4ADDR and then require updating hostapd to get non-4addr
VLAN, but that also seems awkward.

Since hostapd doesn't currently check anything...

Ok, no, I'm confused now. If we just clear WIPHY_FLAG_4ADDR_AP, don't we
get what we want? 4-addr AP_VLAN interfaces would no longer be permitted
to be created?

johannes