Re: [B.A.T.M.A.N.] link alternation when radios are not on batman-adv router?
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 guidoiribar...@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, gto...@inti.gob.ar gto...@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
Re: [B.A.T.M.A.N.] link alternation when radios are not on batman-adv router?
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, gto...@inti.gob.ar gto...@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., gto...@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, gto...@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.
Re: [B.A.T.M.A.N.] link alternation when radios are not on batman-adv router?
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 guidoiribar...@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, gto...@inti.gob.ar gto...@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., gto...@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, gto...@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
Re: [B.A.T.M.A.N.] link alternation when radios are not on batman-adv router?
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., gto...@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, gto...@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
Re: [B.A.T.M.A.N.] link alternation when radios are not on batman-adv router?
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, gto...@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?
On Thu, Jun 14, 2012 at 04:51:01PM -0300, gto...@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 signature.asc Description: Digital signature
Re: [B.A.T.M.A.N.] link alternation when radios are not on batman-adv router?
On Sat, Mar 31, 2012 at 12:11 PM, Guido Iribarren guidoiribar...@buenosaireslibre.org wrote: On Sat, Mar 31, 2012 at 12:45 PM, Dan Denson danden...@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?
On 03/31/2012 06:03 PM, dan wrote: On Sat, Mar 31, 2012 at 12:11 PM, Guido Iribarren guidoiribar...@buenosaireslibre.org wrote: On Sat, Mar 31, 2012 at 12:45 PM, Dan Denson danden...@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
[B.A.T.M.A.N.] link alternation when radios are not on batman-adv router?
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?
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_Link1node2_Link1 node1_Link2node2_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-picostation1supernode2 supernode1---picostation2-picostation2supernode2 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.
