On 2011-09-20 8:38 PM, Luis R. Rodriguez wrote:
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.
Simply sticking with the configured HT opmode is also simple, but it's a
lot more practical.
- Felix
--
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
