public inbox for linux-wireless@vger.kernel.org
 help / color / mirror / Atom feed
From: Simon Raffeiner <sturmflut@lieberbiber.de>
To: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
Cc: Andrey Yurovsky <andrey@cozybit.com>,
	linux-wireless@vger.kernel.org, johannes@sipsolutions.net
Subject: Re: [PATCH] nl80211: allow adding new station to devices in mesh mode
Date: Fri, 5 Feb 2010 20:04:06 +0100	[thread overview]
Message-ID: <201002052004.06220.sturmflut@lieberbiber.de> (raw)
In-Reply-To: <20100205175556.GC1496@holoscopio.com>

Am Freitag, 5. Februar 2010 18:55:56 schrieb Thadeu Lima de Souza Cascardo:

> I did not get automatic plinks for a peer.

The last time that happened I was using different checkouts of wireless-testing 
on both nodes and somebody had changed the code to match a new draft version 
in between.

And the one time before that there was a bug in the ath5k code, effectively 
preventing the device from beaconing.


> I want automatic plinks to work. But since I've started to play with it,
> why not make the command just work. It's there. If adding plinks
> manually to mesh nodes is not permitted, I may just send another patch,
> disallowing it entirely and making it explicit in code, comment and git
> log.

If I'm not mistaken the draft standard says that every node has to actively or 
passively scan for neighbors and automatically select candidate peers. A 
candidate peer has to announce a profile (Mesh Information Element) in its 
beacons that matches the local profile.

If manual addition of plinks is allowed you could theoretically force your 
node to peer with a neighbor running a different profile, e.g. using a different 
path selection or authentication algorithm, or an implementation based on a 
different draft version.

I can't really think of an use for it.

Just my 0.01$.

regards
Simon Raffeiner

  reply	other threads:[~2010-02-05 19:12 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 [this message]
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
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=201002052004.06220.sturmflut@lieberbiber.de \
    --to=sturmflut@lieberbiber.de \
    --cc=andrey@cozybit.com \
    --cc=cascardo@holoscopio.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox