From: Johannes Berg <johannes@sipsolutions.net>
To: Alexander Simon <alexander.simon@saxnet.de>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [PATCH 4/4] mac80211: Add HT operation modes for IBSS
Date: Fri, 12 Aug 2011 14:35:36 +0200 [thread overview]
Message-ID: <1313152536.4022.9.camel@jlt3.sipsolutions.net> (raw)
In-Reply-To: <1312990268.3128.22.camel@alex-2> (sfid-20110810_173144_123158_1479ED2B)
On Wed, 2011-08-10 at 17:31 +0200, Alexander Simon wrote:
> In short: The HT parameter shall behave similar to the frequency:
> Non-fixed mode: Only used when starting an IBSS or starting HT in an
> non-IBSS.
> Fixed mode: Only join when HT modes match.
Ok, that makes sense. So you need the get_bss_ht() only for fixed mode I
guess.
> This should answer your last questions:
> When not fixed, the BSSID configuration always is preferred. Thus, we
> would join as HT40 even though not requested.
> So, when we requsted HT40-, but the IBSS is HT40+, we would work on -.
? I think I know what you mean but your example seems .. the wrong way
around?
> I wanted to have the opportunity to start HT on an existing IBSS.
Well that should always be OK?
> The problem is that legacy station may "kill" the HT configuration:
> If STA A starts in HT IBSS and lets say Windows STA B joins, B would
> advertise that IBSS as non-HT as it ignores our HT IE.
> Then, if STA A dies and STA C joins, it will be non-HT.
mac80211 is STA C? Would it be a problem to use HT if the IBSS was
previously non-HT? The old members will ignore it, but other new HT
members may work OK? IOW -- is it not possible to have a mixed HT/non-HT
IBSS?
> No, pretty sure not. We *are* already joined. That means the TSFs of all
> stations *within* our BSSID match. TSFs can only tell whitch BSSID is
> older...
> So there is no way to distinguish which station first joined.
> Or am i wrong? That would be good in that case :)
Oh, no, you're right of course.
johannes
next prev parent reply other threads:[~2011-08-12 12:35 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-08 12:02 [PATCH 1/4] nl80211: Parse channel type attribute in an IBSS join request Alexander Simon
2011-08-08 12:04 ` [PATCH 2/4] cfg80211: Add cfg80211_get_bss_ht to also match HT configuration Alexander Simon
2011-08-10 13:53 ` Johannes Berg
2011-08-10 15:48 ` Alexander Simon
2011-08-10 16:05 ` Johannes Berg
2011-08-10 17:50 ` Alexander Simon
2011-08-12 12:32 ` Johannes Berg
2011-08-12 14:20 ` Alexander Simon
2011-08-08 12:09 ` [PATCH 3/4] mac80211: Add HT helper functions Alexander Simon
2011-08-10 13:54 ` Johannes Berg
2011-08-10 13:55 ` Johannes Berg
2011-08-08 12:10 ` [PATCH 4/4] mac80211: Add HT operation modes for IBSS Alexander Simon
2011-08-10 14:03 ` Johannes Berg
2011-08-10 15:31 ` Alexander Simon
2011-08-12 12:35 ` Johannes Berg [this message]
2011-08-12 14:25 ` Alexander Simon
2011-08-13 16:05 ` Felix Fietkau
2011-08-10 13:50 ` [PATCH 1/4] nl80211: Parse channel type attribute in an IBSS join request Johannes Berg
2011-08-23 19:39 ` John W. Linville
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1313152536.4022.9.camel@jlt3.sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=alexander.simon@saxnet.de \
--cc=linux-wireless@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).