[B.A.T.M.A.N.] link alternation when radios are not on batman-adv router?

[B.A.T.M.A.N.] link alternation when radios are not on batman-adv router?

[dan]

I have an interesting hardware setup I'd like to explore.

Basically, I would like to take commodity ubiquiti and/or openmesh
hardware and build a mesh with two different node types, some having
just 1 radio and others having multiple radios, a standard node and a
super node.

the standard node is:
a picostation flashed to openwrt running batman-adv and running the
radio in Ad-Hoc mode.  Alternately an OM2P flashed to openwrt.  This
is the basic client radio

the super node is:
a group of picostations or nanostations, flashed openwrt in adhoc
mode, but acting only as the L2 transport with a router at the center
running batman-adv.

The idea is that the super nodes have multiple radios in multiple
channels and can take advantage of link alternation allowing super
nodes to keep much higher bandwidth between them while the standard
nodes are cheap.  The 'router' MIGHT also have a radio for client
access (unifi station flashed to openwrt maybe, or an ALIX board)

The supernode will have more CPU and also be the target of
backhaul/shorthaul links to cut down on hop count.  The main router
would also be a batman-adv device, probably an x86 server, and would
be the border router for the mesh.

some questions,
I know that the supernodes will have higher throughput capabilities
due to dual mesh radios, but how will batman-adv know this or how
would I tell it?  Is the internal mechanism for determining the best
path going to take this into account?  Is there a way to identify a
supernode as being a better path above and beyond the automatic
batman-adv mechanisms?

Is having separate radios connected to a batman-adv router going to
behave how I presume?  That multiple node2node connections will be
identified and the links be alternated when appropriate?

If the supernodes have 2 mesh radios, 1 in 5Ghz and 1 in 2.4Ghz, then
the standard nodes will only be able to connect to the 2.4Ghz channel
which might make it inappropriate to do link alternating on these two
links because of the shared traffic.  Should batman-adv automatically
stop alternating the tx/rx on these links when one of the channels
starts to get saturated?

some other info:
the supernodes may have a link directly to the main distribution
point, but may also be linked just to another supernode and not to the
main distribution point, or possibly both.

the supernodes are likely to have more than 2 mesh radios as some of
these could be direction antennas.  A supernode might have 3x 2.4Ghz
radios for mesh, 2x 5Ghz radios for mesh, and a 2.4Ghz radio for
non-mesh clients.  These would most likely all be connected to a
switch port and only be on a single ethernet interface as far as
batman-adv is concerned.

Re: [B.A.T.M.A.N.] link alternation when radios are not on batman-adv router?

[Guido Iribarren]

