[PATCH 00/13 v2] o11s: mesh interface support for mac80211

[PATCH 00/13 v2] o11s: mesh interface support for mac80211

[Luis Carlos Cobo]

This series of patches provides support for (pre) IEEE 802.11s mesh interfaces.
Current features include mesh discovery, peer link establishment and on-demand
HWMP path discovery.

This is the second round of patches incorporating the comments from Johannes
Berg and others. The main changes with the first set of patches are:

 - We are now using airtime link metric, instead of hop count.

 - Mesh peer link table has been discarded, integrating the necessary attributes
   directly on struct sta_info.

 - We no longer use directily rtnetlink for mesh peer link and mesh paths
   operation, and use nl80211 instead.

 - We now support mesh network in scan. The part interacting with wext is a bit
   ugly but works well. I just read the mail from Johannes with a different
   approach and will consider it.

The pid rate control algorithm has been modified to provide an estimated
transmission error, probability, necessary for the airtime link metric, and a to
call mesh_peer_link_broken() if it detects a sta is no longer reachable.

I would like to point out that it looks like we can get duplicate sta_entries,
or more entries than the maximum allowed, if stas are added at the same time
through normal network behaviour and manual operation through nl80211. Please
correct me if I am wrong or if it is just that no interface type is supposed to
allow both kinds of additions.

The code has been tested in a 12-node testbed and has proved to be stable and
functional. We would like to get it integrated as soon as possible so it can get
more widespread testing and (hopefully) contributions. Unfortunately we have run
out of funds for this project (we are looking for sponsors!) so work on the
project from our side might slow down. At the very least, we are commited to
fixing bugs and tracking changes introduced by newer versions of the 11s draft.

The only supported driver right now is zd1211rw, but changes in the driver for
mesh functionality are minimal (for the zd1211rw driver most changes were just
to provide missing functionality such as beaconing support), so we expect a wide
array of devices to be supported soon.

The patches are to be applied on top of wireless-2.6/everything HEAD. Even
though I am sure there will be some issues, it would be great if we could
integrate this as soon as possible to make it easier for other people to
collaborate and to make my life a bit easier :-)

For more information, please visit: http://o11s.org/devel

Enjoy,

Luis Carlos Cobo

[PATCH 00/13 v2] o11s: mesh interface support for mac80211

[Luis Carlos Cobo]

This series of patches provides support for (pre) IEEE 802.11s mesh interfaces.
Current features include mesh discovery, peer link establishment and on-demand
HWMP path discovery.

This is the second round of patches incorporating the comments from Johannes
Berg and others. The main changes with the first set of patches are:

 - We are now using airtime link metric, instead of hop count.

 - Mesh peer link table has been discarded, integrating the necessary attributes
   directly on struct sta_info.

 - We no longer use directly rtnetlink for mesh peer link and mesh paths
   operation, and use nl80211 instead.

 - We now support mesh network in scan. The part interacting with wext is a bit
   ugly but works well. I just read the mail from Johannes with a different
   approach and will consider it.

The pid rate control algorithm has been modified to provide an estimated
transmission error, probability, necessary for the airtime link metric, and a to
call mesh_peer_link_broken() if it detects a sta is no longer reachable.

I would like to point out that it looks like we can get duplicate sta_entries,
or more entries than the maximum allowed, if stas are added at the same time
through normal network behavior and manual operation through nl80211. Please
correct me if I am wrong or if it is just that no interface type is supposed to
allow both kinds of additions.

The code has been tested in a 12-node testbed and has proved to be stable and
functional. The only supported driver right now is zd1211rw, but changes in the
driver for mesh functionality are minimal (for the zd1211rw driver most changes
were just to provide missing functionality such as beaconing support), so we
expect a wide array of devices to be supported soon.

The patches are to be applied on top of wireless-2.6/everything HEAD. Even
though I am sure there will be some issues, it would be great if we could
integrate this as soon as possible to make it easier for other people to
collaborate and to make my life a bit easier :-)

For more information, please visit: http://o11s.org/devel

Enjoy,

Luis Carlos Cobo

Re: [PATCH 00/13 v2] o11s: mesh interface support for mac80211

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 2652 bytes --]


