On Sun, 2012-08-05 at 19:21 +0200, Johannes Berg wrote: > 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? Oh and if you actually do need WDS-type interfaces, maybe their role should change to be virtual like AP_VLAN-type interfaces? 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