If i got your setup right, you plan to flash openwrt on all the
nanostations that belong to the supernode, but install batman-adv only
on the 'central' router, with a single eth nic.
In that case, batman-adv has no (manual or automatic) way of
alternating the different paths (or even knowing which packet came
trough which radio).
You should use vlans for that (i'm not sure about the performance), or
run batman-adv on each individual radio, including both the wlan and
eth0 in bat0.
This last choice will allow packets being relayed along the backbone
to skip passing through every central router on hops. They would
instead get switched directly between nanostations belonging to the
same supernode (unless, of course, the packet's destination is indeed
that 'central' router)

On 3/30/12, dan <dandenson@gmail.com> wrote:
> I have an interesting hardware setup I'd like to explore.
>
> Basically, I would like to take commodity ubiquiti and/or openmesh
> hardware and build a mesh with two different node types, some having
> just 1 radio and others having multiple radios, a standard node and a
> super node.
>
> the standard node is:
> a picostation flashed to openwrt running batman-adv and running the
> radio in Ad-Hoc mode.  Alternately an OM2P flashed to openwrt.  This
> is the basic client radio
>
> the super node is:
> a group of picostations or nanostations, flashed openwrt in adhoc
> mode, but acting only as the L2 transport with a router at the center
> running batman-adv.
>
> The idea is that the super nodes have multiple radios in multiple
> channels and can take advantage of link alternation allowing super
> nodes to keep much higher bandwidth between them while the standard
> nodes are cheap.  The 'router' MIGHT also have a radio for client
> access (unifi station flashed to openwrt maybe, or an ALIX board)
>
> The supernode will have more CPU and also be the target of
> backhaul/shorthaul links to cut down on hop count.  The main router
> would also be a batman-adv device, probably an x86 server, and would
> be the border router for the mesh.
>
> some questions,
> I know that the supernodes will have higher throughput capabilities
> due to dual mesh radios, but how will batman-adv know this or how
> would I tell it?  Is the internal mechanism for determining the best
> path going to take this into account?  Is there a way to identify a
> supernode as being a better path above and beyond the automatic
> batman-adv mechanisms?
>
> Is having separate radios connected to a batman-adv router going to
> behave how I presume?  That multiple node2node connections will be
> identified and the links be alternated when appropriate?
>
> If the supernodes have 2 mesh radios, 1 in 5Ghz and 1 in 2.4Ghz, then
> the standard nodes will only be able to connect to the 2.4Ghz channel
> which might make it inappropriate to do link alternating on these two
> links because of the shared traffic.  Should batman-adv automatically
> stop alternating the tx/rx on these links when one of the channels
> starts to get saturated?
>
> some other info:
> the supernodes may have a link directly to the main distribution
> point, but may also be linked just to another supernode and not to the
> main distribution point, or possibly both.
>
> the supernodes are likely to have more than 2 mesh radios as some of
> these could be direction antennas.  A supernode might have 3x 2.4Ghz
> radios for mesh, 2x 5Ghz radios for mesh, and a 2.4Ghz radio for
> non-mesh clients.  These would most likely all be connected to a
> switch port and only be on a single ethernet interface as far as
> batman-adv is concerned.
>

Re: [B.A.T.M.A.N.] link alternation when radios are not on batman-adv router?

[dan]

sorry if I wasnt clear, ill explain in-line:

>If i got your setup right, you plan to flash openwrt on all the
>nanostations that belong to the supernode, but install batman-adv only
>on the 'central' router, with a single eth nic.
>In that case, batman-adv has no (manual or automatic) way of
>alternating the different paths (or even knowing which packet came
>trough which radio).

ok, this is where I was unclear. You are correct that only the router
that is part of the 'supernode' runs batman-adv (at least in the
described scenario).  I didn't know if batman-adv was tracking
connections to each node or tracking interfaces.


>You should use vlans for that (i'm not sure about the performance), or
>run batman-adv on each individual radio, including both the wlan and
>eth0 in bat0.

ok, this is an option I had considered, but I'm worried that link
alternation wont be an option as the radios only have a single radio
and the alternate path is through a completely different radio/device
connected via ethernet.

As far as vlans are concerned, are you saying to have a vlan on the
router for each attached picostation and then set the picostations
ethernet interface to match that vlan?  Then I can add all the vlans
to bat0?  Alternatively, some of my options for the router have enough
ethernet ports to forgo the vlans.

>This last choice will allow packets being relayed along the backbone
>to skip passing through every central router on hops. They would
>instead get switched directly between nanostations belonging to the
>same supernode (unless, of course, the packet's destination is indeed
>that 'central' router)

sure, but by hoping through individual nanostations, the packets are
going to take a single channel.  Then the second link between nodes is
really just failover, right?

maybe if you could clarify this for me.  for link alternating, do the
two nodes need to be one hop neighbors?

according to docs, link alternating works in this scenario, where both
links are good:
node1_Link1------------node2_Link1
node1_Link2------------node2_Link2

but what about this:
node1_Link1------node3_Link1------node2_Link1
node1_Link2------node4_Link2------node2_Link2

will node1 and node2 still have link alternation?  This is basically
what the central router + picostations with the picostations running
batman-adv would look like


supernode1-------picostation1---------picostation1--------supernode2
supernode1-------picostation2---------picostation2--------supernode2

so supernode2 is then a 3 hop neighbor to supernode1.  So will link
alternation work here?  Lets just say that supernode1 has the backhaul
and supernode2 has nothing except it's link to supernode1.  Ideally,
SN2 gets the faster, dual link connection to SN1.  If not, then back
to the dedicated ports/vlan option

supernode1-bat0-vlan1-----vlan1-picostation1---------picostation1-vlan1-----vlan1-bat0-supernode2
supernode1-bat0-vlan2-----vlan2-picostation2---------picostation2-vlan2-----vlan2-bat0-supernode2
(vlan1 and vlan2 are interchangable with eth1 and eth2 in this example)

now SN1 sees SN2 is a single hop neighbor, and then I would expect
that link alternating would work.


in the scenario with dedicated ethernet ports or vlans are used to
connect the picostations, the supernode acts like a single device as
far as the mesh is concerned
in the scenario where the picostations run batman-adv as well as the
router (which might just be a switch at that point) then the supernode
is just a node cluster where ethernet is the L2 transport instead of
adhoc wireless.

Re: [B.A.T.M.A.N.] link alternation when radios are not on batman-adv router?

[Guido Iribarren]

On Fri, Mar 30, 2012 at 2:18 PM, dan <dandenson@gmail.com> wrote:

> ok, this is an option I had considered, but I'm worried that link
> alternation wont be an option as the radios only have a single radio
> and the alternate path is through a completely different radio/device
> connected via ethernet.
batman-adv makes no difference between ethernet or radio interfaces,
they are all simply just interfaces that somehow link to other
batman-adv nodes (with some -or zero- packet loss)
so link alternation would work the same: if packet comes in through
radio, and batman-adv can reach the destination through the ethernet
port (it doesn't matter if that implies hopping through more
batman-adv nodes) it will prefer sending it through this "alternate"
path (alternate in the sense it doesn't use the same interface the
packet came in)

>
> As far as vlans are concerned, are you saying to have a vlan on the
> router for each attached picostation and then set the picostations
> ethernet interface to match that vlan?  Then I can add all the vlans
> to bat0?

exactly.

> maybe if you could clarify this for me.  for link alternating, do the
> two nodes need to be one hop neighbors?
Nope, not needed. And in fact it is "interface alternation" (subtle difference).
if packet comes in through interface A, and the final destination is
reachable through 2 different paths that start at interface A and
interface B respectively, it will send the packet through interface B
to avoid reusing interface A.
It doesn't matter if between interface B and final destination there are N hops.

A long thread earlier this month was particularly clarifying on the subject.
https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2012-March/006351.html

>
> according to docs, link alternating works in this scenario, where both
> links are good:
> node1_Link1------------node2_Link1
> node1_Link2------------node2_Link2
>
> but what about this:
> node1_Link1------node3_Link1------node2_Link1
> node1_Link2------node4_Link2------node2_Link2
>
> will node1 and node2 still have link alternation?
Yes. in addition you might also be interested in interface bonding,
which is not enabled by default but can be activated after
understanding a few caveats. it's documented on batctl manpage online.

> This is basically
> what the central router + picostations with the picostations running
> batman-adv would look like
>
>
> supernode1-------picostation1---------picostation1--------supernode2
> supernode1-------picostation2---------picostation2--------supernode2
>
> so supernode2 is then a 3 hop neighbor to supernode1.  So will link
> alternation work here?  Lets just say that supernode1 has the backhaul
> and supernode2 has nothing except it's link to supernode1.  Ideally,
> SN2 gets the faster, dual link connection to SN1.

If picostations are only connected point-to-point to each other, and
there are no other clients sending traffic to them (except the
supernodes), then interface alternating won't take advantage of the
"faster dual link connection"
You must use interface bonding to achieve that.

Interface alternating would be useful, for example, if picostation2
from supernode2 was receiving a radio transmission from a distant
supernode3 (not pictured) destined at supernode1. Then, instead of
trying to relay the packets through that same picostation2, it would
use picostation1 to send them and avoid reusing the same interface.

Cheers!

Guido

Re: [B.A.T.M.A.N.] link alternation when radios are not on batman-adv router?

[Dan Denson]

 
> batman-adv makes no difference between ethernet or radio interfaces,
> they are all simply just interfaces that somehow link to other
> batman-adv nodes (with some -or zero- packet loss)
> so link alternation would work the same: if packet comes in through
> radio, and batman-adv can reach the destination through the ethernet
> port (it doesn't matter if that implies hopping through more
> batman-adv nodes) it will prefer sending it through this "alternate"
> path (alternate in the sense it doesn't use the same interface the
> packet came in)

So how does hop count come into play or does it? Is it just the connection quality that is considered?

> A long thread earlier this month was particularly clarifying on the subject.
> https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2012-March/006351.html
> 
Thanks, I'll check that out

> Yes. in addition you might also be interested in interface bonding,
> which is not enabled by default but can be activated after
> understanding a few caveats. it's documented on batctl manpage online.

I read up on bonding, I think that leaving the dynamic interface alternation is more ideal but I think I'll play with it.

> 
> If picostations are only connected point-to-point to each other, and
> there are no other clients sending traffic to them (except the
> supernodes), then interface alternating won't take advantage of the
> "faster dual link connection"
> You must use interface bonding to achieve that.
> 
> Interface alternating would be useful, for example, if picostation2
> from supernode2 was receiving a radio transmission from a distant
> supernode3 (not pictured) destined at supernode1. Then, instead of
> trying to relay the packets through that same picostation2, it would
> use picostation1 to send them and avoid reusing the same interface.
> 
> Cheers!
> 
> Guido

 I think I understand. Basically, so long as two interfaces both have a path the to destination of acceptable quality, it will send the packets out the interface that did not receive the packets. Hop count doesn't have a direct effect, we don't really care about hop count, only about link quality.

Is that the case?


If hop count doesn't really matter, how do I identify my high quality, high capacity backhauls?

Re: [B.A.T.M.A.N.] link alternation when radios are not on batman-adv router?

[Guido Iribarren]

On Sat, Mar 31, 2012 at 12:45 PM, Dan Denson <dandenson@gmail.com> wrote:
>  I think I understand. Basically, so long as two interfaces both have a path the to destination of acceptable quality, it will send the packets out the interface that did not receive the packets. Hop count doesn't have a direct effect, we don't really care about hop count, only about link quality.
>
> Is that the case?
>
>
> If hop count doesn't really matter, how do I identify my high quality, high capacity backhauls?

In batworld, by their high TQ (= AFAIU lack of packet loss to destination.)
no capacity involved in the calculations.

(but devs might correct me if i'm being too shortsighted!)

Re: [B.A.T.M.A.N.] link alternation when radios are not on batman-adv router?

[dan]

On Sat, Mar 31, 2012 at 12:11 PM, Guido Iribarren
<guidoiribarren@buenosaireslibre.org> wrote:
> On Sat, Mar 31, 2012 at 12:45 PM, Dan Denson <dandenson@gmail.com> wrote:
>>  I think I understand. Basically, so long as two interfaces both have a path the to destination of acceptable quality, it will send the packets out the interface that did not receive the packets. Hop count doesn't have a direct effect, we don't really care about hop count, only about link quality.
>>
>> Is that the case?
>>
>>
>> If hop count doesn't really matter, how do I identify my high quality, high capacity backhauls?
>
> In batworld, by their high TQ (= AFAIU lack of packet loss to destination.)
> no capacity involved in the calculations.
>
> (but devs might correct me if i'm being too shortsighted!)

according to the docs, capacity is not used in the calculation.  It is
assumed that lowest TQ is always the best route.  Hop count adds a
default '10' to the TQ which is adjustable.  I figure this means that
I can give a supernode a lower hop cost than the default 10 which
should slide the TQ in favor of using this node as the optimal path.

I also infer that this means that picostations running batman-adv that
are part of the supernode 'cluster' are going to also add a hop
penalty to the TQ.  From what I can tell though, link aggregation only
cares if a interaces/links have an acceptable TQ, not an equal TQ,
though I suspect that two picos in a supernode config would end up
providing the same hop count and similar TQ anyway, assuming solid
wireless links.

Re: [B.A.T.M.A.N.] link alternation when radios are not on batman-adv router?

[Nicolás Echániz]

On 03/31/2012 06:03 PM, dan wrote:
> On Sat, Mar 31, 2012 at 12:11 PM, Guido Iribarren
> <guidoiribarren@buenosaireslibre.org> wrote:
>> On Sat, Mar 31, 2012 at 12:45 PM, Dan Denson <dandenson@gmail.com> wrote:
>>>  I think I understand. Basically, so long as two interfaces both have a path the to destination of acceptable quality, it will send the packets out the interface that did not receive the packets. Hop count doesn't have a direct effect, we don't really care about hop count, only about link quality.
>>>
>>> Is that the case?
>>>
>>>
>>> If hop count doesn't really matter, how do I identify my high quality, high capacity backhauls?
>>
>> In batworld, by their high TQ (= AFAIU lack of packet loss to destination.)
>> no capacity involved in the calculations.
>>
>> (but devs might correct me if i'm being too shortsighted!)
> 
> according to the docs, capacity is not used in the calculation.  It is
> assumed that lowest TQ is always the best route.  Hop count adds a
> default '10' to the TQ which is adjustable.  I figure this means that
> I can give a supernode a lower hop cost than the default 10 which
> should slide the TQ in favor of using this node as the optimal path.
> 
> I also infer that this means that picostations running batman-adv that
> are part of the supernode 'cluster' are going to also add a hop
> penalty to the TQ.  From what I can tell though, link aggregation only
> cares if a interaces/links have an acceptable TQ, not an equal TQ,
> though I suspect that two picos in a supernode config would end up
> providing the same hop count and similar TQ anyway, assuming solid
> wireless links.

it's a tricky task to try and convince batman-adv to favour certain routes.

Our strategy in QuintanaLibre has been to lower the hop penalty but also
to increase multicast rate where necessary.

This effectively "invisibilizes" some links for batman.

You should use this with care, mainly if you are playing with it
remotely because you may be left out of a portion of your network.

We have reduced hop_penalty to zero on certain "preferred" nodes and
also increased mcast_rate where necessary.

Your mcast_rate can actually be heterogeneous across the network.

For example, we have an Ubiquiti BulletM2 with a 14db panel antenna
which is "seen" even by the furthest node, which establishes a low rate
link that has low throughput but looses very few packets, so batman
"thinks" it's actually a good route when in practice it's not.

So we set the Bullet mcast_rate high like so:

config 'wifi-iface'
	option 'device' 'radio0'
	option 'mcast_rate' '54000'
        ...

and then only those nodes than can establish a really good link to the
Bullet will see it as a valid route while others will ignore it.


It took a lot of time to find out this subtleties and we don't even know
if this is the "canonical" method but it does work very well to discard
undesired low rate routes.

In your setup, I think you could increase hop penalty for your
picostations, lower the hop penalty for your supernodes and also set
their mcast_rate high, so that picostations won't choose to route
directly to a far supernode but rather send traffic to their nearest
supernode which will have a solid route to the next one...  that is if I
correctly understood what you are trying to accomplish.



Please share your findings on these matters, as we may all profit from
each other's experimentation work!


Cheers,
NicoEchániz

Re: [B.A.T.M.A.N.] [OT] ruci / Was: link alternation when radios are not on batman-adv router?

[Nicolás Echániz]

On 03/31/2012 10:31 PM, Nicolás Echániz wrote:

> This effectively "invisibilizes" some links for batman.
> 
> You should use this with care, mainly if you are playing with it
> remotely because you may be left out of a portion of your network.

One more thing, not specific to batman, but useful for the kind of
experimentation you might be doing in the near future.

We (QuintanaLibre and DeltaLibre) have designed a tool for "fail-proof"
remote administration of OpenWRT nodes, which Guido (also participating
in this thread) has developed and maintains.

It's called ruci (for remote uci) and it has many useful features:

1) uses a centralized mercurial repository to store all your nodes
configuration.
2) can "pull" configurations from nodes at any time into the repo.
3) can push configuration changes to a node or set of nodes.
4) can compare configuration status between repo and nodes.
5) can always revert nodes or the whole network to any previous state
(provided by mercurial), as long as you keep a useful commit policy.


