On Tue, Sep 20, 2011 at 11:21 AM, Felix Fietkau <nbd@xxxxxxxxxxx> wrote: > On 2011-09-20 8:12 PM, Luis R. Rodriguez wrote: >> >> On Tue, Sep 20, 2011 at 5:21 AM, Johannes Berg >> <johannes@xxxxxxxxxxxxxxxx> wrote: >>> >>> On Mon, 2011-09-19 at 17:46 +0200, Alexander Simon wrote: >>> That seems pretty complex too ... >>> >>> I don't really know. As I said, I think I'd be happy with an >>> implementation that maybe doesn't fully implement everything as long as >>> it considers the trade-offs. >> >> The same questions come up with HT support and 802.11s, as per Javier >> this is not really well spelled out in the spec. My recommendation is >> to just support for now the most simple case and let us not entangle >> ourselves with the complexities of handling trying to merge different >> setups. So only enable peering up for adhoc or mesh if and only if the >> observed IE matches our own supported HT caps or target configuration. >> If a legacy STA tries to peer up with an HT IBSS, this would simply be >> rejected. We can leave off handling the change in configuration later >> for userspace, but do not see this as being a requirement for >> supporting HT for IBSS or Mesh. The simpler the better, so long as we >> simply respect the spec. > > I disagree. That'll make it useless for real deployments, which are often a > mix of HT and non-HT devices. I'm not saying to not do it at all, I'm saying to start off with basic support *first* and *later* worry about the mixing. Luis -- 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
