Hi,
I would be interested in running the 802.11s mode of the linux wifi
stack without the mesh switching protocol.
802.11s with its 6-address frame format could be a great improvement
over IBSS mode because it allows to attach the local wifi card to a
bridge. We are using Layer-3 routing for establishing the mesh, so
HWMP would just interfere with out usecase.
Is there an easy way to stop HWMP in the 802.11s implementation? This
would restrict unicast and multicast communication to just direct
connections like IBSS mode.
Henning Rogge
On Mon, May 19, 2014 at 3:18 PM, Bob Copeland <[email protected]> wrote:
> On Mon, May 19, 2014 at 11:00:53AM +0200, Henning Rogge wrote:
>> Is there an easy way to stop HWMP in the 802.11s implementation?
>
> If I understand your use case, you want to basically remove the
> resolving part of mesh_nexthop_resolve()? I don't believe the
> current implementation has a way to turn that off. In principle,
> you can specify a vendor-specific path selection protocol when
> joining, but glancing at the existing code, we don't really do
> anything with that field except use it for peering fitness checks.
I have an IP router connected via ethernet to a radio with a single
wifi card, using the wifi card as a bridged radio. Its a great way to
build routers with lots of Wifi links because you can mount the
wifi-cards itself on the antenna and keep the router in a central
place.
I don't want to use layer-2 forwarding in the mesh because this
increases the broad-/multicast domain size and spams the available
frequencies even more.
> If all you want to do is force the paths, you can do so with the
> NL80211_CMD_SET_MESH_PATH API; such paths would override any selected
> by HWMP. But you'd still generate PREQ/PREPs and get multihop
> communication in that case, it just wouldn't be subject to the
> airtime link metric.
>
> Perhaps we should skip resolve in case ifmsh->mesh_pp_id != 1
> and assume paths are somehow set up out of band or something?
I want to force 802.11s only to connect to other stations one layer-2
hop away. So no forwarding by intermediate stations.
Does the "mesh_fwding" parameter maybe help? Or can I set a "TTL" for
the PREQ messages to 1?
Henning Rogge
Hi,
----- Mail original -----
> De: "Henning Rogge" <[email protected]>
> À: "Bob Copeland" <[email protected]>
> Cc: [email protected]
> Envoyé: Lundi 19 Mai 2014 16:14:36
> Objet: Re: 802.11s mode without HWMP
>
> On Mon, May 19, 2014 at 3:18 PM, Bob Copeland <[email protected]>
> wrote:
> > On Mon, May 19, 2014 at 11:00:53AM +0200, Henning Rogge wrote:
> >> Is there an easy way to stop HWMP in the 802.11s implementation?
> >
> I have an IP router connected via ethernet to a radio with a single
> wifi card, using the wifi card as a bridged radio. Its a great way to
> build routers with lots of Wifi links because you can mount the
> wifi-cards itself on the antenna and keep the router in a central
> place.
>
> I don't want to use layer-2 forwarding in the mesh because this
> increases the broad-/multicast domain size and spams the available
> frequencies even more.
>
> I want to force 802.11s only to connect to other stations one layer-2
> hop away. So no forwarding by intermediate stations.
>
> Henning Rogge
> --
I'm curious, what are you using for your L3 mesh/can you give details on the network?
Thanks in advance
Etienne
On Tue, May 20, 2014 at 7:36 PM, Thomas Pedersen <[email protected]> wrote:
> Hi Henning,
> mac80211 keeps a separate table for bridged endpoints (mpp_paths).
> Unfortunately this table currently isn't exported by the cfg80211
> mpath_dump API. If you really need access to this information from
> cfg80211 / userspace, then the quickest thing for now would be to hack
> in support for iterating over both tables.
>
> I'm not really sure why the decision was made to go with 2 different
> path tables (see 79617dee for the initial implementation), but it
> seems the cleaner approach would be to merge these and stick with the
> existing mpath_dump commands.
After looking at both tables (especially the m***_path_add()
functions) I think the two tables could be joined.
Mesh-nodes could be just a special case where mpp and dst is the same
address. The alternative would be to have a flag that states the same
thing.
I don't even think this would slow down the path_lookup that much,
because normally the proxied destinations should be in different hash
buckets than the normal ones.
Of course cfg80211 would have to deliver both mpp and dst to
userspace, I am not quite sure how to do this without breaking
compatibility in the output. Maybe an additional netlink command (dump
"full" mpath?) would be better than putting more output into the
existing one.
Henning Rogge
On Mon, May 19, 2014 at 11:00:53AM +0200, Henning Rogge wrote:
> Is there an easy way to stop HWMP in the 802.11s implementation?
If I understand your use case, you want to basically remove the
resolving part of mesh_nexthop_resolve()? I don't believe the
current implementation has a way to turn that off. In principle,
you can specify a vendor-specific path selection protocol when
joining, but glancing at the existing code, we don't really do
anything with that field except use it for peering fitness checks.
If all you want to do is force the paths, you can do so with the
NL80211_CMD_SET_MESH_PATH API; such paths would override any selected
by HWMP. But you'd still generate PREQ/PREPs and get multihop
communication in that case, it just wouldn't be subject to the
airtime link metric.
Perhaps we should skip resolve in case ifmsh->mesh_pp_id != 1
and assume paths are somehow set up out of band or something?
--
Bob Copeland %% http://www.bobcopeland.com
On Mon, May 19, 2014 at 04:14:36PM +0200, Henning Rogge wrote:
> I want to force 802.11s only to connect to other stations one layer-2
> hop away. So no forwarding by intermediate stations.
>
> Does the "mesh_fwding" parameter maybe help? Or can I set a "TTL" for
> the PREQ messages to 1?
Ah, ok got it. Then yes, you are right, either of those approaches will
disable forwarding.
--
Bob Copeland %% http://www.bobcopeland.com
> I will have a look at both tables and see what I can do with them,
> maybe a second netlink command is necessary in cfg80211.
You can probably take a look on patches by Shinoda submitted to o11s
mailing list:
http://lists.open80211s.org/pipermail/devel/2012-September/002112.html
It extends the support of mpath dump to show the MAC address behind
the proxy mesh gate.
In additional to this, as mentioned in IEEE 802.11-2012 section
13.11.4.3, the proxy mesh gate can generate a PXU element to others to
inform external stations proxied by the proxy mesh gate. But o11s has
not implemented yet.
----
Chun-Yeow
I am not convinced merging them is a good idea, because they contain
different information.
One of them is the list of AODV ("HWMP") capable MACs, the other is
"attached/bridged" MACs.
I will have a look at both tables and see what I can do with them,
maybe a second netlink command is necessary in cfg80211.
Thank you for the tip.
Henning Rogge
On Tue, May 20, 2014 at 7:36 PM, Thomas Pedersen <[email protected]> wrote:
> Hi Henning,
>
> On Tue, May 20, 2014 at 5:32 AM, Henning Rogge <[email protected]> wrote:
>> Hi,
>>
>> after spending a day reading through the 802.11s implementation of
>> Linux I have to admit I am lost...
>>
>> I am using 802.11s bridged to ethernet on both wlan interfaces and it
>> works very well.
>>
>> Unfortunately the cfg802.11 is not telling me which ethernet mac
>> address is behind which wifi mac address, something that has to be
>> known to the kernel to forward the bridged ethernet frames.
>>
>> Is there a trick to get this information or is this just a missing
>> functionality in the cfg80211 API (or the "iw <mesh-if> mpath ..."
>> commands) ?
>
> mac80211 keeps a separate table for bridged endpoints (mpp_paths).
> Unfortunately this table currently isn't exported by the cfg80211
> mpath_dump API. If you really need access to this information from
> cfg80211 / userspace, then the quickest thing for now would be to hack
> in support for iterating over both tables.
>
> I'm not really sure why the decision was made to go with 2 different
> path tables (see 79617dee for the initial implementation), but it
> seems the cleaner approach would be to merge these and stick with the
> existing mpath_dump commands.
>
> --
> thomas
Hi Henning,
On Tue, May 20, 2014 at 5:32 AM, Henning Rogge <[email protected]> wrote:
> Hi,
>
> after spending a day reading through the 802.11s implementation of
> Linux I have to admit I am lost...
>
> I am using 802.11s bridged to ethernet on both wlan interfaces and it
> works very well.
>
> Unfortunately the cfg802.11 is not telling me which ethernet mac
> address is behind which wifi mac address, something that has to be
> known to the kernel to forward the bridged ethernet frames.
>
> Is there a trick to get this information or is this just a missing
> functionality in the cfg80211 API (or the "iw <mesh-if> mpath ..."
> commands) ?
mac80211 keeps a separate table for bridged endpoints (mpp_paths).
Unfortunately this table currently isn't exported by the cfg80211
mpath_dump API. If you really need access to this information from
cfg80211 / userspace, then the quickest thing for now would be to hack
in support for iterating over both tables.
I'm not really sure why the decision was made to go with 2 different
path tables (see 79617dee for the initial implementation), but it
seems the cleaner approach would be to merge these and stick with the
existing mpath_dump commands.
--
thomas
Hi,
after spending a day reading through the 802.11s implementation of
Linux I have to admit I am lost...
I am using 802.11s bridged to ethernet on both wlan interfaces and it
works very well.
Unfortunately the cfg802.11 is not telling me which ethernet mac
address is behind which wifi mac address, something that has to be
known to the kernel to forward the bridged ethernet frames.
Is there a trick to get this information or is this just a missing
functionality in the cfg80211 API (or the "iw <mesh-if> mpath ..."
commands) ?
Henning Rogge
On Mon, May 19, 2014 at 9:38 PM, <[email protected]> wrote:
> Hi,
>
> I'm curious, what are you using for your L3 mesh/can you give details on the network?
>
> Thanks in advance
> Etienne
I am using the Olsr.org codebase for routing... I have spent the last
~2 years to do a clean rewrite of the codebase for an OLSRv2
implementation.
I am not directly involved in one special mesh network.
1st, I am involved in the Olsr.org project, which is one of the
routing protocols used in lots of cities in Europe to build large
city-wide mesh networks with a mixture of wifi links, some of them
with hundreds of nodes.
2nd, I am working for Fraunhofer FKIE in mesh related research
(currently as part of the EU CONFINE project, see
http://www.confine-project.eu) and we are interested in using mesh networks
both for civil usecases (police, fire brigade, disaster recovery like
earthquakes) and military ones.
Some networks running with OLSR.org routing software have hundreds of
nodes, most are smaller.
My interest in the "bridging adhoc mode" is also related to the IETF
DLEP draft (http://tools.ietf.org/html/draft-ietf-manet-dlep-05),
which contains the concept of the "ethernet attached briding radio"
and a communication protocol between local router and radio.
I think a "802.11s without HWMP" mode would make a perfect candidate
for a DLEP style radio, at the moment I am using IBSS mode and a hack
with the mac addresses.
I hope this answers your question.
Henning Rogge
On Mon, May 19, 2014 at 4:29 PM, Bob Copeland <[email protected]> wrote:
> On Mon, May 19, 2014 at 04:14:36PM +0200, Henning Rogge wrote:
>> I want to force 802.11s only to connect to other stations one layer-2
>> hop away. So no forwarding by intermediate stations.
>>
>> Does the "mesh_fwding" parameter maybe help? Or can I set a "TTL" for
>> the PREQ messages to 1?
>
> Ah, ok got it. Then yes, you are right, either of those approaches will
> disable forwarding.
I will try both of them and see what the Mac80211 Monitor mode sees.
But I have a second question, does the 802.11 mesh mode keep track
which "end to end" mac address is behind which "mesh" mac address? If
I bridge the mesh interfaces to an ethernet both will not be the same.
Henning Rogge