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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