When new configuration is pushed, the remote router updates and reboots
(we found this to be safer than just restarting services). It then boots
with the new configuration and a 10min. revert timer, which triggers
unless you confirm the changes.

This simple method provides enormous experimentation possibilities. You
can, for example modify your entire network's IP addressing policy in
your local configs repo and then push the change simultaneously. If
something goes wrong, the routers will revert configuration and reboot
in 10 min.; if everythig went well, you can just confirm your changes
during the "revert window" to make them permanent.


You don't need to use uci locally, you may just edit config files by
hand and push them, but uci really comes in handy to avoid human error
when making changes or to implement some modifications programatically.


Guido might like to add some more detail, but that's a short description
of ruci[0].


Anyone who would like to test it, and might need some initial guidance
(mainly to set up things, the rest is self-explanatory), just drop guido
or me an e-mail and we will gladly help you out. There's no list or
forum yet...


Cheers,
NicoEchániz



[0] http://bitbucket.org/guidoi/ruci

Re: [B.A.T.M.A.N.] [OT] ruci / Was: link alternation when radios are not on batman-adv router?

[dan]

2012/3/31 Nicolás Echániz <nicoechaniz@codigosur.org>:
> on status between repo and nodes.
> 5) can always revert nodes or the whole network to any previous state
> (provided by mercurial), as long as you keep a useful commit

Thanks for the comments and suggestion.  I will definitely check this out.

I think I am going to use the mikrotik rb751 flashed to openwrt for
the supernode tests.  They have 5 ethernet ports that can be addressed
individually as well as wireless that I can bridge in for client
access.  Picostations for the standard nodes and for the radio
interfaces on the supernode.  I'll do 2.4Ghz for all local meshing and
5Ghz for the links between supernodes and the backhauls.

Re: [B.A.T.M.A.N.] link alternation when radios are not on batman-adv router?

[gtolon]

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

Hi,

     we are interested too in interface alternating, so we made some 
tests to understand how it works. As you can see on the attached 
sketch.png, we connected two pair of routers using their ethernet 
interfaces, E6 with E7, and E8 with E9. All of them have eth0, and an ad 
hoc interface, wlan0-1, managed by batman. E6 and E8 are in channel 11, 
whereas E7 and E9 are in channel 1. Besides we used two other routers, 
E12 and E13, both in channel 11, with their tx power set to just 0 dbm, 
to avoid a direct sight between them.

     Then we sent traffic from E12 to E13. We expected that packets 
travelled from E12 to E6, and that E6 forwarded them to his eth0 to use 
the interface alternating feature, making traffic flow to E7, then E9, 
E8 and finally E13. But instead, we observed that the actual path was 
E12--E6--E8--E13. The resulting routes for each router are attached in a 
text file, and also the graph from the batctl vd dot command.

     After this result, we read again the thread mentioned by Guido, 
specially in this part:

https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2012-March/006344.html

    And if we understand correctly, the alternation feature works after 
the batman path has been selected. So in our case, E12 looks at his 
table to know where to send a packet to E13, and finds E6. Then E6 
receives the packet and looks in his own table, finding that the best 
path to reach E13 is E8. At this point, the alternating should work, but 
there's only one interface directly connected to E8, so the packet goes 
there, and so on. We think that if E6 and E7 were not two different 
routers running batman-adv but they were two radios of the same 
batman-adv router, and the same for E8 and E9, the alternating would 
work, because the unique router would choose the best path, and then 
would find two possible interfaces to the same next-hop, changing the 
interface.

     We'd like to know if this interpretation is correct, and in that 
case, if it were possible to use interface alternating in a case like 
this, with two routers connected to work together. Thanks!

Gabriel


El 31/03/2012 12:48 a.m., Guido Iribarren escribió:
> On Fri, Mar 30, 2012 at 2:18 PM, dan<dandenson@gmail.com>  wrote:
>
>> ok, this is an option I had considered, but I'm worried that link
>> alternation wont be an option as the radios only have a single radio
>> and the alternate path is through a completely different radio/device
>> connected via ethernet.
> batman-adv makes no difference between ethernet or radio interfaces,
> they are all simply just interfaces that somehow link to other
> batman-adv nodes (with some -or zero- packet loss)
> so link alternation would work the same: if packet comes in through
> radio, and batman-adv can reach the destination through the ethernet
> port (it doesn't matter if that implies hopping through more
> batman-adv nodes) it will prefer sending it through this "alternate"
> path (alternate in the sense it doesn't use the same interface the
> packet came in)
>
>> As far as vlans are concerned, are you saying to have a vlan on the
>> router for each attached picostation and then set the picostations
>> ethernet interface to match that vlan?  Then I can add all the vlans
>> to bat0?
> exactly.
>
>> maybe if you could clarify this for me.  for link alternating, do the
>> two nodes need to be one hop neighbors?
> Nope, not needed. And in fact it is "interface alternation" (subtle difference).
> if packet comes in through interface A, and the final destination is
> reachable through 2 different paths that start at interface A and
> interface B respectively, it will send the packet through interface B
> to avoid reusing interface A.
> It doesn't matter if between interface B and final destination there are N hops.
>
> A long thread earlier this month was particularly clarifying on the subject.
> https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2012-March/006351.html
>
>> according to docs, link alternating works in this scenario, where both
>> links are good:
>> node1_Link1------------node2_Link1
>> node1_Link2------------node2_Link2
>>
>> but what about this:
>> node1_Link1------node3_Link1------node2_Link1
>> node1_Link2------node4_Link2------node2_Link2
>>
>> will node1 and node2 still have link alternation?
> Yes. in addition you might also be interested in interface bonding,
> which is not enabled by default but can be activated after
> understanding a few caveats. it's documented on batctl manpage online.
>
>>   This is basically
>> what the central router + picostations with the picostations running
>> batman-adv would look like
>>
>>
>> supernode1-------picostation1---------picostation1--------supernode2
>> supernode1-------picostation2---------picostation2--------supernode2
>>
>> so supernode2 is then a 3 hop neighbor to supernode1.  So will link
>> alternation work here?  Lets just say that supernode1 has the backhaul
>> and supernode2 has nothing except it's link to supernode1.  Ideally,
>> SN2 gets the faster, dual link connection to SN1.
> If picostations are only connected point-to-point to each other, and
> there are no other clients sending traffic to them (except the
> supernodes), then interface alternating won't take advantage of the
> "faster dual link connection"
> You must use interface bonding to achieve that.
>
> Interface alternating would be useful, for example, if picostation2
> from supernode2 was receiving a radio transmission from a distant
> supernode3 (not pictured) destined at supernode1. Then, instead of
> trying to relay the packets through that same picostation2, it would
> use picostation1 to send them and avoid reusing the same interface.
>
> Cheers!
>
> Guido
>

[-- Attachment #2: sketch.png --]
[-- Type: image/png, Size: 13907 bytes --]

[-- Attachment #3: rutas9 --]
[-- Type: text/plain, Size: 5020 bytes --]

rutas9.png


E6:

[B.A.T.M.A.N. adv 2012.0.0, MainIF/MAC: wlan0-1/fa:d1:11:24:54:5d (bat0)]
  Originator      last-seen (#/255)           Nexthop [outgoingIF]:   Potential nexthops ...
       E9-wlan0-1    0.950s   (245)        E8-wlan0-1 [   wlan0-1]:           E7-eth0 (240)        E8-wlan0-1 (245)
       E8-wlan0-1    0.550s   (255)        E8-wlan0-1 [   wlan0-1]:           E7-eth0 (235)       E12-wlan0-1 (235)        E8-wlan0-1 (255)
      E13-wlan0-1    0.570s   (234)        E8-wlan0-1 [   wlan0-1]:           E7-eth0 (216)        E8-wlan0-1 (234)
      E12-wlan0-1    0.780s   (255)       E12-wlan0-1 [   wlan0-1]:       E12-wlan0-1 (255)
          E7-eth0    0.230s   (255)           E7-eth0 [      eth0]:           E7-eth0 (255)
       E7-wlan0-1    0.570s   (255)           E7-eth0 [      eth0]:           E7-eth0 (255)        E8-wlan0-1 (  0)


E7:

[B.A.T.M.A.N. adv 2012.0.0, MainIF/MAC: wlan0-1/fa:d1:11:24:54:83 (bat0)]
  Originator      last-seen (#/255)           Nexthop [outgoingIF]:   Potential nexthops ...
       E9-wlan0-1    0.130s   (249)        E9-wlan0-1 [   wlan0-1]:           E6-eth0 (235)        E9-wlan0-1 (249)
       E6-wlan0-1    0.340s   (253)           E6-eth0 [      eth0]:           E6-eth0 (253)        E9-wlan0-1 (208)
       E8-wlan0-1    0.810s   (245)           E6-eth0 [      eth0]:           E6-eth0 (245)        E9-wlan0-1 (236)
      E13-wlan0-1    0.730s   (224)           E6-eth0 [      eth0]:           E6-eth0 (224)        E9-wlan0-1 (218)
      E12-wlan0-1    0.940s   (245)           E6-eth0 [      eth0]:           E6-eth0 (245)        E9-wlan0-1 (197)
          E6-eth0    0.620s   (255)           E6-eth0 [      eth0]:           E6-eth0 (255)


E8:

[B.A.T.M.A.N. adv 2012.0.0, MainIF/MAC: wlan0-1/fa:d1:11:24:59:a7 (bat0)]
  Originator      last-seen (#/255)           Nexthop [outgoingIF]:   Potential nexthops ...
       E9-wlan0-1    0.810s   (255)           E9-eth0 [      eth0]:        E6-wlan0-1 (208)           E9-eth0 (255)
          E9-eth0    0.050s   (255)           E9-eth0 [      eth0]:           E9-eth0 (255)
       E6-wlan0-1    0.850s   (221)        E6-wlan0-1 [   wlan0-1]:           E9-eth0 (  0)       E13-wlan0-1 (  0)        E6-wlan0-1 (221)
      E13-wlan0-1    0.410s   (246)       E13-wlan0-1 [   wlan0-1]:        E6-wlan0-1 (192)       E13-wlan0-1 (246)
      E12-wlan0-1    0.410s   (212)        E6-wlan0-1 [   wlan0-1]:           E9-eth0 (  0)        E6-wlan0-1 (212)
       E7-wlan0-1    0.200s   (224)           E9-eth0 [      eth0]:        E6-wlan0-1 (211)           E9-eth0 (224)

E9:

[B.A.T.M.A.N. adv 2012.0.0, MainIF/MAC: wlan0-1/fa:d1:11:24:5a:95 (bat0)]
  Originator      last-seen (#/255)           Nexthop [outgoingIF]:   Potential nexthops ...
       E6-wlan0-1    0.370s   (222)        E7-wlan0-1 [   wlan0-1]:        E7-wlan0-1 (222)           E8-eth0 (210)
       E8-wlan0-1    0.920s   (255)           E8-eth0 [      eth0]:        E7-wlan0-1 (215)           E8-eth0 (255)
      E13-wlan0-1    0.840s   (236)           E8-eth0 [      eth0]:        E7-wlan0-1 (199)           E8-eth0 (236)
      E12-wlan0-1    0.920s   (215)        E7-wlan0-1 [   wlan0-1]:        E7-wlan0-1 (215)           E8-eth0 (203)
          E8-eth0    0.970s   (255)           E8-eth0 [      eth0]:           E8-eth0 (255)
       E7-wlan0-1    0.630s   (234)        E7-wlan0-1 [   wlan0-1]:           E8-eth0 (215)        E7-wlan0-1 (234)


E12:

[B.A.T.M.A.N. adv 2012.0.0, MainIF/MAC: wlan0-1/fa:d1:11:24:54:7f (bat0)]
  Originator      last-seen (#/255)           Nexthop [outgoingIF]:   Potential nexthops ...
       E9-wlan0-1    0.510s   (235)        E6-wlan0-1 [   wlan0-1]:        E6-wlan0-1 (235)
       E6-wlan0-1    0.770s   (255)        E6-wlan0-1 [   wlan0-1]:        E6-wlan0-1 (255)
       E8-wlan0-1    0.200s   (245)        E6-wlan0-1 [   wlan0-1]:        E6-wlan0-1 (245)        E8-wlan0-1 (  0)
      E13-wlan0-1    0.090s   (225)        E6-wlan0-1 [   wlan0-1]:        E6-wlan0-1 (225)
       E7-wlan0-1    0.090s   (245)        E6-wlan0-1 [   wlan0-1]:        E6-wlan0-1 (245)

E13:

[B.A.T.M.A.N. adv 2012.0.0, MainIF/MAC: wlan0-1/fa:d1:11:24:53:47 (bat0)]
  Originator      last-seen (#/255)           Nexthop [outgoingIF]:   Potential nexthops ...
       E9-wlan0-1    0.460s   (245)        E8-wlan0-1 [   wlan0-1]:        E8-wlan0-1 (245)
       E6-wlan0-1    0.710s   (206)        E8-wlan0-1 [   wlan0-1]:        E8-wlan0-1 (206)        E6-wlan0-1 (  0)
       E8-wlan0-1    0.160s   (250)        E8-wlan0-1 [   wlan0-1]:        E8-wlan0-1 (250)
      E12-wlan0-1    0.270s   (193)        E8-wlan0-1 [   wlan0-1]:        E8-wlan0-1 (193)
       E7-wlan0-1    0.060s   (216)        E8-wlan0-1 [   wlan0-1]:        E8-wlan0-1 (216)


TR E12:

traceroute to E13-wlan0-1 (fa:d1:11:24:53:47), 50 hops max, 20 byte packets
 1: E6-wlan0-1 (fa:d1:11:24:54:5d)  0.791 ms  0.820 ms  0.596 ms
 2: E8-wlan0-1 (fa:d1:11:24:59:a7)  1.889 ms  2.815 ms  1.613 ms
 3: E13-wlan0-1 (fa:d1:11:24:53:47)  2.472 ms  4.252 ms  5.048 ms



[-- Attachment #4: rutas.jpg --]
[-- Type: image/jpeg, Size: 47283 bytes --]

Re: [B.A.T.M.A.N.] link alternation when radios are not on batman-adv router?

[Simon Wunderlich]

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

On Thu, Jun 14, 2012 at 04:51:01PM -0300, gtolon@inti.gob.ar wrote:
> Hi,
> 
>     we are interested too in interface alternating, so we made some
> tests to understand how it works. As you can see on the attached
> sketch.png, we connected two pair of routers using their ethernet
> interfaces, E6 with E7, and E8 with E9. All of them have eth0, and
> an ad hoc interface, wlan0-1, managed by batman. E6 and E8 are in
> channel 11, whereas E7 and E9 are in channel 1. Besides we used two
> other routers, E12 and E13, both in channel 11, with their tx power
> set to just 0 dbm, to avoid a direct sight between them.
> 
>     Then we sent traffic from E12 to E13. We expected that packets
> travelled from E12 to E6, and that E6 forwarded them to his eth0 to
> use the interface alternating feature, making traffic flow to E7,
> then E9, E8 and finally E13. But instead, we observed that the
> actual path was E12--E6--E8--E13. The resulting routes for each
> router are attached in a text file, and also the graph from the
> batctl vd dot command.
> 
>     After this result, we read again the thread mentioned by Guido,
> specially in this part:
> 
> https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2012-March/006344.html
> 
>    And if we understand correctly, the alternation feature works
> after the batman path has been selected. So in our case, E12 looks
> at his table to know where to send a packet to E13, and finds E6.
> Then E6 receives the packet and looks in his own table, finding that
> the best path to reach E13 is E8. At this point, the alternating
> should work, but there's only one interface directly connected to
> E8, so the packet goes there, and so on. We think that if E6 and E7
> were not two different routers running batman-adv but they were two
> radios of the same batman-adv router, and the same for E8 and E9,
> the alternating would work, because the unique router would choose
> the best path, and then would find two possible interfaces to the
> same next-hop, changing the interface.

This is entirely correct - batman-adv has only one link to choose from
(E6 -> E8) to reach its best nexthop E8, so there is no way to
"alternate" the interfaces.

>     We'd like to know if this interpretation is correct, and in that
> case, if it were possible to use interface alternating in a case
> like this, with two routers connected to work together. Thanks!

Mhm, with the current implementation - no, unfortunately not. We would
need some kind of multipath routing to select between routes, this is
much more complex.

An alternative might be to use the routers E7/E9 as secondary routers
without batman, but only forwarding traffic between Ethernet and
WiFi. Then the "primary" routers (E6 -> E8) would think they have
an alternative route via Ethernet (because they don't see the
intermediate hops E7/E9). This comes with some caveats however, e.g.
4-addr mode in Ad-Hoc, you need some very simple ethernet forwarder,
and most probably other things I forgot.

Cheers,
	Simon


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [B.A.T.M.A.N.] link alternation when radios are not on batman-adv router?

[gtolon]

Hi Simon, thanks for your reply!


El 15/06/2012 06:55 a.m., Simon Wunderlich escribió:
> On Thu, Jun 14, 2012 at 04:51:01PM -0300, gtolon@inti.gob.ar wrote:
>> Hi,
>>
>>      we are interested too in interface alternating, so we made some
>> tests to understand how it works. As you can see on the attached
>> sketch.png, we connected two pair of routers using their ethernet
>> interfaces, E6 with E7, and E8 with E9. All of them have eth0, and
>> an ad hoc interface, wlan0-1, managed by batman. E6 and E8 are in
>> channel 11, whereas E7 and E9 are in channel 1. Besides we used two
>> other routers, E12 and E13, both in channel 11, with their tx power
>> set to just 0 dbm, to avoid a direct sight between them.
>>
>>      Then we sent traffic from E12 to E13. We expected that packets
>> travelled from E12 to E6, and that E6 forwarded them to his eth0 to
>> use the interface alternating feature, making traffic flow to E7,
>> then E9, E8 and finally E13. But instead, we observed that the
>> actual path was E12--E6--E8--E13. The resulting routes for each
>> router are attached in a text file, and also the graph from the
>> batctl vd dot command.
>>
>>      After this result, we read again the thread mentioned by Guido,
>> specially in this part:
>>
>> https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2012-March/006344.html
>>
>>     And if we understand correctly, the alternation feature works
>> after the batman path has been selected. So in our case, E12 looks
>> at his table to know where to send a packet to E13, and finds E6.
>> Then E6 receives the packet and looks in his own table, finding that
>> the best path to reach E13 is E8. At this point, the alternating
>> should work, but there's only one interface directly connected to
>> E8, so the packet goes there, and so on. We think that if E6 and E7
>> were not two different routers running batman-adv but they were two
>> radios of the same batman-adv router, and the same for E8 and E9,
>> the alternating would work, because the unique router would choose
>> the best path, and then would find two possible interfaces to the
>> same next-hop, changing the interface.
> This is entirely correct - batman-adv has only one link to choose from
> (E6 ->  E8) to reach its best nexthop E8, so there is no way to
> "alternate" the interfaces.
>
>>      We'd like to know if this interpretation is correct, and in that
>> case, if it were possible to use interface alternating in a case
>> like this, with two routers connected to work together. Thanks!
> Mhm, with the current implementation - no, unfortunately not. We would
> need some kind of multipath routing to select between routes, this is
> much more complex.

Ok, i understand.

>
> An alternative might be to use the routers E7/E9 as secondary routers
> without batman, but only forwarding traffic between Ethernet and
> WiFi. Then the "primary" routers (E6 ->  E8) would think they have
> an alternative route via Ethernet (because they don't see the
> intermediate hops E7/E9). This comes with some caveats however, e.g.
> 4-addr mode in Ad-Hoc, you need some very simple ethernet forwarder,
> and most probably other things I forgot.

We had tried with something like that using ap and sta modes in E7 and 
E9, and it hadn't worked. Thanks to your suggestion we noticed the 
necessity of the 4-address mode, so we are now trying with wds:

http://wiki.openwrt.org/doc/recipes/atheroswds

Unfortunately, we haven't found yet a way to use 4-address mode in ad 
hoc. Apparentrly, it's not possible:

http://linuxwireless.org/en/users/Documentation/iw#Using_4-address_for_AP_and_client_mode

Best Regards

Gabriel

Re: [B.A.T.M.A.N.] link alternation when radios are not on batman-adv router?

[gtolon]

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

Hi.

We've been trying two different configurations to use link alternation 
with two routers conected via ethernet. In both cases in each pair of 
routers one runs batman and the other only forwards traffic between 
ethernet and wifi, as Simon suggested:

1) First in the forwarding routers we configured an AP and a station, 
both using wds. The idea was to form a chain of pairs of routers, where 
each forwarding router were connected to the previous and the next 
forwarder using those sta and AP interfaces, as can be seen in 
conf_1.png. Unfortunately we found that with this configuration the 
broadcast batman packets were forwarded through all the chain without 
any batman processing. For example, Batman 1 sends an Originator which 
goes out through its ad hoc interface, and also through ethernet, then 
Forward 1 sends it through its sta to Forward 2. In Forward 2 the sta, 
ap and ethernet interfaces are bridged, so the Originator goes to Batman 
2 via ethernet (that's ok) but also goes directly to Forward 3 without 
the hop penalty applied. As a result Batman 3 sees the ethernet 
interface of Batman 1 as a direct neighbour with a good quality. In a 
longer chain the result would be the same.

2) A solution to the first configuration could be use some ebtables 
rules, but using ebtables we directly tried with normal ad hoc 
interfaces. So we used the configuration seen in conf_2.png. We cloned 
the MACs of the Batman ethernet interfaces to the ad hoc interfaces. 
That way the packets destined by Batman to the ethernet interfaces of 
their neighbours enter through the wireless interfaces because they have 
the same MAC. Once inside the Forwarding routers we use this rule:

  ebtables -t broute -A BROUTING -i wlan0 -d <MAC1> -j dnat --to-dst 
<MACX> --dnat-target ACCEPT

So changing the dst MAC the packets are forwarded through ethernet. In 
the BATMAN routers we used this rule to change again the dst MAC:

  ebtables -t broute -A BROUTING -i eth0 -d <MACX> -j dnat --to-dst 
<MAC1> --dnat-target ACCEPT

For using ebtables with Batman we had to attach eth0 to a bridge, and 
add that bridge to batman. In the normal configuration with batman 
managing eth0 it doesn't work.
For the reverse path, packets entering to Forwarding routers from Batman 
routers it wasn't necessary to use any rule, we just saw many warnings 
advicing that packets with own address as source address were received.

We had read in openwrt forum that ebtables could cause performance 
issues on routers, but we didn't notice a great difference in the tests 
we've made with iperf up to now.

The problem that we are facing now is the impossibility of increasing 
the MTU of ethernet interfaces in the routers. We saw this patch:

http://permalink.gmane.org/gmane.comp.embedded.openwrt.devel/14678

and thought that maybe we could increase a bit more the MTU, but we 
couldn't. So the other possibility is to decrease all the other 
interfaces MTU to 1470 and let the ethernet to 1500 right? We guess that 
could cause IP fragmentation in some cases.

I hope my explanations are understandable.

Best regards!

Gabriel

El 18/06/2012 03:46 p.m., gtolon@inti.gob.ar escribió:
> Hi Simon, thanks for your reply!
>
>
> El 15/06/2012 06:55 a.m., Simon Wunderlich escribió:
>> On Thu, Jun 14, 2012 at 04:51:01PM -0300, gtolon@inti.gob.ar wrote:
>>> Hi,
>>>
>>>      we are interested too in interface alternating, so we made some
>>> tests to understand how it works. As you can see on the attached
>>> sketch.png, we connected two pair of routers using their ethernet
>>> interfaces, E6 with E7, and E8 with E9. All of them have eth0, and
>>> an ad hoc interface, wlan0-1, managed by batman. E6 and E8 are in
>>> channel 11, whereas E7 and E9 are in channel 1. Besides we used two
>>> other routers, E12 and E13, both in channel 11, with their tx power
>>> set to just 0 dbm, to avoid a direct sight between them.
>>>
>>>      Then we sent traffic from E12 to E13. We expected that packets
>>> travelled from E12 to E6, and that E6 forwarded them to his eth0 to
>>> use the interface alternating feature, making traffic flow to E7,
>>> then E9, E8 and finally E13. But instead, we observed that the
>>> actual path was E12--E6--E8--E13. The resulting routes for each
>>> router are attached in a text file, and also the graph from the
>>> batctl vd dot command.
>>>
>>>      After this result, we read again the thread mentioned by Guido,
>>> specially in this part:
>>>
>>> https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2012-March/006344.html 
>>>
>>>
>>>     And if we understand correctly, the alternation feature works
>>> after the batman path has been selected. So in our case, E12 looks
>>> at his table to know where to send a packet to E13, and finds E6.
>>> Then E6 receives the packet and looks in his own table, finding that
>>> the best path to reach E13 is E8. At this point, the alternating
>>> should work, but there's only one interface directly connected to
>>> E8, so the packet goes there, and so on. We think that if E6 and E7
>>> were not two different routers running batman-adv but they were two
>>> radios of the same batman-adv router, and the same for E8 and E9,
>>> the alternating would work, because the unique router would choose
>>> the best path, and then would find two possible interfaces to the
>>> same next-hop, changing the interface.
>> This is entirely correct - batman-adv has only one link to choose from
>> (E6 ->  E8) to reach its best nexthop E8, so there is no way to
>> "alternate" the interfaces.
>>
>>>      We'd like to know if this interpretation is correct, and in that
>>> case, if it were possible to use interface alternating in a case
>>> like this, with two routers connected to work together. Thanks!
>> Mhm, with the current implementation - no, unfortunately not. We would
>> need some kind of multipath routing to select between routes, this is
>> much more complex.
>
> Ok, i understand.
>
>>
>> An alternative might be to use the routers E7/E9 as secondary routers
>> without batman, but only forwarding traffic between Ethernet and
>> WiFi. Then the "primary" routers (E6 ->  E8) would think they have
>> an alternative route via Ethernet (because they don't see the
>> intermediate hops E7/E9). This comes with some caveats however, e.g.
>> 4-addr mode in Ad-Hoc, you need some very simple ethernet forwarder,
>> and most probably other things I forgot.
>
> We had tried with something like that using ap and sta modes in E7 and 
> E9, and it hadn't worked. Thanks to your suggestion we noticed the 
> necessity of the 4-address mode, so we are now trying with wds:
>
> http://wiki.openwrt.org/doc/recipes/atheroswds
>
> Unfortunately, we haven't found yet a way to use 4-address mode in ad 
> hoc. Apparentrly, it's not possible:
>
> http://linuxwireless.org/en/users/Documentation/iw#Using_4-address_for_AP_and_client_mode 
>
>
> Best Regards
>
> Gabriel

[-- Attachment #2: conf_1.png --]
[-- Type: image/png, Size: 11955 bytes --]

[-- Attachment #3: conf_2.png --]
[-- Type: image/png, Size: 12091 bytes --]

Re: [B.A.T.M.A.N.] link alternation when radios are not on batman-adv router?

[Guido Iribarren]

You can try taking eth0 out of the bridge and adding it to bat0
that way you wouldn't need to mess with ebtables?
As there would be no bridged interfaces, batman would be the only one
forwarding packets between eth0 and wlan0. With hop penalty.

On 7/13/12, gtolon@inti.gob.ar <gtolon@inti.gob.ar> wrote:
> Hi.
>
> We've been trying two different configurations to use link alternation
> with two routers conected via ethernet. In both cases in each pair of
> routers one runs batman and the other only forwards traffic between
> ethernet and wifi, as Simon suggested:
>
> 1) First in the forwarding routers we configured an AP and a station,
> both using wds. The idea was to form a chain of pairs of routers, where
> each forwarding router were connected to the previous and the next
> forwarder using those sta and AP interfaces, as can be seen in
> conf_1.png. Unfortunately we found that with this configuration the
> broadcast batman packets were forwarded through all the chain without
> any batman processing. For example, Batman 1 sends an Originator which
> goes out through its ad hoc interface, and also through ethernet, then
> Forward 1 sends it through its sta to Forward 2. In Forward 2 the sta,
> ap and ethernet interfaces are bridged, so the Originator goes to Batman
> 2 via ethernet (that's ok) but also goes directly to Forward 3 without
> the hop penalty applied. As a result Batman 3 sees the ethernet
> interface of Batman 1 as a direct neighbour with a good quality. In a
> longer chain the result would be the same.
>
> 2) A solution to the first configuration could be use some ebtables
> rules, but using ebtables we directly tried with normal ad hoc
> interfaces. So we used the configuration seen in conf_2.png. We cloned
> the MACs of the Batman ethernet interfaces to the ad hoc interfaces.
> That way the packets destined by Batman to the ethernet interfaces of
> their neighbours enter through the wireless interfaces because they have
> the same MAC. Once inside the Forwarding routers we use this rule:
>
>   ebtables -t broute -A BROUTING -i wlan0 -d <MAC1> -j dnat --to-dst
> <MACX> --dnat-target ACCEPT
>
> So changing the dst MAC the packets are forwarded through ethernet. In
> the BATMAN routers we used this rule to change again the dst MAC:
>
>   ebtables -t broute -A BROUTING -i eth0 -d <MACX> -j dnat --to-dst
> <MAC1> --dnat-target ACCEPT
>
> For using ebtables with Batman we had to attach eth0 to a bridge, and
> add that bridge to batman. In the normal configuration with batman
> managing eth0 it doesn't work.
> For the reverse path, packets entering to Forwarding routers from Batman
> routers it wasn't necessary to use any rule, we just saw many warnings
> advicing that packets with own address as source address were received.
>
> We had read in openwrt forum that ebtables could cause performance
> issues on routers, but we didn't notice a great difference in the tests
> we've made with iperf up to now.
>
> The problem that we are facing now is the impossibility of increasing
> the MTU of ethernet interfaces in the routers. We saw this patch:
>
> http://permalink.gmane.org/gmane.comp.embedded.openwrt.devel/14678
>
> and thought that maybe we could increase a bit more the MTU, but we
> couldn't. So the other possibility is to decrease all the other
> interfaces MTU to 1470 and let the ethernet to 1500 right? We guess that
> could cause IP fragmentation in some cases.
>
> I hope my explanations are understandable.
>
> Best regards!
>
> Gabriel
>
> El 18/06/2012 03:46 p.m., gtolon@inti.gob.ar escribió:
>> Hi Simon, thanks for your reply!
>>
>>
>> El 15/06/2012 06:55 a.m., Simon Wunderlich escribió:
>>> On Thu, Jun 14, 2012 at 04:51:01PM -0300, gtolon@inti.gob.ar wrote:
>>>> Hi,
>>>>
>>>>      we are interested too in interface alternating, so we made some
>>>> tests to understand how it works. As you can see on the attached
>>>> sketch.png, we connected two pair of routers using their ethernet
>>>> interfaces, E6 with E7, and E8 with E9. All of them have eth0, and
>>>> an ad hoc interface, wlan0-1, managed by batman. E6 and E8 are in
>>>> channel 11, whereas E7 and E9 are in channel 1. Besides we used two
>>>> other routers, E12 and E13, both in channel 11, with their tx power
>>>> set to just 0 dbm, to avoid a direct sight between them.
>>>>
>>>>      Then we sent traffic from E12 to E13. We expected that packets
>>>> travelled from E12 to E6, and that E6 forwarded them to his eth0 to
>>>> use the interface alternating feature, making traffic flow to E7,
>>>> then E9, E8 and finally E13. But instead, we observed that the
>>>> actual path was E12--E6--E8--E13. The resulting routes for each
>>>> router are attached in a text file, and also the graph from the
>>>> batctl vd dot command.
>>>>
>>>>      After this result, we read again the thread mentioned by Guido,
>>>> specially in this part:
>>>>
>>>> https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2012-March/006344.html
>>>>
>>>>
>>>>
>>>>     And if we understand correctly, the alternation feature works
>>>> after the batman path has been selected. So in our case, E12 looks
>>>> at his table to know where to send a packet to E13, and finds E6.
>>>> Then E6 receives the packet and looks in his own table, finding that
>>>> the best path to reach E13 is E8. At this point, the alternating
>>>> should work, but there's only one interface directly connected to
>>>> E8, so the packet goes there, and so on. We think that if E6 and E7
>>>> were not two different routers running batman-adv but they were two
>>>> radios of the same batman-adv router, and the same for E8 and E9,
>>>> the alternating would work, because the unique router would choose
>>>> the best path, and then would find two possible interfaces to the
>>>> same next-hop, changing the interface.
>>> This is entirely correct - batman-adv has only one link to choose from
>>> (E6 ->  E8) to reach its best nexthop E8, so there is no way to
>>> "alternate" the interfaces.
>>>
>>>>      We'd like to know if this interpretation is correct, and in that
>>>> case, if it were possible to use interface alternating in a case
>>>> like this, with two routers connected to work together. Thanks!
>>> Mhm, with the current implementation - no, unfortunately not. We would
>>> need some kind of multipath routing to select between routes, this is
>>> much more complex.
>>
>> Ok, i understand.
>>
>>>
>>> An alternative might be to use the routers E7/E9 as secondary routers
>>> without batman, but only forwarding traffic between Ethernet and
>>> WiFi. Then the "primary" routers (E6 ->  E8) would think they have
>>> an alternative route via Ethernet (because they don't see the
>>> intermediate hops E7/E9). This comes with some caveats however, e.g.
>>> 4-addr mode in Ad-Hoc, you need some very simple ethernet forwarder,
>>> and most probably other things I forgot.
>>
>> We had tried with something like that using ap and sta modes in E7 and
>> E9, and it hadn't worked. Thanks to your suggestion we noticed the
>> necessity of the 4-address mode, so we are now trying with wds:
>>
>> http://wiki.openwrt.org/doc/recipes/atheroswds
>>
>> Unfortunately, we haven't found yet a way to use 4-address mode in ad
>> hoc. Apparentrly, it's not possible:
>>
>> http://linuxwireless.org/en/users/Documentation/iw#Using_4-address_for_AP_and_client_mode
>>
>>
>>
>> Best Regards
>>
>> Gabriel
>

Re: [B.A.T.M.A.N.] link alternation when radios are not on batman-adv router?

[Guido Iribarren]

Ah, i missed this sentence
"In the normal configuration with batman managing eth0 it doesn't work."
why? How was the setup? Which batman version?
I came across something like this (reported in a previous thread) but
so far i haven't had spare time to reproduce it again to debug it.

On 7/14/12, Guido Iribarren <guidoiribarren@buenosaireslibre.org> wrote:
> You can try taking eth0 out of the bridge and adding it to bat0
> that way you wouldn't need to mess with ebtables?
> As there would be no bridged interfaces, batman would be the only one
> forwarding packets between eth0 and wlan0. With hop penalty.
>
> On 7/13/12, gtolon@inti.gob.ar <gtolon@inti.gob.ar> wrote:
>> Hi.
>>
>> We've been trying two different configurations to use link alternation
>> with two routers conected via ethernet. In both cases in each pair of
>> routers one runs batman and the other only forwards traffic between
>> ethernet and wifi, as Simon suggested:
>>
>> 1) First in the forwarding routers we configured an AP and a station,
>> both using wds. The idea was to form a chain of pairs of routers, where
>> each forwarding router were connected to the previous and the next
>> forwarder using those sta and AP interfaces, as can be seen in
>> conf_1.png. Unfortunately we found that with this configuration the
>> broadcast batman packets were forwarded through all the chain without
>> any batman processing. For example, Batman 1 sends an Originator which
>> goes out through its ad hoc interface, and also through ethernet, then
>> Forward 1 sends it through its sta to Forward 2. In Forward 2 the sta,
>> ap and ethernet interfaces are bridged, so the Originator goes to Batman
>> 2 via ethernet (that's ok) but also goes directly to Forward 3 without
>> the hop penalty applied. As a result Batman 3 sees the ethernet
>> interface of Batman 1 as a direct neighbour with a good quality. In a
>> longer chain the result would be the same.
>>
>> 2) A solution to the first configuration could be use some ebtables
>> rules, but using ebtables we directly tried with normal ad hoc
>> interfaces. So we used the configuration seen in conf_2.png. We cloned
>> the MACs of the Batman ethernet interfaces to the ad hoc interfaces.
>> That way the packets destined by Batman to the ethernet interfaces of
>> their neighbours enter through the wireless interfaces because they have
>> the same MAC. Once inside the Forwarding routers we use this rule:
>>
>>   ebtables -t broute -A BROUTING -i wlan0 -d <MAC1> -j dnat --to-dst
>> <MACX> --dnat-target ACCEPT
>>
>> So changing the dst MAC the packets are forwarded through ethernet. In
>> the BATMAN routers we used this rule to change again the dst MAC:
>>
>>   ebtables -t broute -A BROUTING -i eth0 -d <MACX> -j dnat --to-dst
>> <MAC1> --dnat-target ACCEPT
>>
>> For using ebtables with Batman we had to attach eth0 to a bridge, and
>> add that bridge to batman. In the normal configuration with batman
>> managing eth0 it doesn't work.
>> For the reverse path, packets entering to Forwarding routers from Batman
>> routers it wasn't necessary to use any rule, we just saw many warnings
>> advicing that packets with own address as source address were received.
>>
>> We had read in openwrt forum that ebtables could cause performance
>> issues on routers, but we didn't notice a great difference in the tests
>> we've made with iperf up to now.
>>
>> The problem that we are facing now is the impossibility of increasing
>> the MTU of ethernet interfaces in the routers. We saw this patch:
>>
>> http://permalink.gmane.org/gmane.comp.embedded.openwrt.devel/14678
>>
>> and thought that maybe we could increase a bit more the MTU, but we
>> couldn't. So the other possibility is to decrease all the other
>> interfaces MTU to 1470 and let the ethernet to 1500 right? We guess that
>> could cause IP fragmentation in some cases.
>>
>> I hope my explanations are understandable.
>>
>> Best regards!
>>
>> Gabriel
>>
>> El 18/06/2012 03:46 p.m., gtolon@inti.gob.ar escribió:
>>> Hi Simon, thanks for your reply!
>>>
>>>
>>> El 15/06/2012 06:55 a.m., Simon Wunderlich escribió:
>>>> On Thu, Jun 14, 2012 at 04:51:01PM -0300, gtolon@inti.gob.ar wrote:
>>>>> Hi,
>>>>>
>>>>>      we are interested too in interface alternating, so we made some
>>>>> tests to understand how it works. As you can see on the attached
>>>>> sketch.png, we connected two pair of routers using their ethernet
>>>>> interfaces, E6 with E7, and E8 with E9. All of them have eth0, and
>>>>> an ad hoc interface, wlan0-1, managed by batman. E6 and E8 are in
>>>>> channel 11, whereas E7 and E9 are in channel 1. Besides we used two
>>>>> other routers, E12 and E13, both in channel 11, with their tx power
>>>>> set to just 0 dbm, to avoid a direct sight between them.
>>>>>
>>>>>      Then we sent traffic from E12 to E13. We expected that packets
>>>>> travelled from E12 to E6, and that E6 forwarded them to his eth0 to
>>>>> use the interface alternating feature, making traffic flow to E7,
>>>>> then E9, E8 and finally E13. But instead, we observed that the
>>>>> actual path was E12--E6--E8--E13. The resulting routes for each
>>>>> router are attached in a text file, and also the graph from the
>>>>> batctl vd dot command.
>>>>>
>>>>>      After this result, we read again the thread mentioned by Guido,
>>>>> specially in this part:
>>>>>
>>>>> https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2012-March/006344.html
>>>>>
>>>>>
>>>>>
>>>>>     And if we understand correctly, the alternation feature works
>>>>> after the batman path has been selected. So in our case, E12 looks
>>>>> at his table to know where to send a packet to E13, and finds E6.
>>>>> Then E6 receives the packet and looks in his own table, finding that
>>>>> the best path to reach E13 is E8. At this point, the alternating
>>>>> should work, but there's only one interface directly connected to
>>>>> E8, so the packet goes there, and so on. We think that if E6 and E7
>>>>> were not two different routers running batman-adv but they were two
>>>>> radios of the same batman-adv router, and the same for E8 and E9,
>>>>> the alternating would work, because the unique router would choose
>>>>> the best path, and then would find two possible interfaces to the
>>>>> same next-hop, changing the interface.
>>>> This is entirely correct - batman-adv has only one link to choose from
>>>> (E6 ->  E8) to reach its best nexthop E8, so there is no way to
>>>> "alternate" the interfaces.
>>>>
>>>>>      We'd like to know if this interpretation is correct, and in that
>>>>> case, if it were possible to use interface alternating in a case
>>>>> like this, with two routers connected to work together. Thanks!
>>>> Mhm, with the current implementation - no, unfortunately not. We would
>>>> need some kind of multipath routing to select between routes, this is
>>>> much more complex.
>>>
>>> Ok, i understand.
>>>
>>>>
>>>> An alternative might be to use the routers E7/E9 as secondary routers
>>>> without batman, but only forwarding traffic between Ethernet and
>>>> WiFi. Then the "primary" routers (E6 ->  E8) would think they have
>>>> an alternative route via Ethernet (because they don't see the
>>>> intermediate hops E7/E9). This comes with some caveats however, e.g.
>>>> 4-addr mode in Ad-Hoc, you need some very simple ethernet forwarder,
>>>> and most probably other things I forgot.
>>>
>>> We had tried with something like that using ap and sta modes in E7 and
>>> E9, and it hadn't worked. Thanks to your suggestion we noticed the
>>> necessity of the 4-address mode, so we are now trying with wds:
>>>
>>> http://wiki.openwrt.org/doc/recipes/atheroswds
>>>
>>> Unfortunately, we haven't found yet a way to use 4-address mode in ad
>>> hoc. Apparentrly, it's not possible:
>>>
>>> http://linuxwireless.org/en/users/Documentation/iw#Using_4-address_for_AP_and_client_mode
>>>
>>>
>>>
>>> Best Regards
>>>
>>> Gabriel
>>
>

Re: [B.A.T.M.A.N.] link alternation when radios are not on batman-adv router?

[gtolon]

Hi Guido,

In both configurations described, there's one router running batman and 
the other connected via ethernet which is not. The function of the 
latter is just to forward batman packets between ethernet and wifi. That 
way the batman routers see alternative paths to their neighbours through 
their ethernet interfaces.

For this to work, however, it's necessary to do something in the router 
which doesn't run batman, because a normal ad hoc interface using 2 MAC 
addresses doesn't work in a bridged configuration. That's why Simon 
suggested the 4-addr mode in ad hoc, but unfortunately, we found that 
with ath9k it's not possible to use that mode. So we began with the 
configuration 1) where we didn't use ad hoc, but instead we tried with 
ap and sta using wds (a mode with 4-address for access points and 
stations). As mentioned previously, the problem with this configuration 
was that as we were using both ap and sta bridged in the same non-batman 
forwarding router (to achieve alternative paths between all nodes), the 
batman broadcast packets were being forwarded directly.

That's where we tried with ebtables + ad hoc (config 2). This way using 
ebtables and the cloned MACs we don't need 4-addr mode, and the batman 
routers see the alternative paths through their ethernet interfaces. But 
for this to work, the batman routers need to use ebtables also, not just 
the forwarding routers, because we change the dst MACs in both the 
forwarding and the batman routers. And for using ebtables in a router 
running batman, we had to add eth0 to a bridge, and then add the bridge 
to bat0, that's what i was saying with that sentence. Look at this thread:

https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2010-May/002716.html

By the way, we're using batman-adv 2012.0.0

Anyway, all this was just to achieve link alternation using two routers 
with 1 radio each. With 2 radios it would be much better i guess. Please 
tell me if something is still unclear.


Best regards

Gabriel

El 14/07/2012 06:35 p.m., Guido Iribarren escribió:
> Ah, i missed this sentence
> "In the normal configuration with batman managing eth0 it doesn't work."
> why? How was the setup? Which batman version?
> I came across something like this (reported in a previous thread) but
> so far i haven't had spare time to reproduce it again to debug it.
>
> On 7/14/12, Guido Iribarren <guidoiribarren@buenosaireslibre.org> wrote:
>> You can try taking eth0 out of the bridge and adding it to bat0
>> that way you wouldn't need to mess with ebtables?
>> As there would be no bridged interfaces, batman would be the only one
>> forwarding packets between eth0 and wlan0. With hop penalty.
>>
>> On 7/13/12, gtolon@inti.gob.ar <gtolon@inti.gob.ar> wrote:
>>> Hi.
>>>
>>> We've been trying two different configurations to use link alternation
>>> with two routers conected via ethernet. In both cases in each pair of
>>> routers one runs batman and the other only forwards traffic between
>>> ethernet and wifi, as Simon suggested:
>>>
>>> 1) First in the forwarding routers we configured an AP and a station,
>>> both using wds. The idea was to form a chain of pairs of routers, where
>>> each forwarding router were connected to the previous and the next
>>> forwarder using those sta and AP interfaces, as can be seen in
>>> conf_1.png. Unfortunately we found that with this configuration the
>>> broadcast batman packets were forwarded through all the chain without
>>> any batman processing. For example, Batman 1 sends an Originator which
>>> goes out through its ad hoc interface, and also through ethernet, then
>>> Forward 1 sends it through its sta to Forward 2. In Forward 2 the sta,
>>> ap and ethernet interfaces are bridged, so the Originator goes to Batman
>>> 2 via ethernet (that's ok) but also goes directly to Forward 3 without
>>> the hop penalty applied. As a result Batman 3 sees the ethernet
>>> interface of Batman 1 as a direct neighbour with a good quality. In a
>>> longer chain the result would be the same.
>>>
>>> 2) A solution to the first configuration could be use some ebtables
>>> rules, but using ebtables we directly tried with normal ad hoc
>>> interfaces. So we used the configuration seen in conf_2.png. We cloned
>>> the MACs of the Batman ethernet interfaces to the ad hoc interfaces.
>>> That way the packets destined by Batman to the ethernet interfaces of
>>> their neighbours enter through the wireless interfaces because they have
>>> the same MAC. Once inside the Forwarding routers we use this rule:
>>>
>>>    ebtables -t broute -A BROUTING -i wlan0 -d <MAC1> -j dnat --to-dst
>>> <MACX> --dnat-target ACCEPT
>>>
>>> So changing the dst MAC the packets are forwarded through ethernet. In
>>> the BATMAN routers we used this rule to change again the dst MAC:
>>>
>>>    ebtables -t broute -A BROUTING -i eth0 -d <MACX> -j dnat --to-dst
>>> <MAC1> --dnat-target ACCEPT
>>>
>>> For using ebtables with Batman we had to attach eth0 to a bridge, and
>>> add that bridge to batman. In the normal configuration with batman
>>> managing eth0 it doesn't work.
>>> For the reverse path, packets entering to Forwarding routers from Batman
>>> routers it wasn't necessary to use any rule, we just saw many warnings
>>> advicing that packets with own address as source address were received.
>>>
>>> We had read in openwrt forum that ebtables could cause performance
>>> issues on routers, but we didn't notice a great difference in the tests
>>> we've made with iperf up to now.
>>>
>>> The problem that we are facing now is the impossibility of increasing
>>> the MTU of ethernet interfaces in the routers. We saw this patch:
>>>
>>> http://permalink.gmane.org/gmane.comp.embedded.openwrt.devel/14678
>>>
>>> and thought that maybe we could increase a bit more the MTU, but we
>>> couldn't. So the other possibility is to decrease all the other
>>> interfaces MTU to 1470 and let the ethernet to 1500 right? We guess that
>>> could cause IP fragmentation in some cases.
>>>
>>> I hope my explanations are understandable.
>>>
>>> Best regards!
>>>
>>> Gabriel
>>>
>>> El 18/06/2012 03:46 p.m., gtolon@inti.gob.ar escribió:
>>>> Hi Simon, thanks for your reply!
>>>>
>>>>
>>>> El 15/06/2012 06:55 a.m., Simon Wunderlich escribió:
>>>>> On Thu, Jun 14, 2012 at 04:51:01PM -0300, gtolon@inti.gob.ar wrote:
>>>>>> Hi,
>>>>>>
>>>>>>       we are interested too in interface alternating, so we made some
>>>>>> tests to understand how it works. As you can see on the attached
>>>>>> sketch.png, we connected two pair of routers using their ethernet
>>>>>> interfaces, E6 with E7, and E8 with E9. All of them have eth0, and
>>>>>> an ad hoc interface, wlan0-1, managed by batman. E6 and E8 are in
>>>>>> channel 11, whereas E7 and E9 are in channel 1. Besides we used two
>>>>>> other routers, E12 and E13, both in channel 11, with their tx power
>>>>>> set to just 0 dbm, to avoid a direct sight between them.
>>>>>>
>>>>>>       Then we sent traffic from E12 to E13. We expected that packets
>>>>>> travelled from E12 to E6, and that E6 forwarded them to his eth0 to
>>>>>> use the interface alternating feature, making traffic flow to E7,
>>>>>> then E9, E8 and finally E13. But instead, we observed that the
>>>>>> actual path was E12--E6--E8--E13. The resulting routes for each
>>>>>> router are attached in a text file, and also the graph from the
>>>>>> batctl vd dot command.
>>>>>>
>>>>>>       After this result, we read again the thread mentioned by Guido,
>>>>>> specially in this part:
>>>>>>
>>>>>> https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2012-March/006344.html
>>>>>>
>>>>>>
>>>>>>
>>>>>>      And if we understand correctly, the alternation feature works
>>>>>> after the batman path has been selected. So in our case, E12 looks
>>>>>> at his table to know where to send a packet to E13, and finds E6.
>>>>>> Then E6 receives the packet and looks in his own table, finding that
>>>>>> the best path to reach E13 is E8. At this point, the alternating
>>>>>> should work, but there's only one interface directly connected to
>>>>>> E8, so the packet goes there, and so on. We think that if E6 and E7
>>>>>> were not two different routers running batman-adv but they were two
>>>>>> radios of the same batman-adv router, and the same for E8 and E9,
>>>>>> the alternating would work, because the unique router would choose
>>>>>> the best path, and then would find two possible interfaces to the
>>>>>> same next-hop, changing the interface.
>>>>> This is entirely correct - batman-adv has only one link to choose from
>>>>> (E6 ->  E8) to reach its best nexthop E8, so there is no way to
>>>>> "alternate" the interfaces.
>>>>>
>>>>>>       We'd like to know if this interpretation is correct, and in that
>>>>>> case, if it were possible to use interface alternating in a case
>>>>>> like this, with two routers connected to work together. Thanks!
>>>>> Mhm, with the current implementation - no, unfortunately not. We would
>>>>> need some kind of multipath routing to select between routes, this is
>>>>> much more complex.
>>>> Ok, i understand.
>>>>
>>>>> An alternative might be to use the routers E7/E9 as secondary routers
>>>>> without batman, but only forwarding traffic between Ethernet and
>>>>> WiFi. Then the "primary" routers (E6 ->  E8) would think they have
>>>>> an alternative route via Ethernet (because they don't see the
>>>>> intermediate hops E7/E9). This comes with some caveats however, e.g.
>>>>> 4-addr mode in Ad-Hoc, you need some very simple ethernet forwarder,
>>>>> and most probably other things I forgot.
>>>> We had tried with something like that using ap and sta modes in E7 and
>>>> E9, and it hadn't worked. Thanks to your suggestion we noticed the
>>>> necessity of the 4-address mode, so we are now trying with wds:
>>>>
>>>> http://wiki.openwrt.org/doc/recipes/atheroswds
>>>>
>>>> Unfortunately, we haven't found yet a way to use 4-address mode in ad
>>>> hoc. Apparentrly, it's not possible:
>>>>
>>>> http://linuxwireless.org/en/users/Documentation/iw#Using_4-address_for_AP_and_client_mode
>>>>
>>>>
>>>>
>>>> Best Regards
>>>>
>>>> Gabriel