LinuxLists.cc - [PATCH 17/19] [RFC, v2] libertas: Kconfig entry for libertas+cfg80211

[permalink] [raw]

Subject: Re: [PATCH 17/19] [RFC, v2] libertas: Kconfig entry for libertas+cfg80211

> Which should allow us to use cfg80211 by default, and then have
> only the LIBERTAS_MESH Kconfig option depend on WEXT. Maybe?

That would be a good idea. I always thought about a LIBERTAS_MESH
Kconfig right after persistcfg.c was added :-)

--
http://www.holgerschurig.de

2009-10-23 16:31:40

[permalink] [raw]

Subject: Re: [PATCH 17/19] [RFC, v2] libertas: Kconfig entry for libertas+cfg80211

On Fri, 2009-10-23 at 09:28 -0700, Dan Williams wrote:
> On Fri, 2009-10-23 at 18:04 +0200, Johannes Berg wrote:
> > On Fri, 2009-10-23 at 08:49 -0700, Dan Williams wrote:
> >
> > > > - (iw_handler) lbs_set_freq, /* SIOCSIWFREQ */
> > > > + (iw_handler) cfg80211_wext_siwfreq,
> > > >
> > > > etc.
> > > >
> > > > That's why those exist and are exported. And that way you don't need the
> > > > Kconfig at all, and can remove most of the wext code.
> > >
> > > I *think* because Holger is trying to keep WEXT around for a bit,
> > > because cfg80211 won't be mature enough yet (IMHO, I could be wrong) by
> > > 2.6.33, and because it doesn't support the OLPC-style mesh stuff and the
> > > libertas monitor interface code. There's a few loose-ends that need to
> > > be tied up before a cfg80211 conversion would completely replace the
> > > functionality of the WEXT code.
> >
> > I just don't understand why he thinks that wext and cfg80211 need to be
> > mutually exclusive. cfg80211 has exported its handlers for exactly this
> > purpose, so that you could have everything that cfg80211 supports via
> > it, and everything else directly.
>
> I thought about it more, and I think we can go all cfg80211 with a small
> WEXT handler for the mesh bits (it only cares about 4 of the WEXT
> operations and redirected the rest to the STA interface handlers). The
> mesh stuff is actually quite simple operationally.

Which should allow us to use cfg80211 by default, and then have only the
LIBERTAS_MESH Kconfig option depend on WEXT. Maybe?

Dan

2009-10-23 16:29:03

[permalink] [raw]

Subject: Re: [PATCH 17/19] [RFC, v2] libertas: Kconfig entry for libertas+cfg80211

On Fri, 2009-10-23 at 18:04 +0200, Johannes Berg wrote:
> On Fri, 2009-10-23 at 08:49 -0700, Dan Williams wrote:
>
> > > - (iw_handler) lbs_set_freq, /* SIOCSIWFREQ */
> > > + (iw_handler) cfg80211_wext_siwfreq,
> > >
> > > etc.
> > >
> > > That's why those exist and are exported. And that way you don't need the
> > > Kconfig at all, and can remove most of the wext code.
> >
> > I *think* because Holger is trying to keep WEXT around for a bit,
> > because cfg80211 won't be mature enough yet (IMHO, I could be wrong) by
> > 2.6.33, and because it doesn't support the OLPC-style mesh stuff and the
> > libertas monitor interface code. There's a few loose-ends that need to
> > be tied up before a cfg80211 conversion would completely replace the
> > functionality of the WEXT code.
>
> I just don't understand why he thinks that wext and cfg80211 need to be
> mutually exclusive. cfg80211 has exported its handlers for exactly this
> purpose, so that you could have everything that cfg80211 supports via
> it, and everything else directly.

I thought about it more, and I think we can go all cfg80211 with a small
WEXT handler for the mesh bits (it only cares about 4 of the WEXT
operations and redirected the rest to the STA interface handlers). The
mesh stuff is actually quite simple operationally.

Dan

2009-10-23 15:49:58

[permalink] [raw]

Subject: Re: [PATCH 17/19] [RFC, v2] libertas: Kconfig entry for libertas+cfg80211

On Fri, 2009-10-23 at 16:19 +0200, Johannes Berg wrote:
> On Thu, 2009-10-22 at 15:31 +0200, Holger Schurig wrote:
>
> > +#ifdef CONFIG_LIBERTAS_WEXT
> > dev->ethtool_ops = &lbs_ethtool_ops;
> > dev->wireless_handlers = &lbs_handler_def;
> > #endif
>
> So here you make the wireless_handlers optional.
>
> I still don't understand why you can't just replace only some of the
> handlers, i.e. instead of doing this, simply do
>
> - (iw_handler) lbs_set_freq, /* SIOCSIWFREQ */
> + (iw_handler) cfg80211_wext_siwfreq,
>
> etc.
>
> That's why those exist and are exported. And that way you don't need the
> Kconfig at all, and can remove most of the wext code.

I *think* because Holger is trying to keep WEXT around for a bit,
because cfg80211 won't be mature enough yet (IMHO, I could be wrong) by
2.6.33, and because it doesn't support the OLPC-style mesh stuff and the
libertas monitor interface code. There's a few loose-ends that need to
be tied up before a cfg80211 conversion would completely replace the
functionality of the WEXT code.

Dan

2009-10-23 16:30:22

[permalink] [raw]

Subject: Re: [PATCH 17/19] [RFC, v2] libertas: Kconfig entry for libertas+cfg80211

On Fri, 2009-10-23 at 17:56 +0200, Holger Schurig wrote:
> On Friday 23 October 2009 16:19:31 Johannes Berg wrote:
> > On Thu, 2009-10-22 at 15:31 +0200, Holger Schurig wrote:
> >
> > > +#ifdef CONFIG_LIBERTAS_WEXT
> > > dev->ethtool_ops = &lbs_ethtool_ops;
> > > dev->wireless_handlers = &lbs_handler_def;
> > > #endif
> >
> > So here you make the wireless_handlers optional.
> >
> > I still don't understand why you can't just replace only some
> of the
> > handlers, i.e. instead of doing this, simply do
> >
> > - (iw_handler) lbs_set_freq, /* SIOCSIWFREQ */
> > + (iw_handler) cfg80211_wext_siwfreq,
> >
> > etc.
> >
> > That's why those exist and are exported. And that way you don't
> > need the Kconfig at all, and can remove most of the wext code.
>
> The Kconfig has *NOTHING* to do with mesh.
>
> MESH should be implemented via add_virtual_intf() /
> change_virtual_intf(). This code isn't there yet, mesh_dev is
> always NULL in the CONFIG_LIBERTAS_CFG80211 case, so there's no
> need to export anything to ethtool or WEXT.
>
> And having cfg80211 + (mesh_dev != NULL) is something that
> I cannot program, due to (sigh) missing hardware, time,
> testing ability. Repeat rinse wash, repeat rinse wash ...
>
>
> Okay, I now stop talking about this. Please talk with Dan about
> the matter. He knows cfg80211 and libertas probably better than
> I. Once you two have found a decision, I'm looking if I'm still
> interested.

Please keep going :) At this point, you likely understand cfg80211
better than I do. And as I"ve commented in a few other mails this
morning, I don't think it'll be as complex as I thought it was earlier.

Dan

2009-10-23 16:04:13

[permalink] [raw]

Subject: Re: [PATCH 17/19] [RFC, v2] libertas: Kconfig entry for libertas+cfg80211

On Fri, 2009-10-23 at 08:49 -0700, Dan Williams wrote:

> > - (iw_handler) lbs_set_freq, /* SIOCSIWFREQ */
> > + (iw_handler) cfg80211_wext_siwfreq,
> >
> > etc.
> >
> > That's why those exist and are exported. And that way you don't need the
> > Kconfig at all, and can remove most of the wext code.
>
> I *think* because Holger is trying to keep WEXT around for a bit,
> because cfg80211 won't be mature enough yet (IMHO, I could be wrong) by
> 2.6.33, and because it doesn't support the OLPC-style mesh stuff and the
> libertas monitor interface code. There's a few loose-ends that need to
> be tied up before a cfg80211 conversion would completely replace the
> functionality of the WEXT code.

