Re: WDS vs. multi-channel operation

[Johannes Berg <johannes@sipsolutions.net>]

On Sun, 2012-08-05 at 19:12 +0200, Felix Fietkau wrote:
> On 2012-07-30 3:36 PM, Johannes Berg wrote:
> > Ok so I'm chipping away at multi-channel operation, but WDS is
> > troubling. Which channel should it use? It doesn't even have channel
> > configuration today, but relies on having a channel already, but that
> > breaks when you have multi-channel since then it either has to have its
> > own channel or be slaved to another channel...
> > 
> > Anyone have any ideas?
> Let's bind WDS interfaces to AP VIFs, then they can be slave to the AP's
> channel context. This is necessary for my yet-to-be-resubmitted WDS
> fixes anyway.

For now I decided that drivers supporting the channel context APIs will
not be allowed to support WDS interfaces :-P
(and the code in WDS TX will simply take the global channel as before)

So ... yes, I think this makes sense, but I'm not sure I care enough to
implement it right now, I have enough other things with multi-channel
still to do ... Though the question remains *how* we bind them. We could
try to match them by MAC address when they're brought up (and require
the same MAC address?), or do explicit binding, or something else
entirely ...

If you're going to require them to be bound to an AP though, where's the
difference to the current 4-addr AP_VLAN behaviour? It seems with that
you could actually implement a bound-to-AP-WDS entirely in userspace
since there's no requirement to actually go through the auth/assoc
sequence for hostapd to add the station entry?

johannes