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.
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.
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.
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
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?
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!)
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.
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
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
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.
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, dandandenson@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
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 sometests 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 packetstravelled 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 thatcase, 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
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 sometests 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 packetstravelled 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 worksafter 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 thatcase, 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_an...
Best Regards
Gabriel
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 sometests 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 packetstravelled 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 worksafter 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 thatcase, 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_an...
Best Regards
Gabriel
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:
- 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.
- 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 sometests 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 packetstravelled 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 worksafter 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 thatcase, 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_an...
Best Regards
Gabriel
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:
- 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.
- 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 sometests 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 packetstravelled 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 worksafter 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 thatcase, 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_an...
Best Regards
Gabriel
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:
- 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.
- 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 sometests 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 packetstravelled 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 worksafter 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 thatcase, 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_an...
Best Regards
Gabriel
b.a.t.m.a.n@lists.open-mesh.org
-
dan -
Dan Denson
-
gtolon＠inti.gob.ar -
Guido Iribarren -
Nicolás Echániz -
Simon Wunderlich