I just don't understand why he thinks that wext and cfg80211 need to be
mutually exclusive. cfg80211 has exported its handlers for exactly this
purpose, so that you could have everything that cfg80211 supports via
it, and everything else directly.

johannes

Attachments:

signature.asc (801.00 B)
This is a digitally signed message part

2009-10-26 20:16:45

[permalink] [raw]

Subject: Re: [PATCH 17/19] [RFC, v2] libertas: Kconfig entry for libertas+cfg80211

On Mon, 2009-10-26 at 09:04 +0100, Holger Schurig wrote:
> > How much does mesh actually get used? AFAICS it's a
> > OLPC-specific one off.
>
> A good question, I don't know no-one that uses mesh outside of
> OLPC.

Nobody uses the custom libertas mesh stuff outside OLPC. I tend to look
at it as just not being a dick, subject to the limitations of testing
ability. Obviously OLPC are the only ones who can do in-depth testing
of mesh-related changes since those of us outside OLPC only have a few
OLPCs/dongles to mesh together.

>
> > So unless OLPC people come up and fix it why do people even
> > bother with it?
>
> In some way the OLPC people won't be bothered, they don't
> follow linux-git or linux-wireless, they are stuck to some
> old kernel (2.6.25 AFAIK). So they don't even notice :-)

Actually untrue; the *shipping* products are still at 2.6.25, but there
are fairly recent kernel trees, especially for the G1.5 machines (which
admittedly don't have the mesh capability anyway, but they do use the
Libertas sd8686).

> However, they need MESH, so if I now rip MESH out completely
> just because I change some configuration API, that would
> bring more burden to them.

Yeah, I don't think it's normal practice in kernel drivers to just rip
something out that we know people are using, we at least put in a modest
amount of effort to not break it completely. At least basic sanity
testing of mesh start/stop, and if possible, meshing two machines
together with static IP and making sure they can ping each other. More
extensive testing needs to be done by the organization set up for that.

Dan

2009-10-25 03:38:54

by Christoph Hellwig

[permalink] [raw]

Subject: Re: [PATCH 17/19] [RFC, v2] libertas: Kconfig entry for libertas+cfg80211

How much does mesh actually get used? AFAICS it's a OLPC-specific one
off. So unless OLPC people come up and fix it why do people even bother
with it?

2009-10-23 16:48:59

[permalink] [raw]

Subject: Re: [PATCH 17/19] [RFC, v2] libertas: Kconfig entry for libertas+cfg80211

On Fri, 2009-10-23 at 09:42 -0700, Dan Williams wrote:

> Yeah, I think it's best to handle the mesh WEXT ioctls separately for
> now. There are really only 4 of them (get/set SSID, set channel, get
> mode) that matter for mesh. The rest of the ioctls that the mesh
> interface supports get redirected to the cfg80211 handlers because they
> aren't specific to mesh.

So why can't we simply do

set_ssid()
{
if (mesh)
return mesh_set_ssid();
else
return cfg80211_wext_iwessid()
}

johannes

Attachments:

signature.asc (801.00 B)
This is a digitally signed message part

2009-10-26 08:04:40

[permalink] [raw]

Subject: Re: [PATCH 17/19] [RFC, v2] libertas: Kconfig entry for libertas+cfg80211

> How much does mesh actually get used? AFAICS it's a
> OLPC-specific one off.

A good question, I don't know no-one that uses mesh outside of
OLPC.

> So unless OLPC people come up and fix it why do people even
> bother with it?

In some way the OLPC people won't be bothered, they don't
follow linux-git or linux-wireless, they are stuck to some
old kernel (2.6.25 AFAIK). So they don't even notice :-)

