From: Javier Cardona <javier@cozybit.com>
To: Felix Fietkau <nbd@openwrt.org>
Cc: "John W. Linville" <linville@tuxdriver.com>,
Thomas Pedersen <thomas@cozybit.com>,
devel@lists.open80211s.org,
Johannes Berg <johannes@sipsolutions.net>,
linux-wireless@vger.kernel.org, jlopex@gmail.com
Subject: Re: [PATCH 13/13] ath9k: fix beaconing for mesh interfaces
Date: Wed, 4 May 2011 10:13:56 -0700 [thread overview]
Message-ID: <BANLkTikOOvGfzV4YK6_0LWnF3jFQy-N0ig@mail.gmail.com> (raw)
In-Reply-To: <4DC165D7.50403@openwrt.org>
On Wed, May 4, 2011 at 7:42 AM, Felix Fietkau <nbd@openwrt.org> wrote:
> On 2011-05-04 1:57 AM, Javier Cardona wrote:
>>
>> Mesh beaconing on ath9k was broken by this commit:
>>
>> commit 4801416c76a3a355076d6d371c00270dfe332e1c
>> Author: Ben Greear<greearb@candelatech.com>
>> Date: Sat Jan 15 19:13:48 2011 +0000
>>
>> This patch assigns the right opmode when the device is used in mesh
>> mode.
>>
>> Reported-by: Fabrice Deyber fabricedeyber@agilemesh.com
>> Signed-off-by: Javier Cardona<javier@cozybit.com>
>
> Any idea why exactly ath9k needs to use this opmode? If I understand the
> specs correctly, 802.11s does not use distributed beacons like ad-hoc mode,
> so theoretically it should be fine with using the AP iftype.
> If beacons don't work at all in this opmode for 802.11s then this patch may
> just be covering up an underlying bug rather than fixing the real issue.
Older versions of the 11s draft let implementers decide whether mesh
nodes would beacon in ad-hoc or AP mode. Apparently on ath9k ad-hoc
mode was chosen when the earlier mesh draft was implemented.
The current version of the draft defines a different beaconing mode
specific for mesh. This is very unlikely to change since 11s has
already passed sponsor ballot. My suggestion would be to keep using
ad-hoc style beaconing in ath9k for mesh and to leave the opmode
around for when mesh-specific beaconing is implemented in the driver.
But I know little about ath9k. If someone can suggest a better way to
"unbreak" mesh beaconing I'll be equally happy.
Thanks!
Javier
next prev parent reply other threads:[~2011-05-04 17:14 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-03 23:57 Support for secure mesh in userspace and other mesh fixes Javier Cardona
2011-05-03 23:57 ` [PATCH 01/13] nl80211: Introduce NL80211_MESH_SETUP_USERSPACE_AMPE Javier Cardona
2011-05-04 12:27 ` Johannes Berg
2011-05-04 16:32 ` Javier Cardona
2011-05-04 16:34 ` Johannes Berg
2011-05-03 23:57 ` [PATCH 02/13] mac80211: Let userspace send action frames over mesh interfaces Javier Cardona
2011-05-03 23:57 ` [PATCH 03/13] mac80211: Drop MESH_PLINK category and use new ANA-approved MESH_ACTION Javier Cardona
2011-05-03 23:57 ` [PATCH 04/13] open80211s: Stop using zero for address 3 in mesh plink mgmt frames Javier Cardona
2011-05-04 12:57 ` Johannes Berg
2011-05-04 16:28 ` Javier Cardona
2011-05-04 17:24 ` [PATCH] cfg80211: Use capability info to detect mesh beacons Javier Cardona
2011-05-09 8:25 ` Johannes Berg
2011-05-30 10:51 ` Vivek Natarajan
2011-05-31 17:26 ` Javier Cardona
2011-05-31 18:10 ` Eliad Peller
2011-05-31 18:38 ` Javier Cardona
2011-06-01 7:01 ` Eliad Peller
2011-05-03 23:57 ` [PATCH 05/13] nl80211: Let userspace drive the peer link management states Javier Cardona
2011-05-04 12:28 ` Johannes Berg
2011-05-03 23:57 ` [PATCH 06/13] nl80211: allow installing keys for a meshif Javier Cardona
2011-05-03 23:57 ` [PATCH 07/13] nl80211: allow setting MFP flag " Javier Cardona
2011-05-03 23:57 ` [PATCH 08/13] mac80211: Self-protected management frames are not robust Javier Cardona
2011-05-03 23:57 ` [PATCH 09/13] Check size of a new mesh path table for changes since allocation Javier Cardona
2011-05-03 23:57 ` [PATCH 10/13] mac80211: Fix locking bug on mesh path table access Javier Cardona
2011-05-03 23:57 ` [PATCH 11/13] mac80211: Move call to mpp_path_lookup inside RCU-read section Javier Cardona
2011-05-03 23:57 ` [PATCH 12/13] mac80211: allow setting supported rates on mesh peers Javier Cardona
2011-05-03 23:57 ` [PATCH 13/13] ath9k: fix beaconing for mesh interfaces Javier Cardona
2011-05-04 14:42 ` Felix Fietkau
2011-05-04 16:16 ` Steve Brown
2011-05-04 17:13 ` Javier Cardona [this message]
2011-05-04 17:25 ` Johannes Berg
2011-05-04 17:31 ` Javier Cardona
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=BANLkTikOOvGfzV4YK6_0LWnF3jFQy-N0ig@mail.gmail.com \
--to=javier@cozybit.com \
--cc=devel@lists.open80211s.org \
--cc=jlopex@gmail.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=nbd@openwrt.org \
--cc=thomas@cozybit.com \
/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).