> This is the second round of patches incorporating the comments from Johannes
> Berg and others. The main changes with the first set of patches are:

:)

>  - We are now using airtime link metric, instead of hop count.

Cool.

>  - Mesh peer link table has been discarded, integrating the necessary attributes
>    directly on struct sta_info.

Neat. I'll have to respin either my recent sta_info reorg patches or
these. I can do the work either way, sorry for messing with mac80211 all
the time.

>  - We no longer use directly rtnetlink for mesh peer link and mesh paths
>    operation, and use nl80211 instead.

Nice too. What does libertas currently do btw?

>  - We now support mesh network in scan. The part interacting with wext is a bit
>    ugly but works well. I just read the mail from Johannes with a different
>    approach and will consider it.

I'll take a look here too.

> The pid rate control algorithm has been modified to provide an estimated
> transmission error, probability, necessary for the airtime link metric, and a to
> call mesh_peer_link_broken() if it detects a sta is no longer reachable.

Interesting. Would like to get Stefano's input on that.

> I would like to point out that it looks like we can get duplicate sta_entries,
> or more entries than the maximum allowed, if stas are added at the same time
> through normal network behavior and manual operation through nl80211. Please
> correct me if I am wrong or if it is just that no interface type is supposed to
> allow both kinds of additions.

I think I CC'ed you on the patch fixing that, no?

> The code has been tested in a 12-node testbed and has proved to be stable and
> functional. The only supported driver right now is zd1211rw, but changes in the
> driver for mesh functionality are minimal (for the zd1211rw driver most changes
> were just to provide missing functionality such as beaconing support), so we
> expect a wide array of devices to be supported soon.

I think b43 should be fine since it supports AP (so clearly beacons),
the only thing to figure out is whether to turn on or off INFRA mode
(ie. use AP or IBSS beaconing)

> The patches are to be applied on top of wireless-2.6/everything HEAD. Even
> though I am sure there will be some issues, it would be great if we could
> integrate this as soon as possible to make it easier for other people to
> collaborate and to make my life a bit easier :-)

Hm. I think you'd have to rebase on top of wireless-testing/master but
I'm not sure how they currently differ. See John Linville's mail on the
new tree structure.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [PATCH 00/13 v2] o11s: mesh interface support for mac80211

[John W. Linville]

On Fri, Feb 22, 2008 at 04:21:49PM +0100, Johannes Berg wrote:

> > The patches are to be applied on top of wireless-2.6/everything HEAD. Even
> > though I am sure there will be some issues, it would be great if we could
> > integrate this as soon as possible to make it easier for other people to
> > collaborate and to make my life a bit easier :-)
> 
> Hm. I think you'd have to rebase on top of wireless-testing/master but
> I'm not sure how they currently differ. See John Linville's mail on the
> new tree structure.

They were euivalent until day before yesterday.  No
wireless-2.6/everything is gone and wireless-testing/master has
progressed.  Please use wireless-testing/master for any future patches.

Thanks,

John
-- 
John W. Linville
linville@tuxdriver.com

Re: [PATCH 00/13 v2] o11s: mesh interface support for mac80211

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1059 bytes --]

Hi,

Luis, thanks for your patience with me.

> >  - We now support mesh network in scan. The part interacting with wext is a bit
> >    ugly but works well. I just read the mail from Johannes with a different
> >    approach and will consider it.
> 
> I'll take a look here too.

Looks ok to me, if it works in userspace. Adding custom items to wext is
always fine and a new mode is ok with me, overloading the SSID is the
only sane thing to do.

> > The pid rate control algorithm has been modified to provide an estimated
> > transmission error, probability, necessary for the airtime link metric, and a to
> > call mesh_peer_link_broken() if it detects a sta is no longer reachable.
> 
> Interesting. Would like to get Stefano's input on that.

Looks ok to me too, though it should be documented.

I think you're right and we should apply this to wireless-testing and
fix the remaining problems there. I can then rebase my last 9 patches
(including the sta info work) on top of that and we'll see where it
conflicts.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [PATCH 00/13 v2] o11s: mesh interface support for mac80211

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 298 bytes --]


