From: Ben Greear <greearb@candelatech.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: linux-wireless@vger.kernel.org
Subject: Re: Multiple vifs and HT v/s non-HT.
Date: Fri, 28 Jan 2011 09:11:47 -0800 [thread overview]
Message-ID: <4D42F8D3.6090806@candelatech.com> (raw)
In-Reply-To: <1296220663.5118.0.camel@jlt3.sipsolutions.net>
On 01/28/2011 05:17 AM, Johannes Berg wrote:
> On Thu, 2011-01-27 at 15:07 -0800, Ben Greear wrote:
>> We found something fun while playing with HT mode:
>>
>> We had some vifs associated with an AP with HT enabled,
>> and other VIFS to an AP with HT disabled.
>>
>> They managed to associate, but with slow rates and
>> for whatever reason, nothing is able to send traffic.
>> I would have expected one set or the other would
>> be able to send traffic.
>>
>> The ath9k hardware ended up in HT mode according to
>> ath9k debugfs wiphy file, but that was probably
>> just luck.
>>
>> I'm not too sure how to ensure this mixed-mode HT
>> scenario doesn't happen at this point...
>
> So that patch you sent addressed this?
Well, I could no longer (easily?) reproduce the problem,
but to be honest, I don't see how my changes could have fixed
the problem that I saw. I still think that patch is useful
and could fix other problems, however.
I ran 30 STAs w/out HT and 30 with all night, about 175kbps UDP tx + rx on
each interface, and it ran OK.
But, there may still be issues/races with initial setup and state transitions.
At the least, the set-channel-type method should do WARN_ON_ONCE
instead of WARN_ON if you have HT40+ on some VIFs and HT40-
on others. I was also thinking that the first vif(s) to associate
on a channel-type should win..and just fail to set the channel type
to something invalid (ie, ht40- -> ht40+) in that case. Otherwise,
I think you would get endless flapping.
Thanks,
Ben
>
> johannes
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
prev parent reply other threads:[~2011-01-28 17:11 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-27 23:07 Multiple vifs and HT v/s non-HT Ben Greear
2011-01-28 13:17 ` Johannes Berg
2011-01-28 17:11 ` Ben Greear [this message]
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=4D42F8D3.6090806@candelatech.com \
--to=greearb@candelatech.com \
--cc=johannes@sipsolutions.net \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.