On Tue, Sep 20, 2011 at 11:21 AM, Felix Fietkau <nbd@xxxxxxxxxxx> wrote: >>> 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. For mesh, my initial thought was to allow mismatched peerings according to the following rules: 1. Peering is allowed between non-HT STAs as well as between HT and non-HT STAs. No HT checks in that case. 2. If both peer candidates support HT, only allow peering if they advertise the same BSSBasicMCSSet in their HT Operation IE. This ensures that a basic link can be established between these stations. 3. Don't use the HT info for anything else: if there are poorly matched HT links, let the path selection algorithm try and find better ones (if there are any). I believe the above is compliant with 802.11s. Cheers, Javier -- 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
