From: Javier Cardona <javier@cozybit.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>,
linux-wireless@vger.kernel.org,
Andrey Yurovsky <yurovsky@gmail.com>
Subject: Re: [PATCH] nl80211: allow adding new station to devices in mesh mode
Date: Mon, 8 Feb 2010 11:25:37 -0800 [thread overview]
Message-ID: <445f43ac1002081125i61bb53dap5b9df374b3116ba9@mail.gmail.com> (raw)
In-Reply-To: <1265620089.3783.2.camel@johannes.berg>
Thadeu, Johannes,
On Mon, Feb 8, 2010 at 1:08 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Sun, 2010-02-07 at 11:51 -0800, Andrey Yurovsky wrote:
>> On Sat, Feb 6, 2010 at 12:59 AM, Johannes Berg
>> <johannes@sipsolutions.net> wrote:
>> > I do wonder though, the commit (155cc9e4b1d60161ee53) I referenced was
>> > yours, and now you're asking the same question as I am -- "why even
>> > allow adding stations?"
>>
>> It was supported for automated testing and experimentation (you could
>> then force certain topologies). I can't think of any other reason to
>> do it. I suppose that the same thing goes for mpaths and the mesh
>> portal tables.
>
> So would you prefer to fix it (however we would do that, I don't think
> that the patch here is correct since it leaves the station struct with
> no usable rates afaict), or just disallow it?
After reviewing our mesh test suite, I would vote for disallowing mesh
point addition via iw. We currently force topologies by 1. turning
auto peering off, 2. waiting for neighbors to be discovered and 3.
controlling peering with 'iw ... station set <MAC address>
plink_action <open|block>'
Thadeu, would this approach work for you?
Javier
--
Javier Cardona
cozybit Inc.
http://www.cozybit.com
next prev parent reply other threads:[~2010-02-08 19:33 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-05 1:00 [PATCH] nl80211: allow adding new station to devices in mesh mode Thadeu Lima de Souza Cascardo
2010-02-05 9:39 ` Johannes Berg
2010-02-05 9:59 ` Johannes Berg
2010-02-05 16:57 ` Thadeu Lima de Souza Cascardo
2010-02-05 17:47 ` Andrey Yurovsky
2010-02-05 17:55 ` Thadeu Lima de Souza Cascardo
2010-02-05 19:04 ` Simon Raffeiner
2010-02-05 23:16 ` Andrey Yurovsky
2010-02-06 8:59 ` Johannes Berg
2010-02-07 19:51 ` Andrey Yurovsky
2010-02-08 9:08 ` Johannes Berg
2010-02-08 19:25 ` Javier Cardona [this message]
2010-02-08 20:26 ` Thadeu Lima de Souza Cascardo
2010-02-09 7:58 ` Johannes Berg
2010-02-08 13:54 ` Simon Raffeiner
2010-02-08 17:26 ` 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=445f43ac1002081125i61bb53dap5b9df374b3116ba9@mail.gmail.com \
--to=javier@cozybit.com \
--cc=cascardo@holoscopio.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=yurovsky@gmail.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