> I think you're right and we should apply this to wireless-testing and
> fix the remaining problems there. I can then rebase my last 9 patches
> (including the sta info work) on top of that and we'll see where it
> conflicts.

I'm just working on fixups, just to let you know.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [PATCH 00/13 v2] o11s: mesh interface support for mac80211

[Luis Carlos Cobo]

On Fri, 2008-02-22 at 16:21 +0100, Johannes Berg wrote:
> >  - We no longer use directly rtnetlink for mesh peer link and mesh paths
> >    operation, and use nl80211 instead.
> 
> Nice too. What does libertas currently do btw?
> 

iwpriv...

> > I would like to point out that it looks like we can get duplicate sta_entries,
> > or more entries than the maximum allowed, if stas are added at the same time
> > through normal network behavior and manual operation through nl80211. Please
> > correct me if I am wrong or if it is just that no interface type is supposed to
> > allow both kinds of additions.
> 
> I think I CC'ed you on the patch fixing that, no?

Not sure which patch are you talking about, anyway I will check that
along with the mesh + sta_info changes testing.

-- 
Luis Carlos Cobo Rus       GnuPG ID: 44019B60
cozybit Inc.

Re: [PATCH 00/13 v2] o11s: mesh interface support for mac80211

[Luis Carlos Cobo]

On Fri, 2008-02-22 at 17:34 +0100, Johannes Berg wrote:
> Hi,
> 
> Luis, thanks for your patience with me.

Hahaha, your comments (and fixes) are really appreciated!

-- 
Luis Carlos Cobo Rus       GnuPG ID: 44019B60
cozybit Inc.

Re: [PATCH 00/13 v2] o11s: mesh interface support for mac80211

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1021 bytes --]


> > >  - We no longer use directly rtnetlink for mesh peer link and mesh paths
> > >    operation, and use nl80211 instead.
> > 
> > Nice too. What does libertas currently do btw?
> > 
> 
> iwpriv...

eww, ok. Guess we can convert that, CC Dan & David.

> > > I would like to point out that it looks like we can get duplicate sta_entries,
> > > or more entries than the maximum allowed, if stas are added at the same time
> > > through normal network behavior and manual operation through nl80211. Please
> > > correct me if I am wrong or if it is just that no interface type is supposed to
> > > allow both kinds of additions.
> > 
> > I think I CC'ed you on the patch fixing that, no?
> 
> Not sure which patch are you talking about, anyway I will check that
> along with the mesh + sta_info changes testing.

Subject was "mac80211: atomically check whether STA exists already"

It didn't check the number of STAs since I thought adding one per CPU
more wouldn't hurt too much ;)

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [PATCH 00/13 v2] o11s: mesh interface support for mac80211

[David Woodhouse]

On Mon, 2008-02-25 at 20:50 +0100, Johannes Berg wrote:
> > > >  - We no longer use directly rtnetlink for mesh peer link and mesh paths
> > > >    operation, and use nl80211 instead.
> > > 
> > > Nice too. What does libertas currently do btw?
> > > 
> > 
> > iwpriv...
> 
> eww, ok. Guess we can convert that, CC Dan & David.

Upstream libertas doesn't have the private ioctls. We have them as a
local hack in the OLPC tree only. I'll be happy to convert to a saner
generic API.

We also want some way to set the l2 ttl per-socket.

-- 
dwmw2

Re: [PATCH 00/13 v2] o11s: mesh interface support for mac80211

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 816 bytes --]


On Mon, 2008-02-25 at 20:03 -0500, David Woodhouse wrote:
> On Mon, 2008-02-25 at 20:50 +0100, Johannes Berg wrote:
> > > > >  - We no longer use directly rtnetlink for mesh peer link and mesh paths
> > > > >    operation, and use nl80211 instead.
> > > > 
> > > > Nice too. What does libertas currently do btw?

> Upstream libertas doesn't have the private ioctls. We have them as a
> local hack in the OLPC tree only. I'll be happy to convert to a saner
> generic API.

Oh, cool. The API seems to be there for mesh paths now.

> We also want some way to set the l2 ttl per-socket.

I think you went around with that on netdev before? I don't think we can
do any per-socket special stuff just in wireless since we're not really
handling sockets, so it'll have to be a socket option?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]