However, they need MESH, so if I now rip MESH out completely
just because I change some configuration API, that would
bring more burden to them.

--
http://www.holgerschurig.de

2009-10-23 14:19:32

[permalink] [raw]

Subject: Re: [PATCH 17/19] [RFC, v2] libertas: Kconfig entry for libertas+cfg80211

On Thu, 2009-10-22 at 15:31 +0200, Holger Schurig wrote:

> +#ifdef CONFIG_LIBERTAS_WEXT
> dev->ethtool_ops = &lbs_ethtool_ops;
> dev->wireless_handlers = &lbs_handler_def;
> #endif

So here you make the wireless_handlers optional.

I still don't understand why you can't just replace only some of the
handlers, i.e. instead of doing this, simply do

- (iw_handler) lbs_set_freq, /* SIOCSIWFREQ */
+ (iw_handler) cfg80211_wext_siwfreq,

etc.

That's why those exist and are exported. And that way you don't need the
Kconfig at all, and can remove most of the wext code.

johannes

Attachments:

signature.asc (801.00 B)
This is a digitally signed message part

2009-10-23 15:57:12

[permalink] [raw]

Subject: Re: [PATCH 17/19] [RFC, v2] libertas: Kconfig entry for libertas+cfg80211

On Friday 23 October 2009 16:19:31 Johannes Berg wrote:
> On Thu, 2009-10-22 at 15:31 +0200, Holger Schurig wrote:
>
> > +#ifdef CONFIG_LIBERTAS_WEXT
> > dev->ethtool_ops = &lbs_ethtool_ops;
> > dev->wireless_handlers = &lbs_handler_def;
> > #endif
>
> So here you make the wireless_handlers optional.
>
> I still don't understand why you can't just replace only some
of the
> handlers, i.e. instead of doing this, simply do
>
> - (iw_handler) lbs_set_freq, /* SIOCSIWFREQ */
> + (iw_handler) cfg80211_wext_siwfreq,
>
> etc.
>
> That's why those exist and are exported. And that way you don't
> need the Kconfig at all, and can remove most of the wext code.

The Kconfig has *NOTHING* to do with mesh.

MESH should be implemented via add_virtual_intf() /
change_virtual_intf(). This code isn't there yet, mesh_dev is
always NULL in the CONFIG_LIBERTAS_CFG80211 case, so there's no
need to export anything to ethtool or WEXT.

And having cfg80211 + (mesh_dev != NULL) is something that
I cannot program, due to (sigh) missing hardware, time,
testing ability. Repeat rinse wash, repeat rinse wash ...

Okay, I now stop talking about this. Please talk with Dan about
the matter. He knows cfg80211 and libertas probably better than
I. Once you two have found a decision, I'm looking if I'm still
interested.

--
http://www.holgerschurig.de

2009-10-26 20:12:59

[permalink] [raw]

Subject: Re: [PATCH 17/19] [RFC, v2] libertas: Kconfig entry for libertas+cfg80211

On Mon, 2009-10-26 at 08:59 +0100, Holger Schurig wrote:
> > > Well if you want to push the mesh wext bits through to cfg80211
> > > (temporarily) you wouldn't even need to depend on WEXT. I'd prefer,
> > > however, to not do this, and just use the cfg80211 wext handlers in
> > > libertas and depend on WEXT for now.
> >
> > Yeah, I think it's best to handle the mesh WEXT ioctls separately for
> > now. There are really only 4 of them (get/set SSID, set channel, get
> > mode) that matter for mesh. The rest of the ioctls that the mesh
> > interface supports get redirected to the cfg80211 handlers because they
> > aren't specific to mesh.
>
> We can reduce this to 3, because get/set channel could
> simply go via cfg80211.
>
> I'm unsure if we still need an GIWRANGE for mesh, but probably not.

Hmm, probably not. I think everything is the same between the mesh
interface and STA here, but not sure.

In any case, the code for the mesh channel change was different than the
code for the STA channel change, we have to be a bit careful here. The
sequences were:

STA:

