From: Bruno Randolf <br1@einfach.org>
To: Ben Greear <greearb@candelatech.com>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [PATCH] ath5k: vif adhoc fixup
Date: Thu, 30 Sep 2010 10:46:50 +0900 [thread overview]
Message-ID: <201009301046.50288.br1@einfach.org> (raw)
In-Reply-To: <4CA36D14.9080400@candelatech.com>
On Thu September 30 2010 01:45:08 Ben Greear wrote:
> > i made these changes on top of your v7 patch, please tell me what you
> > think! and feel free to merge the changes into your patch, if you agree
> > with them.
>
> I'll merge them in and do some quick testing and re-post the full
> patch.
thanks!
> For STAs, I use the can-scan-one logic so that after the first interface
> associates, future automated scans will not scan more than the single
> channel. That helps keep us on the same channel.
>
> But, if all interfaces disassociate, then full scans will happen again,
> and the first interface to associate gets to choose the channel.
>
> If the channel is changed for any reason, all of the old stations are
> un-associated and attempt full rescan to re-associate.
>
> That scan-one logic is probably not going into the upstream kernel though,
> so to keep confusion to a minimum, you would have to make sure that
> your STAs are all configured for APs on the same channel.
that makes sense.
> In general, APs and STAs have worked well together for us..but we have
> never used adhoc. It sounds to me like you know a lot more about this
> stuff than I do, so perhaps you can make more progress.
maybe, but i'm not sure if i can spend much time on this. as i said i'm fine
as long as one ad-hoc interface per device works and if we can have multiple
AP interfaces on another device.
if someone is interested in ad-hoc + STA or ad-hoc + AP interfaces, basically
we would need to test:
- can we have the HW in ad-hoc mode and still have AP interfaces?
- can we have the HW in ad-hoc mode and still have STA interfaces?
- if that's not possible, there have been patches for madwifi, which runs ad-
hoc interfaces with the hardware configured in AP mode, but this has some
disadvantages (like no TSF sync, no beacon backoff).
i'm not sure if we should disable ad-hoc + other interfaces in the mean time
or leave it open for others to test??? maybe i can give it a short try today?
> If we can get agreement on the patch as is (with your changes included),
> I'd love to get it pushed upstream. Then folks can improve it further.
sure. i tested v7 + my changes for the last 12 hours, using 2 WPA and 2 non-
encrypted AP interfaces with concurrent iperf traffic and ping without
problems. one ad-hoc interface works as well. i think the problems i saw last
time were due to dupliacte mac addresses. so i'll checkout your v8 patch and
then let's see to get it merged! :)
bruno
prev parent reply other threads:[~2010-09-30 1:47 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-29 9:22 [PATCH] ath5k: vif adhoc fixup Bruno Randolf
2010-09-29 16:45 ` Ben Greear
2010-09-30 1:46 ` Bruno Randolf [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=201009301046.50288.br1@einfach.org \
--to=br1@einfach.org \
--cc=greearb@candelatech.com \
--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).