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, using hop count as the metric.
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.
We would appreciate any comments or advice useful toward integration of this
code. Specific areas where we would like to get some feedback are:
- Possible integration between mesh peer link and sta_info structures. Their
purpose is similar and it will make it easier to implement mesh rate control
and airtime link metric.
- Beaconing support: the current beacon model is appropriate for the zd1211rw
driver but might not be for others.
- set_mesh_cfg command to set mesh ID and use of broadcast mesh ID when none is
set: Johannes suggested the mesh ID should be specified when creating the mesh
interface [1]. However we feel that a "mesh configuration" or "mesh network"
object analogous to the "association" object he talks about would be more
appropriate. Such an association object has not yet been implemented. We
would appreciate some advice on how to implement our mesh network object so
that it follows the spirit of mac80211.
- Scan support: we were waiting for scan to be moved to cfg80211 to avoid
messing unnecessarily with wext, is there any effort in this direction?
[1]: http://www.spinics.net/lists/linux-wireless/msg07745.html
For more information, please visit: http://o11s.org/devel
Enjoy,
Luis Carlos Cobo
On Tue, 2008-02-19 at 16:59 -0500, Luis R. Rodriguez wrote:
> > Currently, bss are sorted by ssid, bssid and frequency.
>
> I wouldn't use "sort" here but instead "are made unique". As John has
Right, sorry for the imprecise use of the word.
> The key'ing of the BSSes based on BSSID/freq/SSID was just a to deal
> with an issue, how about we just detect if a beacon is from a mesh and
> if so add it to the list using another type of rule? Since we have no
> BSSID/SSID strange issue we don't have to apply that rule there.
Sounds good.
> > but the user chooses an ad-hoc network), change the type of the
> > interface and the proceed to connect. Am I right?
>
> Hopefully nothing will be added via wext, but instead nl80211/cfg80211.
Hopefully, but last time I checked (10 days ago) it looked like there
was no work in progress to implement scanning via nl80211.
--
Luis Carlos Cobo Rus GnuPG ID: 44019B60
cozybit Inc.
On Tue, 2008-02-19 at 13:13 -0800, Luis Carlos Cobo wrote:
> On Thu, 2008-02-07 at 01:13 +0100, Johannes Berg wrote:
> > > - Scan support: we were waiting for scan to be moved to cfg80211 to avoid
> > > messing unnecessarily with wext, is there any effort in this direction?
> >
> > What specifically do you need? Scanning for mesh networks? Wouldn't a
> > regular scan find them as well? As far as I know nobody is currently
> > working on scan support in nl80211. Maybe you can simply report the
> > relevant mesh IEs in a custom element and sort it out in userspace (for
> > now)?
>
> Currently, bss are sorted by ssid, bssid and frequency. In mesh beacons
> and (not yet implemented) mesh probes, the bssid is left zeroed and
> there is no ssid (actually there is a 0 length ssid IE), so all mesh
> networks in a single channel would collapse to one scan entry. I can add
> the mesh IE, but I also need a substitute for those.
>
> One option would be to use mesh id as bssid and source address as bssid
> (with this we would get a different entry for every mesh peer in rage,
> not sure if that's what we want), maybe set the mode to IW_MODE_ADHOC
> and add the extra mesh IE. This way we would not need changes in the
> wireless extesions layer.
>
> I am also curious about the interfaces life cycle. Looks like interfaces
> report any available network (infra or adhoc), regardless their type.
Yes. Ideally the driver will report mesh networks too, perhaps with
IW_MODE_MESH or whatever nl80211 would use.
> Then a network-manager-like interface would have to bring up an
> interface to be able to scan, and the if the user chooses a different
> kind of network (if the interface where the scan is performed is infra
> but the user chooses an ad-hoc network), change the type of the
> interface and the proceed to connect. Am I right?
Yeah, if the stack knows about a mesh network, we've got to be able to
present all the available choices and let the user decide what to do (or
try to do something intelligent like connect to the last used network if
it's seen).
Dan
On Feb 19, 2008 4:13 PM, Luis Carlos Cobo <[email protected]> wrote:
> On Thu, 2008-02-07 at 01:13 +0100, Johannes Berg wrote:
> > > - Scan support: we were waiting for scan to be moved to cfg80211 to avoid
> > > messing unnecessarily with wext, is there any effort in this direction?
> >
> > What specifically do you need? Scanning for mesh networks? Wouldn't a
> > regular scan find them as well? As far as I know nobody is currently
> > working on scan support in nl80211. Maybe you can simply report the
> > relevant mesh IEs in a custom element and sort it out in userspace (for
> > now)?
>
> Currently, bss are sorted by ssid, bssid and frequency.
I wouldn't use "sort" here but instead "are made unique". As John has
mentioned in a recent thread this was done to account for "some
strange AP implementations that use the same BSSID either on different
frequencies or in different SSIDs". We actually don't currently sort
the list of BSSes by any specific value but the idea was to end up
sorting by signal strength measured, for which I have a base patch.
Userspace should then be sort by whatever key it wants to presents its
data to the user.
> In mesh beacons
> and (not yet implemented) mesh probes, the bssid is left zeroed and
> there is no ssid (actually there is a 0 length ssid IE), so all mesh
> networks in a single channel would collapse to one scan entry.
I can see how this can be an issue :)
> I can add
> the mesh IE, but I also need a substitute for those.
>
> One option would be to use mesh id as bssid and source address as bssid
> (with this we would get a different entry for every mesh peer in rage,
> not sure if that's what we want), maybe set the mode to IW_MODE_ADHOC
> and add the extra mesh IE. This way we would not need changes in the
> wireless extesions layer.
The key'ing of the BSSes based on BSSID/freq/SSID was just a to deal
with an issue, how about we just detect if a beacon is from a mesh and
if so add it to the list using another type of rule? Since we have no
BSSID/SSID strange issue we don't have to apply that rule there.
> I am also curious about the interfaces life cycle. Looks like interfaces
> report any available network (infra or adhoc), regardless their type.
> Then a network-manager-like interface would have to bring up an
> interface to be able to scan, and the if the user chooses a different
> kind of network (if the interface where the scan is performed is infra
> but the user chooses an ad-hoc network), change the type of the
> interface and the proceed to connect. Am I right?
Hopefully nothing will be added via wext, but instead nl80211/cfg80211.
Luis
On Thu, 2008-02-07 at 01:13 +0100, Johannes Berg wrote:
> > - Scan support: we were waiting for scan to be moved to cfg80211 to avoid
> > messing unnecessarily with wext, is there any effort in this direction?
>
> What specifically do you need? Scanning for mesh networks? Wouldn't a
> regular scan find them as well? As far as I know nobody is currently
> working on scan support in nl80211. Maybe you can simply report the
> relevant mesh IEs in a custom element and sort it out in userspace (for
> now)?
Currently, bss are sorted by ssid, bssid and frequency. In mesh beacons
and (not yet implemented) mesh probes, the bssid is left zeroed and
there is no ssid (actually there is a 0 length ssid IE), so all mesh
networks in a single channel would collapse to one scan entry. I can add
the mesh IE, but I also need a substitute for those.
One option would be to use mesh id as bssid and source address as bssid
(with this we would get a different entry for every mesh peer in rage,
not sure if that's what we want), maybe set the mode to IW_MODE_ADHOC
and add the extra mesh IE. This way we would not need changes in the
wireless extesions layer.
I am also curious about the interfaces life cycle. Looks like interfaces
report any available network (infra or adhoc), regardless their type.
Then a network-manager-like interface would have to bring up an
interface to be able to scan, and the if the user chooses a different
kind of network (if the interface where the scan is performed is infra
but the user chooses an ad-hoc network), change the type of the
interface and the proceed to connect. Am I right?
--
Luis Carlos Cobo Rus GnuPG ID: 44019B60
cozybit Inc.
Cool stuff! Code looks pretty good but there seems to be some
misunderstanding, especially wrt. beaconing.
> - Possible integration between mesh peer link and sta_info structures. Their
> purpose is similar and it will make it easier to implement mesh rate control
> and airtime link metric.
Indeed, I think this should be done. For one, we already look up the TA
sta_info structure for each frame so you don't need to look it up if you
pass it appropriately. Also a second hash table based on TA address just
takes up a lot of space.
> - Beaconing support: the current beacon model is appropriate for the zd1211rw
> driver but might not be for others.
Indeed. You shouldn't set conf->beacon directly, instead you should
change ieee80211_beacon_get() to support getting an IBSS beacon and then
you need to call ieee80211_if_config_beacon() where appropriate. Using
IEEE80211_HW_HOST_GEN_BEACON_TEMPLATE from the stack is simply wrong
too.
> - set_mesh_cfg command to set mesh ID and use of broadcast mesh ID when none is
> set: Johannes suggested the mesh ID should be specified when creating the mesh
> interface [1]. However we feel that a "mesh configuration" or "mesh network"
> object analogous to the "association" object he talks about would be more
> appropriate. Such an association object has not yet been implemented. We
> would appreciate some advice on how to implement our mesh network object so
> that it follows the spirit of mac80211.
Is it really useful to change the mesh ID on a running interface? It
seems that would totally throw off things like multicast caching and
peer link establishment. Therefore, it seems that
ieee80211_if_set_mesh_cfg should reject to configure a running
interface.
> - Scan support: we were waiting for scan to be moved to cfg80211 to avoid
> messing unnecessarily with wext, is there any effort in this direction?
What specifically do you need? Scanning for mesh networks? Wouldn't a
regular scan find them as well? As far as I know nobody is currently
working on scan support in nl80211. Maybe you can simply report the
relevant mesh IEs in a custom element and sort it out in userspace (for
now)?
johannes
> Currently, bss are sorted by ssid, bssid and frequency. In mesh beacons
> and (not yet implemented) mesh probes, the bssid is left zeroed and
> there is no ssid (actually there is a 0 length ssid IE), so all mesh
> networks in a single channel would collapse to one scan entry. I can add
> the mesh IE, but I also need a substitute for those.
Ok. I think you'll have to rework the scanning code to not just use
SSID, BSSID and frequency to distinguish between networks but also the
mesh information (mesh ID/mesh IE).
> One option would be to use mesh id as bssid and source address as bssid
> (with this we would get a different entry for every mesh peer in rage,
> not sure if that's what we want), maybe set the mode to IW_MODE_ADHOC
> and add the extra mesh IE. This way we would not need changes in the
> wireless extesions layer.
Dan said:
> Yes. Ideally the driver will report mesh networks too, perhaps with
> IW_MODE_MESH or whatever nl80211 would use.
As unfortunate as it may be, we can't add it to wext cleanly because
iwlist would probably simply segfault if we added a new type since it
doesn't verify any input it gets from the kernel and just uses it for an
array lookup (thank you Jean!). Or we add a new type and just let all
userspace segfault until it's fixed. It's not a kernel bug, after all...
We can always include the mesh information in the GENIE element and
interested parties have to parse it... however, we can't set the type to
anything useful. If we set it to ad-hoc, then tools like network manager
might try to use that network for ad-hoc which won't work. It would
probably be best to leave out the SIOCGIWMODE info completely and hope
that tools that aren't prepared to handle it just ignore that...
Ultimately, I guess we're at a point where wext reached the end of its
usefulness and we seriously need to look at getting a replacement done.
> I am also curious about the interfaces life cycle. Looks like interfaces
> report any available network (infra or adhoc), regardless their type.
Indeed.
> Then a network-manager-like interface would have to bring up an
> interface to be able to scan, and the if the user chooses a different
> kind of network (if the interface where the scan is performed is infra
> but the user chooses an ad-hoc network), change the type of the
> interface and the proceed to connect. Am I right?
Yeah, it'll even have to set the interface down to be able to change the
type.
johannes