Search Linux Wireless

Re: [PATCH v3 3/3] mac80211: Add HT operation modes for IBSS

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

  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


[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux