On 2011-09-20 10:18 PM, Luis R. Rodriguez wrote:
On Tue, Sep 20, 2011 at 12:31 PM, Felix Fietkau<nbd@xxxxxxxxxxx> wrote:
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.
How about verifying that HT40 primary, secondary channel pair is
allowed per as IEEE 802.11n Annex J on each peer? In the AP case we do
this centrally, but for IBSS and Mesh, does each peer have to go on
and do the check? If each peer does the check, and change settings,
how do we go about changing the configuration of the established HT
configuration? Where will this code go? Currently this goes into
hostapd for APs.
This is not really an IBSS specific issue. It applies to WDS or monitor
mode as well. If we want to properly enforce Annex J channel pairs, this
needs to be moved to cfg80211.
- 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