1) get current channel #
2) issue a MESH_STOP command with the old channel
3) change the channel
4) resend WEP keys to firmware if any
5) restart adhoc if adhoc is enabled

mesh:

1) if STA is active and in infrastructure, deauth from AP
2) if STA is active and in adhoc, issue ADHOC_STOP
3) issue MESH_START with new channel

There are a few holes in the current implementation since desired
behavior is somewhat undefined; for example, if you change the mesh
channel, should an active adhoc network on the STA interface *restart*
on the new channel, or should the adhoc network on the old channel just
be torn down? If you change the mesh channel and the STA interface is
associated to an AP, should the STA interface try to re-associate to
that SSID on the new channel, or should it just stop?

In the end, we decided to keep it simple and require userspace to know a
bit about what was going on, which is reasonable, and thus if userspace
makes the choice to change mesh channel, userspace would also be
responsible for figuring out what happens with the STA interface next.

Dan

>
> Dan, you once said that you converted the MESH firmware
> calls to new style commands. Do you have those around? Maybe
> I can re-work them if they don't apply anymore.
>

2009-10-23 16:42:59

[permalink] [raw]

Subject: Re: [PATCH 17/19] [RFC, v2] libertas: Kconfig entry for libertas+cfg80211

On Fri, 2009-10-23 at 18:39 +0200, Johannes Berg wrote:
> On Fri, 2009-10-23 at 09:31 -0700, Dan Williams wrote:
>
> > > > I just don't understand why he thinks that wext and cfg80211 need to be
> > > > mutually exclusive. cfg80211 has exported its handlers for exactly this
> > > > purpose, so that you could have everything that cfg80211 supports via
> > > > it, and everything else directly.
> > >
> > > I thought about it more, and I think we can go all cfg80211 with a small
> > > WEXT handler for the mesh bits (it only cares about 4 of the WEXT
> > > operations and redirected the rest to the STA interface handlers). The
> > > mesh stuff is actually quite simple operationally.
> >
> > Which should allow us to use cfg80211 by default, and then have only the
> > LIBERTAS_MESH Kconfig option depend on WEXT. Maybe?
>
> Well if you want to push the mesh wext bits through to cfg80211
> (temporarily) you wouldn't even need to depend on WEXT. I'd prefer,
> however, to not do this, and just use the cfg80211 wext handlers in
> libertas and depend on WEXT for now.

Yeah, I think it's best to handle the mesh WEXT ioctls separately for
now. There are really only 4 of them (get/set SSID, set channel, get
mode) that matter for mesh. The rest of the ioctls that the mesh
interface supports get redirected to the cfg80211 handlers because they
aren't specific to mesh.

Dan

2009-10-23 16:52:53

[permalink] [raw]

Subject: Re: [PATCH 17/19] [RFC, v2] libertas: Kconfig entry for libertas+cfg80211

On Fri, 2009-10-23 at 18:48 +0200, Johannes Berg wrote:
> On Fri, 2009-10-23 at 09:42 -0700, Dan Williams wrote:
>
> > Yeah, I think it's best to handle the mesh WEXT ioctls separately for
> > now. There are really only 4 of them (get/set SSID, set channel, get
> > mode) that matter for mesh. The rest of the ioctls that the mesh
> > interface supports get redirected to the cfg80211 handlers because they
> > aren't specific to mesh.
>
> So why can't we simply do
>
> set_ssid()
> {
> if (mesh)
> return mesh_set_ssid();
> else
> return cfg80211_wext_iwessid()
> }

The mesh interface is a completely separate netdev, with its own WEXT
handler struct. So we'd never be in that situation.

Dan

2009-10-23 17:04:04

[permalink] [raw]

Subject: Re: [PATCH 17/19] [RFC, v2] libertas: Kconfig entry for libertas+cfg80211

On Fri, 2009-10-23 at 09:52 -0700, Dan Williams wrote:

> > > Yeah, I think it's best to handle the mesh WEXT ioctls separately for
> > > now. There are really only 4 of them (get/set SSID, set channel, get
> > > mode) that matter for mesh. The rest of the ioctls that the mesh
> > > interface supports get redirected to the cfg80211 handlers because they
> > > aren't specific to mesh.
> >
> > So why can't we simply do
> >
> > set_ssid()
> > {
> > if (mesh)
> > return mesh_set_ssid();
> > else
> > return cfg80211_wext_iwessid()
> > }
>
> The mesh interface is a completely separate netdev, with its own WEXT
> handler struct. So we'd never be in that situation.

Ah right. Yes then it makes sense to just remove all the non-mesh WEXT
stuff.

johannes

Attachments:

signature.asc (801.00 B)
This is a digitally signed message part

2009-10-23 16:39:35

[permalink] [raw]

Subject: Re: [PATCH 17/19] [RFC, v2] libertas: Kconfig entry for libertas+cfg80211

On Fri, 2009-10-23 at 09:31 -0700, Dan Williams wrote:

> > > I just don't understand why he thinks that wext and cfg80211 need to be
> > > mutually exclusive. cfg80211 has exported its handlers for exactly this
> > > purpose, so that you could have everything that cfg80211 supports via
> > > it, and everything else directly.
> >
> > I thought about it more, and I think we can go all cfg80211 with a small
> > WEXT handler for the mesh bits (it only cares about 4 of the WEXT
> > operations and redirected the rest to the STA interface handlers). The
> > mesh stuff is actually quite simple operationally.
>
> Which should allow us to use cfg80211 by default, and then have only the
> LIBERTAS_MESH Kconfig option depend on WEXT. Maybe?

Well if you want to push the mesh wext bits through to cfg80211
(temporarily) you wouldn't even need to depend on WEXT. I'd prefer,
however, to not do this, and just use the cfg80211 wext handlers in
libertas and depend on WEXT for now.

johannes

Attachments:

signature.asc (801.00 B)
This is a digitally signed message part

2009-10-26 08:00:10

[permalink] [raw]

Subject: Re: [PATCH 17/19] [RFC, v2] libertas: Kconfig entry for libertas+cfg80211

> > Well if you want to push the mesh wext bits through to cfg80211
> > (temporarily) you wouldn't even need to depend on WEXT. I'd prefer,
> > however, to not do this, and just use the cfg80211 wext handlers in
> > libertas and depend on WEXT for now.
>
> Yeah, I think it's best to handle the mesh WEXT ioctls separately for
> now. There are really only 4 of them (get/set SSID, set channel, get
> mode) that matter for mesh. The rest of the ioctls that the mesh
> interface supports get redirected to the cfg80211 handlers because they
> aren't specific to mesh.

We can reduce this to 3, because get/set channel could
simply go via cfg80211.

I'm unsure if we still need an GIWRANGE for mesh, but probably not.

Dan, you once said that you converted the MESH firmware
calls to new style commands. Do you have those around? Maybe
I can re-work them if they don't apply anymore.

--
http://www.holgerschurig.de

2009-12-15 15:37:05

[permalink] [raw]

Subject: Re: [PATCH 17/19] [RFC, v2] libertas: Kconfig entry for libertas+cfg80211

On Tue, 2009-12-15 at 16:06 +0100, Holger Schurig wrote:
> > I'd rather have new mesh commands. Right now, mesh
> > joining/leaving is implicit with interface up/down after you
> > set mesh parameters, but that's not very flexible.
>
> The mesh of Libertas' seems to be very different from "other"
> meshes, do you really want new nl80211 commands that seems
> almost proprietary?
>
> For example, "iw dev wlan0 set mesh_param" gives me lots of
> parameters, but none of them is a SSID. And many of those
> parameters don't seem to have an equivalent of Libertas' mesh.

Well the mesh_id is comparable in that case, I'd think.

But I don't really know.

johannes

Attachments:

signature.asc (801.00 B)
This is a digitally signed message part

2009-12-15 15:00:20

[permalink] [raw]

Subject: Re: [PATCH 17/19] [RFC, v2] libertas: Kconfig entry for libertas+cfg80211

