From: Sascha Silbe <sascha-ml-reply-to-2011-2@silbe.org>
To: Dan Williams <dcbw@redhat.com>
Cc: linux-wireless <linux-wireless@vger.kernel.org>,
devel <devel@lists.laptop.org>,
John@xo15-sascha.sascha.silbe.org,
W.Linville@xo15-sascha.sascha.silbe.org, <linville@tuxdriver.com>,
libertas-dev <libertas-dev@lists.infradead.org>,
netdev <netdev@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Add libertas_disablemesh module parameter to disable mesh interface
Date: Fri, 13 May 2011 15:16:31 +0200 [thread overview]
Message-ID: <1305290935-sup-4547@xo15-sascha.sascha.silbe.org> (raw)
In-Reply-To: <1305169898.8054.19.camel@dcbw.foobar.com>
[-- Attachment #1: Type: text/plain, Size: 1672 bytes --]
Excerpts from Dan Williams's message of Thu May 12 05:11:36 +0200 2011:
> On Wed, 2011-05-11 at 14:52 +0200, Sascha Silbe wrote:
> > This allows individual users and deployments to disable mesh support at
> > runtime, i.e. without having to build and maintain a custom kernel.
> Does the mesh interface somehow cause problems, even when nothing is
> using it?
Some people suspect it does, but there's no hard data showing that. But
then the problems are often hard to reproduce in the first place, so
proving a correlation with mesh is even harder.
The hardware based mesh support is based on an outdated draft of
802.11s and not interoperable with any other device AFAIK. For most
users Ad-hoc networks are the better option. Disabling mesh support as
low-level as possible makes it less likely that any remains are causing
trouble. With at least four layers (firmware, kernel, NM, Sugar)
involved in managing connectivity and one of the (firmware) being closed
source, I prefer to simplify things by eliminating three layers for
functionality we don't intend to use. It makes debugging (and
blaming ;) ) a lot easier.
In the field, mesh support is currently disabled using
/sys/class/net/eth0/lbs_mesh. However, it comes back after resume
(possibly only if powercycled) and needs to be disabled again by
post-resume hacks. Race conditions with NM are possible.
A user space option would be to teach NM to disable mesh support (at
runtime - we don't want to ship a custom NM package). I'd expect the
patch to be much more invasive than the one posted for libertas.
Sascha
--
http://sascha.silbe.org/
http://www.infra-silbe.de/
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 494 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Sascha Silbe <silbe@activitycentral.com>
To: Dan Williams <dcbw@redhat.com>
Cc: linux-wireless <linux-wireless@vger.kernel.org>,
devel <devel@lists.laptop.org>,
John@xo15-sascha.sascha.silbe.org,
W.Linville@xo15-sascha.sascha.silbe.org, <linville@tuxdriver.com>,
libertas-dev <libertas-dev@lists.infradead.org>,
netdev <netdev@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Add libertas_disablemesh module parameter to disable mesh interface
Date: Fri, 13 May 2011 15:16:31 +0200 [thread overview]
Message-ID: <1305290935-sup-4547@xo15-sascha.sascha.silbe.org> (raw)
In-Reply-To: <1305169898.8054.19.camel@dcbw.foobar.com>
[-- Attachment #1: Type: text/plain, Size: 1672 bytes --]
Excerpts from Dan Williams's message of Thu May 12 05:11:36 +0200 2011:
> On Wed, 2011-05-11 at 14:52 +0200, Sascha Silbe wrote:
> > This allows individual users and deployments to disable mesh support at
> > runtime, i.e. without having to build and maintain a custom kernel.
> Does the mesh interface somehow cause problems, even when nothing is
> using it?
Some people suspect it does, but there's no hard data showing that. But
then the problems are often hard to reproduce in the first place, so
proving a correlation with mesh is even harder.
The hardware based mesh support is based on an outdated draft of
802.11s and not interoperable with any other device AFAIK. For most
users Ad-hoc networks are the better option. Disabling mesh support as
low-level as possible makes it less likely that any remains are causing
trouble. With at least four layers (firmware, kernel, NM, Sugar)
involved in managing connectivity and one of the (firmware) being closed
source, I prefer to simplify things by eliminating three layers for
functionality we don't intend to use. It makes debugging (and
blaming ;) ) a lot easier.
In the field, mesh support is currently disabled using
/sys/class/net/eth0/lbs_mesh. However, it comes back after resume
(possibly only if powercycled) and needs to be disabled again by
post-resume hacks. Race conditions with NM are possible.
A user space option would be to teach NM to disable mesh support (at
runtime - we don't want to ship a custom NM package). I'd expect the
patch to be much more invasive than the one posted for libertas.
Sascha
--
http://sascha.silbe.org/
http://www.infra-silbe.de/
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 494 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Sascha Silbe <sascha-ml-reply-to-2011-2@silbe.org>
To: Dan Williams <dcbw@redhat.com>
Cc: libertas-dev <libertas-dev@lists.infradead.org>,
netdev <netdev@vger.kernel.org>,
John@xo15-sascha.sascha.silbe.org,
linux-wireless <linux-wireless@vger.kernel.org>,
linville@tuxdriver.com,
linux-kernel <linux-kernel@vger.kernel.org>,
W.Linville@xo15-sascha.sascha.silbe.org,
devel <devel@lists.laptop.org>
Subject: Re: [PATCH] Add libertas_disablemesh module parameter to disable mesh interface
Date: Fri, 13 May 2011 15:16:31 +0200 [thread overview]
Message-ID: <1305290935-sup-4547@xo15-sascha.sascha.silbe.org> (raw)
In-Reply-To: <1305169898.8054.19.camel@dcbw.foobar.com>
[-- Attachment #1.1: Type: text/plain, Size: 1672 bytes --]
Excerpts from Dan Williams's message of Thu May 12 05:11:36 +0200 2011:
> On Wed, 2011-05-11 at 14:52 +0200, Sascha Silbe wrote:
> > This allows individual users and deployments to disable mesh support at
> > runtime, i.e. without having to build and maintain a custom kernel.
> Does the mesh interface somehow cause problems, even when nothing is
> using it?
Some people suspect it does, but there's no hard data showing that. But
then the problems are often hard to reproduce in the first place, so
proving a correlation with mesh is even harder.
The hardware based mesh support is based on an outdated draft of
802.11s and not interoperable with any other device AFAIK. For most
users Ad-hoc networks are the better option. Disabling mesh support as
low-level as possible makes it less likely that any remains are causing
trouble. With at least four layers (firmware, kernel, NM, Sugar)
involved in managing connectivity and one of the (firmware) being closed
source, I prefer to simplify things by eliminating three layers for
functionality we don't intend to use. It makes debugging (and
blaming ;) ) a lot easier.
In the field, mesh support is currently disabled using
/sys/class/net/eth0/lbs_mesh. However, it comes back after resume
(possibly only if powercycled) and needs to be disabled again by
post-resume hacks. Race conditions with NM are possible.
A user space option would be to teach NM to disable mesh support (at
runtime - we don't want to ship a custom NM package). I'd expect the
patch to be much more invasive than the one posted for libertas.
Sascha
--
http://sascha.silbe.org/
http://www.infra-silbe.de/
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 494 bytes --]
[-- Attachment #2: Type: text/plain, Size: 129 bytes --]
_______________________________________________
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
next prev parent reply other threads:[~2011-05-13 13:23 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-11 12:52 [PATCH] Add libertas_disablemesh module parameter to disable mesh interface Sascha Silbe
2011-05-11 12:52 ` Sascha Silbe
2011-05-11 17:00 ` Randy Dunlap
2011-05-13 13:26 ` Sascha Silbe
2011-05-13 13:26 ` Sascha Silbe
2011-05-13 13:26 ` Sascha Silbe
2011-05-12 3:11 ` Dan Williams
2011-05-13 13:16 ` Sascha Silbe [this message]
2011-05-13 13:16 ` Sascha Silbe
2011-05-13 13:16 ` Sascha Silbe
2011-05-19 17:16 ` Dan Williams
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=1305290935-sup-4547@xo15-sascha.sascha.silbe.org \
--to=sascha-ml-reply-to-2011-2@silbe.org \
--cc=John@xo15-sascha.sascha.silbe.org \
--cc=W.Linville@xo15-sascha.sascha.silbe.org \
--cc=dcbw@redhat.com \
--cc=devel@lists.laptop.org \
--cc=libertas-dev@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=netdev@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.