Re: [B.A.T.M.A.N.] Problems to add Batman-adv in wlan0 Nanostation M5
Hi Esteban, I don't see in the link that you pasted that they use opkg. I think they compile batman-adv before installing the image to the router, right?. Maybe this thread could be useful to you: http://www.mail-archive.com/b.a.t.m.a.n@lists.open-mesh.org/msg07566.html After installing batman-adv you can use the file /etc/config/batman to configure it. Regards Gabriel El 31/07/2012 01:41 p.m., Esteban Municio escribió: Hi all I`m working on a academic develop project for improve the networks in rural areas in Peru. We are doing some test with 6 Nanostation M5 for create a mesh network. I tried Commotion software with OLSR and all was Ok. Now, we are testing BATMAN, with OpenWRT and batman-adv module, but I have some problems. I have compiled OpenWrt Backfire r32751 (Load: 0.09 0.10 0.05) and installed batman-adv with opkg following this http://wiki.openwrt.org/inbox/mesh.batman When I put: lsmod | grep batman I get batman_adv 67936 0 and seems to be load in the kernel But when I try to add the interface wlan0 for activate batman in it, the Nanostation remains locked and i need to reboot. I have tried this with: echo bat0 /sys/class/net/wlan0/batman_adv/mesh_iface and batctl if add wlan0 with the same bad result. What am i doing wrong? That are my configuration files: root@OpenWrt:~# cat /etc/config/network config interface loopback option ifname lo option protostatic option ipaddr 127.0.0.1 option netmask 255.0.0.0 config interface lan option ifname eth0 option type bridge option protostatic option ipaddr 192.168.1.1 option netmask 255.255.255.0 #config interface wan # option ifname eth1 # option protodhcp config interface wan option ifname eth1 option protostatic option ipaddr my ip public for internet access option netmask 255.255.255.192 option gateway my ip public gateway option dns 8.8.8.8 root@OpenWrt:~# cat /etc/config/wireless config 'wifi-device' 'radio0' option 'type' 'mac80211' option 'macaddr' '00:27:22:52:71:a7' option 'hwmode' '11na' option 'htmode' 'HT20' list 'ht_capab' 'SHORT-GI-40' list 'ht_capab' 'TX-STBC' list 'ht_capab' 'RX-STBC1' list 'ht_capab' 'DSSS_CCK-40' option 'channel' '161' option 'txpower' '0' option 'country' 'US' config 'wifi-iface' option 'device' 'radio0' option 'network' 'lan' option 'ssid' 'OpenWrt' option 'encryption' 'none' option 'mode' 'adhoc' option 'bssid' '00:27:22:52:71:A7' --- root@OpenWrt:~# iwconfig lono wireless extensions. eth0 no wireless extensions. eth1 no wireless extensions. br-lanno wireless extensions. wlan0 IEEE 802.11an ESSID:OpenWrt Mode:Ad-Hoc Frequency:5.805 GHz Cell: 00:27:22:52:71:A7 Tx-Power=3 dBm RTS thr:off Fragment thr:off Encryption key:off Power Management:on - root@OpenWrt:~# ifconfig br-lanLink encap:Ethernet HWaddr 00:27:22:53:71:A7 inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:9489 errors:0 dropped:0 overruns:0 frame:0 TX packets:9584 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:989861 (966.6 KiB) TX bytes:3510637 (3.3 MiB) eth0 Link encap:Ethernet HWaddr 00:27:22:53:71:A7 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:9511 errors:0 dropped:0 overruns:0 frame:0 TX packets:9597 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1124441 (1.0 MiB) TX bytes:3512820 (3.3 MiB) Interrupt:4 eth1 Link encap:Ethernet HWaddr 00:27:22:53:71:A8 inet addr:my ip public Bcast:my ip broadcast broadcast Mask:255.255.255.192 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:13086 errors:0 dropped:0 overruns:0 frame:0 TX packets:4552 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:4041054 (3.8 MiB) TX bytes:797392 (778.7 KiB) Interrupt:5 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:16 errors:0 dropped:0 overruns:0 frame:0 TX packets:16 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1556 (1.5 KiB) TX bytes:1556 (1.5 KiB) wlan0 Link encap:Ethernet HWaddr 00:27:22:52:71:A7
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?
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.] newbie error or repo misconfig?
Hi, This page explains how to compile it together with Openwrt: http://www.open-mesh.org/wiki/batman-adv/Building-with-openwrt/ I hope it's useful for you. On the other hand, i think that once i installed batman-adv after installing openwrt. I compiled the batman package using menuconfig (after installing the feeds as described in the page), searched for the corresponding ipkg package on /bin/ar.../packages and then copied the ipkg to the router to install it. Regards Gabriel Tony Godshall t...@of.net escribió: root@OpenWrt:~# opkg install kmod-batman-adv Installing kmod-batman-adv (3.3.8+2012.2.0-2) to root... Downloading http://downloads.openwrt.org/snapshots/trunk/ar71xx/packages/kmod-batman-adv_3.3.8+2012.2.0-2_ar71xx.ipk. Collected errors: * satisfy_dependencies_for: Cannot satisfy the following dependencies for kmod-batman-adv: * kernel (= 3.3.8-1-65fa3307447a560c3a618c4d54bfa4dc) * kernel (= 3.3.8-1-65fa3307447a560c3a618c4d54bfa4dc) * * opkg_install_cmd: Cannot install package kmod-batman-adv. This is my foray into batman-adv land, with a freshly flashed TL-WR703n that has been configured and tested functional as a wifi access point Can the list direct me to- 1. do I need to set up toolchain and build batman-adv myself against this kernel? 2. do I need to set up toolchain and build my own kernel? 3. can I instead point configure for some other repository I've perused the batman-advanced documentation wiki but the documents there seem to kind of skip over this bit -- Best Regards.
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.] Traffic Control in batman-adv
Guido and 3zl, thanks for the replies! Regarding packet marking, i think it's a good idea, but when i tryed it i had some issues with the interaction between iptables/ebtables and the bridge, i'll read more about that. I've heard about gargoyle, didn't know it was based on backfire. That active congestion check sounds great! In this link there's an abstract about that assolo method, interesting: http://www.computer.org/portal/web/csdl/doi/10.1109/ICIMP.2009.28 Best regards Gabriel El 27/04/2012 07:34 p.m., 3zl Trizonelabs escribió: measuring bandwidth we test with assolo packet in afrimesh repos (builds ok with trunk) maybe also have a look at http://wiki.openwrt.org/doc/howto/packet.scheduler/packet.scheduler.theory TBF with netem discussed here https://forum.openwrt.org/viewtopic.php?pid=161108 regards 3zl
Re: [B.A.T.M.A.N.] Traffic Control in batman-adv
Hi, That's a very good diagram! Resuming the thread, Sven said that adding a qdisc to wlan0-1 makes no sense. I don't understand completely why, but i guess that once bat0 manages wlan0-1, the latter can't work anymore at IP layer, right? So i've done some tests with bat0. I realized that maybe when i had applied a SFQ qdisc to bat0, the bottleneck was still on wlan0-1, and for that reasons packets were dropped on wlan0-1. Then using a HTB qdisc i limited bat0 rate to a minor value than the wlan0-1 actual output rate, and added some classes inside with SFQ. This way i could see dropped packets at bat0 and SFQ working as expected (and no dropped packets at wlan0-1). However, for this configuration to work, the limit value rate for bat0 has to be smaller than the output rate of wlan0-1, but this value is not fixed in a wireless link. I don't know if it's possible to use another configuration in which it's not necessary to set a fixed limit value to allow bat0 to control the bottleneck. Regards Gabriel El 26/04/2012 01:04 p.m., 3zl Trizonelabs escribió: Hi Marek, since WBM Athens, where i met you guys,i decided to prepare some stuff and organize it on a collaborating site for batman-adv applications Everybody is welcome to join. I'll add your email to the Mindmono Mindmap site to get some ideas how to organize the site. ( teamlab.com would be nice) Have a look at the mindmap :http://www.mindomo.com/view.htm?m=bbde50c10b0b4864bde98b83f2a7cf3b regards 3zl Greece/Germany 2012/4/26 Marek Lindnerlindner_ma...@yahoo.de: On Thursday, April 26, 2012 22:49:24 3zl Trizonelabs wrote: maybe pic this will help http://www.bild.me/bild.php?file=9951400Batman-CPE-config.png Hey, that is a very good graphical explanation of the setup! Do you happen to have more of those ? Maybe we should create a page talking about possible network setups and include your stuff there ? Cheers, Marek
Re: [B.A.T.M.A.N.] Traffic Control in batman-adv
Hi Sven, thanks for replying. El 25/04/2012 05:51 p.m., Sven Eckelmann escribió: On Wednesday 25 April 2012 17:27:03 gto...@inti.gob.ar wrote: Hi, First thing: Don't reply to random messages when you actually want to start a new topic. Ok. We are doing some tests with Traffic Control (tc) in routers with Openwrt running batman-adv, want to be able to share the bandwidth with some degree of fairness between users, so we think that SFQ could help, differentiating the flows depending on ip addresses and ports. The problem is that when adding the SFQ qdisc to the wireless interface managed by batman it doesn't work as expected. We tested the SFQ in other configurations and it worked fine, in full queues, the dropped packets affected the big flows, allowing the others to pass, but in the interface managed by batman-adv when packets are dropped, the result affects all flows almost equally. We thought this could be related with the bridge we use to connect the batman with the non-batman interfaces, but in a wireless Acces Point bridged to bat0 it also worked fine. Maybe it's related with the way bat0 works with it's managed interface? We'd appreciate any advices. Thanks in advance! Why do you add the sfq qdisc to the wireless device instead to the bat0 device? It doesn't really makes sense to me. I also tryed with bat0, but the packets continued to dropp on the wireless device, not in bat0, so i thought that the qdisc of bat0 was not being used. Anyway, i'll try again. Also your statement about batman-adv bridged with non-batman-adv doesn't work, but batman-adv bridged with non-batman-adv interface works statement is slightly irritating. Please explain it a little bit more verbose to help us understand what is the difference. Sorry for the bad explanation,what i wanted to say is: We have a bridge with bat0, eth0 and wlan0 attached. wlan0 is in ap mode. There's another wireless interface, wlan0-1 in ad-hoc mode, managed by bat0. When SFQ qdisc is applied to wlan0, it works as expected. When it's aplied to wlan0-1, it doesn't. In both cases there's a bridge involved, that´s what i was trying to point. I hope now it's more clear. Best regards Gabriel
[B.A.T.M.A.N.] Traffic Control in batman-adv
Hi, We are doing some tests with Traffic Control (tc) in routers with Openwrt running batman-adv, want to be able to share the bandwidth with some degree of fairness between users, so we think that SFQ could help, differentiating the flows depending on ip addresses and ports. The problem is that when adding the SFQ qdisc to the wireless interface managed by batman it doesn't work as expected. We tested the SFQ in other configurations and it worked fine, in full queues, the dropped packets affected the big flows, allowing the others to pass, but in the interface managed by batman-adv when packets are dropped, the result affects all flows almost equally. We thought this could be related with the bridge we use to connect the batman with the non-batman interfaces, but in a wireless Acces Point bridged to bat0 it also worked fine. Maybe it's related with the way bat0 works with it's managed interface? We'd appreciate any advices. Thanks in advance! Gabriel
Re: [B.A.T.M.A.N.] problem with mesh network
El 10/01/2012 12:17 p.m., Marek Lindner escribió: On Tuesday, January 10, 2012 21:14:38 gto...@inti.gob.ar wrote: Yes, we suspected it could be a TX dma problem, because occasionally we found that error in the logs, so we followed some openwrt tickets related with that, but we're not sure that's the problem, and anyway it has not been solved yet. We've also asked on ath9k list about the driver debug files in case we could find something there, but they did't answered, I guess it's hard to explain in a mail list. We haven't asked to linux-wireless, maybe it would be better, since it could be something on top of the driver. You can post the links to the specific tickets / open bug reports here. Maybe somebody has some information about it. Generally, the wifi lists are the better place to discuss these bugs. Here are the mentioned tickets: https://dev.openwrt.org/ticket/9693 https://dev.openwrt.org/ticket/9654 We were thinking in a script that managed the stations to connect to the different APs to avoid configuring each router manually. However we realized that with just one managed interface, each router could connect to only one AP, so if we wanted that every router could connect bidirectionally to others we should use a number of managed interfaces enough to connect to all neigbours, shouldn't we? In any case it would be just another test to see if the results are different. Correct, managed/AP is a one-to-one connection. If you want a router to connect to several APs you need an additional managed interface per connection. Regards, Marek Regards Gabriel
Re: [B.A.T.M.A.N.] problem with mesh network
Hi Marek, thanks for the reply. El 10/01/2012 08:00 a.m., b.a.t.m.a.n-requ...@lists.open-mesh.org escribió: Date: Mon, 9 Jan 2012 20:22:37 +0800 From: Marek Lindnerlindner_ma...@yahoo.de To: The list for a Better Approach To Mobile Ad-hoc Networking b.a.t.m.a.n@lists.open-mesh.org Subject: Re: [B.A.T.M.A.N.] problem with mesh network Message-ID:201201092022.37637.lindner_ma...@yahoo.de Content-Type: Text/Plain; charset=iso-8859-1 Hi, We are using batman-adv 2011.2.0 with Openwrt Backfire-rc6 on D-Link Dir-615 routers (2 Antennas, 1 single radio), each router with an adhoc interface managed by batman-adv for the mesh network and an Acces Point interface bridged with bat0 and ethernet to allow non batman-adv clients to connect. The problem is that sometimes all works fine, but sometimes we get very poor bitrates between routers, even using just two routers, testing with iperf. We don't know where the problem is, specially because it's a very erratic behavior. If any of you have used this configuration with openwrt and ath9k driver we'd really appreciate some help. this does not sound like a batman issue. Did you try contacting the ath9k/linux-wireless/openwrt developers ? Yes, we suspected it could be a TX dma problem, because occasionally we found that error in the logs, so we followed some openwrt tickets related with that, but we're not sure that's the problem, and anyway it has not been solved yet. We've also asked on ath9k list about the driver debug files in case we could find something there, but they did't answered, I guess it's hard to explain in a mail list. We haven't asked to linux-wireless, maybe it would be better, since it could be something on top of the driver. By the way, the D-Link Dir-615 is an n router, but for some reason related with hostapd the ap vif gets configured in g mode, and the adhoc in n mode, no matter what we set in the uci files. So in case the problem were related with the adhoc and ap virtual interface, we were thinking about the possibility of setting the mesh network without using adhoc mode. In that case each router should have one ap for non batman-adv clients, and two additional interfaces, one in ap and the other managed, these two used to connect with other routers via batman-adv, would that be correct? In that case, you think this configuration could be more or less stable than the other using adhoc mode? batman-adv does not care how you configure your interfaces. Using managed/AP with batman-adv on top works as well. However, you will need to configure each managed/AP setup manually which will be cumbersome in a larger network and has no failover. A single failure in your managed/AP chain will bring down all nodes depending on it. We were thinking in a script that managed the stations to connect to the different APs to avoid configuring each router manually. However we realized that with just one managed interface, each router could connect to only one AP, so if we wanted that every router could connect bidirectionally to others we should use a number of managed interfaces enough to connect to all neigbours, shouldn't we? In any case it would be just another test to see if the results are different. Gabriel
[B.A.T.M.A.N.] problem with mesh network
Hi We are using batman-adv 2011.2.0 with Openwrt Backfire-rc6 on D-Link Dir-615 routers (2 Antennas, 1 single radio), each router with an adhoc interface managed by batman-adv for the mesh network and an Acces Point interface bridged with bat0 and ethernet to allow non batman-adv clients to connect. The problem is that sometimes all works fine, but sometimes we get very poor bitrates between routers, even using just two routers, testing with iperf. We don't know where the problem is, specially because it's a very erratic behavior. If any of you have used this configuration with openwrt and ath9k driver we'd really appreciate some help. By the way, the D-Link Dir-615 is an n router, but for some reason related with hostapd the ap vif gets configured in g mode, and the adhoc in n mode, no matter what we set in the uci files. So in case the problem were related with the adhoc and ap virtual interface, we were thinking about the possibility of setting the mesh network without using adhoc mode. In that case each router should have one ap for non batman-adv clients, and two additional interfaces, one in ap and the other managed, these two used to connect with other routers via batman-adv, would that be correct? In that case, you think this configuration could be more or less stable than the other using adhoc mode? Thanks in advance! Gabriel
Re: [B.A.T.M.A.N.] B.A.T.M.A.N Digest, Vol 59, Issue 21
Thank you for the advice Marek! We've setted the mcast_rate in 18000 using uci and it's quite better! Unfortunately we've found a problem apparently related with ath9k driver, so we couldn't go on with more complicated routes tests. Thanks! -- Message: 4 Date: Wed, 16 Nov 2011 11:30:05 +0800 From: Marek Lindner lindner_ma...@yahoo.de To: The list for a Better Approach To Mobile Ad-hoc Networking b.a.t.m.a.n@lists.open-mesh.org Subject: Re: [B.A.T.M.A.N.] Problem to find better Route Message-ID: 20161130.05500.lindner_ma...@yahoo.de Content-Type: Text/Plain; charset=iso-8859-1 On Wednesday, November 16, 2011 01:59:11 gto...@inti.gob.ar wrote: Thank you for your answers. I copy the Originator's tables for the three nodes: [..] This is a typical state of the tables. We tryed setting the hop pennalty parameter to 1, but the behaviour hasn't changed. The TQ values are quite close, so I can imagine that batman has a hard time finding the better path. You could try to set the broadcast rate to a fixed value (5.5 or even 18) to force the driver to not send the broadcasts at such a low rate. Cheers, Marek -- Message: 5 Date: Wed, 16 Nov 2011 09:32:11 +0100 From: Antonio Quartullior...@autistici.org To: The list for a Better Approach To Mobile Ad-hoc Networking b.a.t.m.a.n@lists.open-mesh.org Subject: Re: [B.A.T.M.A.N.] Problem to find better Route Message-ID:2016083210.ga17...@ritirata.org Content-Type: text/plain; charset=utf-8 On Wed, Nov 16, 2011 at 11:30:05 +0800, Marek Lindner wrote: The TQ values are quite close, so I can imagine that batman has a hard time finding the better path. You could try to set the broadcast rate to a fixed value (5.5 or even 18) to force the driver to not send the broadcasts at such a low rate. Can you really do that? Cheers, -- Antonio Quartulli ..each of us alone is worth nothing.. Ernesto Che Guevara -- Message: 6 Date: Wed, 16 Nov 2011 16:49:46 +0800 From: Marek Lindner lindner_ma...@yahoo.de To: The list for a Better Approach To Mobile Ad-hoc Networking b.a.t.m.a.n@lists.open-mesh.org Subject: Re: [B.A.T.M.A.N.] Problem to find better Route Message-ID: 20161649.46492.lindner_ma...@yahoo.de Content-Type: Text/Plain; charset=utf-8 On Wednesday, November 16, 2011 16:32:11 Antonio Quartulli wrote: On Wed, Nov 16, 2011 at 11:30:05 +0800, Marek Lindner wrote: The TQ values are quite close, so I can imagine that batman has a hard time finding the better path. You could try to set the broadcast rate to a fixed value (5.5 or even 18) to force the driver to not send the broadcasts at such a low rate. Can you really do that? Yap. If you want to find out how: google is your friend.:-) Cheers, Marek --
Re: [B.A.T.M.A.N.] Problem to find better Route
Thank you for your answers. I copy the Originator's tables for the three nodes: A) (MAC: b2:48:7a:c8:a2:65) root@OpenWrt:/# batctl o [B.A.T.M.A.N. adv 2011.2.0, MainIF/MAC: wlan1/b2:48:7a:c8:a2:65 (bat0)] Originator last-seen (#/255) Nexthop [outgoingIF]: Potential nexthops ... 16:d6:4d:3a:3c:3c 0.790s (213) 16:d6:4d:3a:3c:3c [ wlan1]: 16:d6:4d:3a:3d:d8 (193) 16:d6:4d:3a:3c:3c (213) 16:d6:4d:3a:3d:d80.810s (255) 16:d6:4d:3a:3d:d8 [ wlan1]: 16:d6:4d:3a:3c:3c (190) 16:d6:4d:3a:3d:d8 (255) B) (MAC: 16:d6:4d:3a:3c:3c) root@OpenWrt:/# batctl o [B.A.T.M.A.N. adv 2011.2.0, MainIF/MAC: wlan1/16:d6:4d:3a:3c:3c (bat0)] Originator last-seen (#/255) Nexthop [outgoingIF]: Potential nexthops ... b2:48:7a:c8:a2:65 0.840s (235) b2:48:7a:c8:a2:65 [ wlan1]: 16:d6:4d:3a:3d:d8 (236) b2:48:7a:c8:a2:65 (235) 16:d6:4d:3a:3d:d80.640s (253) 16:d6:4d:3a:3d:d8 [ wlan1]: b2:48:7a:c8:a2:65 (205) 16:d6:4d:3a:3d:d8 (253) C) (MAC: 16:d6:4d:3a:3d:d8) root@OpenWrt:/# batctl o [B.A.T.M.A.N. adv 2011.2.0, MainIF/MAC: wlan1/16:d6:4d:3a:3d:d8 (bat0)] Originator last-seen (#/255) Nexthop [outgoingIF]: Potential nexthops ... 16:d6:4d:3a:3c:3c0.060s (208) 16:d6:4d:3a:3c:3c [ wlan1]: b2:48:7a:c8:a2:65 (182) 16:d6:4d:3a:3c:3c (208) b2:48:7a:c8:a2:650.090s (234) b2:48:7a:c8:a2:65 [ wlan1]: 16:d6:4d:3a:3c:3c (182) b2:48:7a:c8:a2:65 (234) This is a typical state of the tables. We tryed setting the hop pennalty parameter to 1, but the behaviour hasn't changed. -- Message: 4 Date: Tue, 15 Nov 2011 00:43:13 +0100 From: Antonio Quartullior...@autistici.org To: The list for a Better Approach To Mobile Ad-hoc Networking b.a.t.m.a.n@lists.open-mesh.org Subject: Re: [B.A.T.M.A.N.] Problem to find better Route Message-ID:2014234312.ga28...@ritirata.org Content-Type: text/plain; charset=utf-8 Hello Gabriel, On Mon, Nov 14, 2011 at 04:53:22 -0300,gto...@inti.gob.ar wrote: Hi. We are using batman-adv 2011.2.0 with Openwrt Backfire-rc6 on D-Link routers, and we're making some tests with iperf to measure bitrate capabilities between nodes. When we put three nodes aligned we notice that the obtained bitrate between the extreme nodes strongly depends on the batman path between them. To make it clear, we have: A -- B -- C With a dinstance of about 20 meters between A and B, and the same distance between B and C. The problem is that sometimes, A and C get connected directly in terms of batman-adv protocol (checked with batctl o), and when that happens, the bitrates are very poor (less than 1Mbps), like if B wasn't there. In fact we disconnected B and obtained very similar results. Then we reduced tx power settings on A and C, forcing the B hop between them, and we got much better speeds (~20Mbps). We've read about ELP and think that maybe simple OGM messages are not good to measure link quility between A and C in this example, could that be the problem? In that case is there a way to fix this with actual batman-adv algorithms? Thanks in advance! Gabriel I think other people will give you better answer than this one, but just as start: OGM are sent in broadcast, which by definition uses a low rate that implies better transmission than higher rates. Therefore a link having an high TQ doesn't necessarily has a good quality at high rates (as you are experiencing). In my opinion the problem resides in the fact that batman-adv uses broadcast packets to measure link qualities which leads to the aforementioned problem. I don't know if ELP would help in this sense because as far as I know it still uses broadcast packets. Please guys correct me if I am wrong. Cheers, -- Antonio Quartulli ..each of us alone is worth nothing.. Ernesto Che Guevara -- Message: 5 Date: Tue, 15 Nov 2011 09:40:36 +0800 From: Marek Lindner lindner_ma...@yahoo.de To: The list for a Better Approach To Mobile Ad-hoc Networking b.a.t.m.a.n@lists.open-mesh.org Subject: Re: [B.A.T.M.A.N.] Problem to find better Route Message-ID: 20150940.36605.lindner_ma...@yahoo.de Content-Type: Text/Plain; charset=iso-8859-1 Hi, With a dinstance of about 20 meters between A and B, and the same distance between B and C. The problem is that sometimes, A and C get connected directly in terms of batman-adv protocol (checked with batctl o), and when that happens, the bitrates are very poor (less than 1Mbps), like if B wasn't there. In fact we disconnected B and obtained very similar results. would you mind sharing the orignator tables of the involved nodes ? Then we reduced tx power settings on A and C, forcing the B hop between them, and we got much better speeds (~20Mbps). We've read about ELP and think that maybe simple OGM messages are not good to measure link quility between A and C in
[B.A.T.M.A.N.] Problem to find better Route
Hi. We are using batman-adv 2011.2.0 with Openwrt Backfire-rc6 on D-Link routers, and we're making some tests with iperf to measure bitrate capabilities between nodes. When we put three nodes aligned we notice that the obtained bitrate between the extreme nodes strongly depends on the batman path between them. To make it clear, we have: A -- B -- C With a dinstance of about 20 meters between A and B, and the same distance between B and C. The problem is that sometimes, A and C get connected directly in terms of batman-adv protocol (checked with batctl o), and when that happens, the bitrates are very poor (less than 1Mbps), like if B wasn't there. In fact we disconnected B and obtained very similar results. Then we reduced tx power settings on A and C, forcing the B hop between them, and we got much better speeds (~20Mbps). We've read about ELP and think that maybe simple OGM messages are not good to measure link quility between A and C in this example, could that be the problem? In that case is there a way to fix this with actual batman-adv algorithms? Thanks in advance! Gabriel El 14/11/2011 08:00 a.m., b.a.t.m.a.n-requ...@lists.open-mesh.org escribió: Send B.A.T.M.A.N mailing list submissions to b.a.t.m.a.n@lists.open-mesh.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.open-mesh.org/mm/listinfo/b.a.t.m.a.n or, via email, send a message with subject or body 'help' to b.a.t.m.a.n-requ...@lists.open-mesh.org You can reach the person managing the list at b.a.t.m.a.n-ow...@lists.open-mesh.org When replying, please edit your Subject line so it is more specific than Re: Contents of B.A.T.M.A.N digest... Today's Topics: 1. Re: [PATCH] add make install (Sven Eckelmann) 2. Re: [PATCH] add make install (Sven Eckelmann) 3. Re: [PATCH] add make install (Alexey Fisher) -- Message: 1 Date: Mon, 14 Nov 2011 11:21:12 +0100 From: Sven Eckelmanns...@narfation.org To: b.a.t.m.a.n@lists.open-mesh.org Cc: lindner_ma...@yahoo.de Subject: Re: [B.A.T.M.A.N.] [PATCH] add make install Message-ID:1428522.agqkbyp...@sven-laptop.home.narfation.org Content-Type: text/plain; charset=iso-8859-1 On Monday 14 November 2011 10:38:07 Sven Eckelmann wrote: On Monday 14 November 2011 10:11:32 Alexey Fisher wrote: Signed-off-by: Alexey Fisherbug-tr...@fisher-privat.net --- Makefile |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) [...] NAck: Sven Eckelmanns...@narfation.org And also Nack for not updating the README [1] Kind regards, Sven [1] http://www.open-mesh.org/wiki/open-mesh/Contribute#Submitting-patches -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL:http://lists.open-mesh.org/pipermail/b.a.t.m.a.n/attachments/2014/850391c0/attachment-0001.pgp -- Message: 2 Date: Mon, 14 Nov 2011 11:29:36 +0100 From: Sven Eckelmanns...@narfation.org To: Alexey Fisherbug-tr...@fisher-privat.net Cc: b.a.t.m.a.n@lists.open-mesh.org, lindner_ma...@yahoo.de Subject: Re: [B.A.T.M.A.N.] [PATCH] add make install Message-ID:1956205.mqfsxpq...@sven-laptop.home.narfation.org Content-Type: text/plain; charset=utf-8 On Monday 14 November 2011 11:19:19 Alexey Fisher wrote: [...] Thank you, so you will send your patch? I prefer last version, to make testing easier. I personally don't care. Feel free to fix your patch and send a new version (but think about adding the : after install -- the character magically disappeared when I wrote the mail). And don't forget the documentation part as it is always hard to remember everything on the day the release is made, but easy when you just made the patch. :) Thanks, Sven -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL:http://lists.open-mesh.org/pipermail/b.a.t.m.a.n/attachments/2014/329c477e/attachment-0001.pgp -- Message: 3 Date: Mon, 14 Nov 2011 11:37:55 +0100 From: Alexey Fisherbug-tr...@fisher-privat.net To: Sven Eckelmanns...@narfation.org Cc: b.a.t.m.a.n@lists.open-mesh.org, lindner_ma...@yahoo.de Subject: Re: [B.A.T.M.A.N.] [PATCH] add make install Message-ID:4ec0ef83.2060...@fisher-privat.net Content-Type: text/plain; charset=utf-8 On 14.11.2011 11:29, Sven Eckelmann wrote: On Monday 14 November 2011 11:19:19 Alexey Fisher wrote: [...] Thank you, so you will send your patch? I prefer last version, to make testing easier. I personally don't care. Feel free to fix your patch and send a new version (but think about adding the : after install -- the character magically disappeared when I wrote the mail). And don't forget the
Re: [B.A.T.M.A.N.] Multiple DHCP Gateways
Thank you for your answers. I understood clearly how the system should work, but i´m not using the git repository but the 2011.1.0 version. I'll try with the repo to see what happens. Best regards Gabriel Message: 2 Date: Fri, 12 Aug 2011 18:02:20 +0200 From: Antonio Quartullior...@autistici.org To: The list for a Better Approach To Mobile Ad-hoc Networking b.a.t.m.a.n@lists.open-mesh.org Subject: Re: [B.A.T.M.A.N.] Multiple DHCP Gateways Message-ID:20110812160217.gb22...@ritirata.org.org Content-Type: text/plain; charset=utf-8 Hello and thank you for sharing your gw experience with us, On Wed, Aug 10, 2011 at 02:52:06PM -0300, gto...@inti.gob.ar wrote: Hi [CUT] However, when the original gateway becomes worse than the alternative, and the client chooses the new one as preferred (observed with batctl gwl) i noticed that the subsequent request DHCP messages are sent to the original server, even if it doesn?t have the best link. I guess that?s because these subsequent DHCP requests are made as Unicast to the original server and so Batman doesn?t redirect them, Unicast renewal requests are dropped only if the TQ towards the destination is smaller than the current_GW_TQ - GW_THRESHOLD (GW_THRESHOLD = 50). To clarify: In your topology you have three nodes: A, B and C. A and C are GWs. A is the current best GW for B and B got an IP from the DHCP server running on A. Then the link A-- B becomes worse than B-- C. At this point Batman-adv will drop a DHCP unicast renewal request directed to A if and only if TQ(C) - TQ(A) 50 Is this condition verified in your topology when your are observing the renewal DHCP packets? I hope I've been clear. :-) but i wonder how this behavior affects the network balance, because the computers would get tied always to the original DHCP and IP default gateway even if they moved, right? As above. Clients will keep the same GW as long as the link is still usable (difference on TQs greater than 50) Thank you very much Thank you too, Antonio -- Message: 3 Date: Fri, 12 Aug 2011 19:22:28 +0200 From: Marek Lindnerlindner_ma...@yahoo.de To: The list for a Better Approach To Mobile Ad-hoc Networking b.a.t.m.a.n@lists.open-mesh.org Subject: Re: [B.A.T.M.A.N.] Multiple DHCP Gateways Message-ID:201108121922.28786.lindner_ma...@yahoo.de Content-Type: Text/Plain; charset=utf-8 On Friday, August 12, 2011 18:02:20 Antonio Quartulli wrote: In your topology you have three nodes: A, B and C. A and C are GWs. A is the current best GW for B and B got an IP from the DHCP server running on A. Then the link A-- B becomes worse than B-- C. At this point Batman-adv will drop a DHCP unicast renewal request directed to A if and only if TQ(C) - TQ(A) 50 Be aware that only happens if you use the git repository. The DHCP request drop feature was not released yet. What version are you using ? Cheers, Marek -- ___ B.A.T.M.A.N mailing list B.A.T.M.A.N@lists.open-mesh.org https://lists.open-mesh.org/mm/listinfo/b.a.t.m.a.n End of B.A.T.M.A.N Digest, Vol 56, Issue 15 ***
[B.A.T.M.A.N.] Multiple DHCP Gateways
Hi I´m testing the Gateway roaming capabilities of Batman-adv (using 2011.1.0 version). I setted two computers as Gateway servers with DHCP servers running on them and other as Gateway client, configured as class 3. Then i stressed individually the Gateway server´s links to make the client choose the not stressed one. I confirmed that when te client sends a layer 3 broadcast DHCP request, Batman redirects that request only to the best gateway. However, when the original gateway becomes worse than the alternative, and the client chooses the new one as preferred (observed with batctl gwl) i noticed that the subsequent request DHCP messages are sent to the original server, even if it doesn´t have the best link. I guess that´s because these subsequent DHCP requests are made as Unicast to the original server and so Batman doesn´t redirect them, but i wonder how this behavior affects the network balance, because the computers would get tied always to the original DHCP and IP default gateway even if they moved, right? Thank you very much