> This means that STA/IBSS and Libertas' MESH cannot be active at
> the same time.

Oh, just read the old wext.c and I was wrong.

This magic de-auth / ibss leave happens only if the mesh channel
is different from the current STA/IBSS channel.

--
http://www.holgerschurig.de

2009-12-15 14:56:08

[permalink] [raw]

Subject: Re: [PATCH 17/19] [RFC, v2] libertas: Kconfig entry for libertas+cfg80211

Hi Dan !

After I conquered

* libertas + cfg80211 + station
* libertas + cfg80211 + monitor
* libertas + cfg80211 + adhoc

I'm at libertas + cfg80211 + Libertas' mesh.

The old idea was to keep WEXT for the little things that mesh
needs. It occurred to me that maybe this is not necessary, we
can use cfg80211 for mesh as well.

On your old

> In any case, the code for the mesh channel change was different
> than the code for the STA channel change, we have to be a bit
> careful here. The sequences were:
>
> STA:
>
> 1) get current channel #
> 2) issue a MESH_STOP command with the old channel
> 3) change the channel
> 4) resend WEP keys to firmware if any
> 5) restart adhoc if adhoc is enabled
>
> mesh:
>
> 1) if STA is active and in infrastructure, deauth from AP
> 2) if STA is active and in adhoc, issue ADHOC_STOP
> 3) issue MESH_START with new channel

This means that STA/IBSS and Libertas' MESH cannot be active at
the same time. In the cfg80211 case I can do the same, but
without doing some magically "deauth from AP" or "send
ADHOC_STOP" operation. I think it's better to keep this
explicit. So the user will have to do "iw XXX disconnect" or "iw
XXX ibss leave" to do that. If you're connected, "connecting" to
mesh would simply fail.

To start LIBERTAS-MESH without WEXT, I'd generate a second wiphy
device with .ibss_join and .ibss_leave operations, which in fact
will use Libertas' mesh commands. Thus a user could do this:

iw wlan0 disconnect
iw wlan0 ibss leave
iw msh0 ibss join MESH 2412 key 0:12345

In another mail Dan wrote:

> There are really only 4 of them (get/set SSID, set channel, get
> mode) that matter for mesh.

Nothing of this is really a WEXT-only, so I'd rather get rid of
WEXT completely, even for mesh. However, I need to abduct or
re-use the cfg80211 ibss commands for this, but I guess that's
not a problem.

Dan, Johannes, does this make sense?

--
http://www.holgerschurig.de

2009-12-15 14:52:23

[permalink] [raw]

Subject: Re: [PATCH 17/19] [RFC, v2] libertas: Kconfig entry for libertas+cfg80211

On Tue, 2009-12-15 at 15:44 +0100, Holger Schurig wrote:

> Nothing of this is really a WEXT-only, so I'd rather get rid of
> WEXT completely, even for mesh. However, I need to abduct or
> re-use the cfg80211 ibss commands for this, but I guess that's
> not a problem.
>
>
> Dan, Johannes, does this make sense?

I'd rather have new mesh commands. Right now, mesh joining/leaving is
implicit with interface up/down after you set mesh parameters, but
that's not very flexible.

johannes

Attachments:

signature.asc (801.00 B)
This is a digitally signed message part

2009-12-15 15:08:15

[permalink] [raw]

Subject: Re: [PATCH 17/19] [RFC, v2] libertas: Kconfig entry for libertas+cfg80211

> I'd rather have new mesh commands. Right now, mesh
> joining/leaving is implicit with interface up/down after you
> set mesh parameters, but that's not very flexible.

The mesh of Libertas' seems to be very different from "other"
meshes, do you really want new nl80211 commands that seems
almost proprietary?

For example, "iw dev wlan0 set mesh_param" gives me lots of
parameters, but none of them is a SSID. And many of those
parameters don't seem to have an equivalent of Libertas' mesh.

--
http://www.holgerschurig.de

2009-12-16 16:51:15