On 2011-09-20 9:05 PM, Luis R. Rodriguez wrote:
On Tue, Sep 20, 2011 at 11:46 AM, Felix Fietkau<nbd@xxxxxxxxxxx> wrote:
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.
Just need to deal with the complexity, the complexity question is
where do we handle this, verifying it respects the standard, and
actually getting the work done. With AP mode of operation hostapd
already does all this for us so if we want to support IBSS and Mesh
without hostapd we'd need to figure out where to stuff this code. In
the long run this would need to be resolved for both IBSS and Mesh. We
can wait for all this work to get done or get a simple taste of basic
HT support for both modes by sticking to the supported HT mode based
on the observed beacons.
HT capabilities are already handled properly, the main issue is handling
the HT opmode. For that, the only important bit is whether we're using
HT40+, HT40- or HT20. The code can easily just fall back to HT20 when
the HT opmode of the peer is incompatible with the local HT opmode.
- 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
