Re: [B.A.T.M.A.N.] batman majareta? I can batctl ping but not ping
On Sat, Jul 21, 2012 at 6:38 PM, Antonio Quartulli or...@autistici.org wrote: Last week I came across this bug again, with the latest firm which includes the fixes mentioned, pushed by Marek. We were kinda in a hurry so i didn't have much time to check it thoroughly, so there's a *slim* chance it was just a coincidence, such as very poor signal giving erratic results. But if I recall correctly Nico Echaniz did stump on this too, using the latest firm. How did you solve it then? Rebooting? A reboot did, yes. So, although i can't confirm it 100%, it seems so far the fixes didn't help :( We'll keep an eye on it and try a batctl l Yes, please. Remember to set the TT log level (batctl ll tt) before launching batctl l. Actually it would be very interesting to see the log of the involved nodes during the wrong behaviour period. This time it solved itself after some brief time (a minute) but the symptoms were the same. So I could catch some logs, http://pastebin.com/MEENj94i sadly, i wasn't fast enough to get a live log from the node involved in the inconsistency as you suggested, so the report might be pretty useless. But at least now I got an idea where we are heading :) Thank you very much! Thanks a lot for your support people! Gui
Re: [B.A.T.M.A.N.] batman majareta? I can batctl ping but not ping
On Sun, Jul 22, 2012 at 7:57 AM, Guido Iribarren guidoiribar...@buenosaireslibre.org wrote: This time it solved itself after some brief time (a minute) but the symptoms were the same. So I could catch some logs, http://pastebin.com/MEENj94i sadly, i wasn't fast enough to get a live log from the node involved in the inconsistency as you suggested, so the report might be pretty useless. from this particular node i ran previous report (colmena-casa) that was rebooted recently, L3 ping to all of the network had the same issue, (no replies for a minute or so) so i had the chance to recreate the situation several times. Turns out, a batctl ll tt ; batctl l on the nodes mentioned in the inconsistencies gave no output at all, so the previous pastebin report is in fact complete :P Looks like the inconsistency is being resolved locally between neighbours, without the need to contact the far end of the network (which is coherent with what's described in the wiki) In any case, AFAIR previous ocurrences of the bug didn't resolve by themselves (in a reasonable amount of time) so what I'm looking at now might be perfectly normal behaviour? (tt tables take some time to propagate?)
Re: [B.A.T.M.A.N.] batman majareta? I can batctl ping but not ping
Resurrecting thread... On Mon, Jul 2, 2012 at 11:36 AM, Antonio Quartulli or...@autistici.org wrote: Hello! Has debug support been compiled in batman-adv? IF yes, it would be interesting so see the output of the tt log (batctl ll tt; batctl l) Ah, I should have re-read this before :( Recently we fixed a bug that which fix has not been released yet. If we are sure that this is the cause, you could eventually try an upgrade to a more recente dev-version. But let's see the log first (if possible) -- Antonio Quartulli Last week I came across this bug again, with the latest firm which includes the fixes mentioned, pushed by Marek. We were kinda in a hurry so i didn't have much time to check it thoroughly, so there's a *slim* chance it was just a coincidence, such as very poor signal giving erratic results. But if I recall correctly Nico Echaniz did stump on this too, using the latest firm. So, although i can't confirm it 100%, it seems so far the fixes didn't help :( We'll keep an eye on it and try a batctl l Cheers! Gui
Re: [B.A.T.M.A.N.] Internet gateway or not: dhcp or static ip?
Please do! Reuse it, modify it, adapt it, i didn't think they were enough lines of code to reserve a gpl notice :) the intention is indeed to make this available, upstream in openwrt official packages, but i'm still getting the grip on sending patches and stuff in the meantime any feedback is much appreciated On 7/19/12, Geneviève Bastien gbast...@versatic.net wrote: Hi Guido, Thanks for the links. I guess we have the same general idea, yours is more developed than mine. Can I borrow some of your scripts? These packages could be made available to the batman community. I think they solve a common scenario and could be useful to others, though I did learn a lot about hotplug by working on this problem :D Cheers, Geneviève On 12-07-18 09:35 PM, Guido Iribarren wrote: Another stab at this, which solves a slightly different scenario: https://bitbucket.org/guidoi/batmesh/raw/ee7042b01ebe/packages/batman-adv-auto-gw-mode/files/etc/hotplug.d/net/99-batman-gw This makes no assumptions about the interface (static or dhcp), but instead asks for a lease in an alias (br-lan:ipv4) this is part of a bigger idea https://bitbucket.org/guidoi/batmesh/src/ee7042b01ebe/packages/batman-adv-auto-gw-mode/ in a nutshell: every node is initially set to gw_mode=client, with static ip and DHCP server (through dnsmasq) offering leases. so if a client connects to the cloud, it gets an ipv4 and has basic connectivity with other clients (bat cloud has no internet access) if one node has internet connection, sets gw_mode=server, (either manually or by some magic script) , and this is recognized by other nodes by this hotplug.d hook, which requests an ipv4 (so that routers can do opkg update and sync ntp time) and at the same time kills the local dhcp server, so that new clients get the lease from the internet gateway dhcp. On Wed, Jul 18, 2012 at 10:18 PM, Geneviève Bastien gbast...@versatic.net wrote: Hi! I had a chat the other day on IRC about how to assign ip addresses whether there is an internet gateway available or not. Here is the problem and the solution I came up with. Let me know if that makes sense or if I'm complicating my life. * Problem * Our network is still small, there may or may not be an internet gateway available on it, it doesn't matter. From what I read here http://www.open-mesh.org/projects/batman-adv/wiki/Gateways for nodes to have access to the internet, the internet gateway has to be a dhcp server. The node requests an ip by dhcp and then knows what the default route is. But if the gateway disappears, there is no more dhcp server, the nodes do not have ip addresses and the mesh network is about useless. But if I set nodes with static ips, then the mesh is routable all the time, but nodes do not know the default route to reach the internet. Am I right so far? * Solution * Someone on irc pointed me out to this page: http://www.open-mesh.org/projects/batman-adv/wiki/Uevent I use this uevent to send a dhcp request if a gateway becomes available or go back to a static ip if all gateways are gone. Attached is the hotplug script I use. It is in /etc/hotplug.d/net/99-batman-adv-gw. It supposes the interface is configured by default with a static ip. It works perfectly, but I can't believe there is no simpler solution to this. Our problem should be a quite common one. What is the general solution to it? Thanks, Geneviève
Re: [B.A.T.M.A.N.] Internet gateway or not: dhcp or static ip?
Another stab at this, which solves a slightly different scenario: https://bitbucket.org/guidoi/batmesh/raw/ee7042b01ebe/packages/batman-adv-auto-gw-mode/files/etc/hotplug.d/net/99-batman-gw This makes no assumptions about the interface (static or dhcp), but instead asks for a lease in an alias (br-lan:ipv4) this is part of a bigger idea https://bitbucket.org/guidoi/batmesh/src/ee7042b01ebe/packages/batman-adv-auto-gw-mode/ in a nutshell: every node is initially set to gw_mode=client, with static ip and DHCP server (through dnsmasq) offering leases. so if a client connects to the cloud, it gets an ipv4 and has basic connectivity with other clients (bat cloud has no internet access) if one node has internet connection, sets gw_mode=server, (either manually or by some magic script) , and this is recognized by other nodes by this hotplug.d hook, which requests an ipv4 (so that routers can do opkg update and sync ntp time) and at the same time kills the local dhcp server, so that new clients get the lease from the internet gateway dhcp. On Wed, Jul 18, 2012 at 10:18 PM, Geneviève Bastien gbast...@versatic.net wrote: Hi! I had a chat the other day on IRC about how to assign ip addresses whether there is an internet gateway available or not. Here is the problem and the solution I came up with. Let me know if that makes sense or if I'm complicating my life. * Problem * Our network is still small, there may or may not be an internet gateway available on it, it doesn't matter. From what I read here http://www.open-mesh.org/projects/batman-adv/wiki/Gateways for nodes to have access to the internet, the internet gateway has to be a dhcp server. The node requests an ip by dhcp and then knows what the default route is. But if the gateway disappears, there is no more dhcp server, the nodes do not have ip addresses and the mesh network is about useless. But if I set nodes with static ips, then the mesh is routable all the time, but nodes do not know the default route to reach the internet. Am I right so far? * Solution * Someone on irc pointed me out to this page: http://www.open-mesh.org/projects/batman-adv/wiki/Uevent I use this uevent to send a dhcp request if a gateway becomes available or go back to a static ip if all gateways are gone. Attached is the hotplug script I use. It is in /etc/hotplug.d/net/99-batman-adv-gw. It supposes the interface is configured by default with a static ip. It works perfectly, but I can't believe there is no simpler solution to this. Our problem should be a quite common one. What is the general solution to it? Thanks, Geneviève
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
Re: [B.A.T.M.A.N.] newbie error or repo misconfig?
On Tue, Jul 10, 2012 at 2:13 PM, Tony Godshall t...@of.net wrote: 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 You probably downloaded a snapshot (daily build), flashed the TL-WR703n, and after a few days tried to install kmod-batman-adv. The problem: every day the whole package tree is discarded and rebuilt, so a particular trunk rev snapshot will only be able to opkg install kmod-* successfully only for a few days (or weeks, or few hours in worst-case scenario) After that, the http://downloads.openwrt.org/ package tree corresponding to your binary is gone forever. Alternatives: a) download today's trunk snapshot, reflash your router, and opkg install kmod-* right away. b) download svn source, compile your binary with kmod-batman-adv included, reflash. c) download svn source, compile packages and set up your own private repo for trunk rX Cheers!
Re: [B.A.T.M.A.N.] Question about Babel
I guess his sarcasm was as evident as yours, First result on google for openmesh yields www.open-mesh.com which might be what you're looking for (i didn't read your hole thread) Have a nice day! Gui On 7/7/12, Catherine Lowenstein clowenst...@ymail.com wrote: Look, Catherine, please try being a little bit more autonomous. Take the batman-adv distribution, look at the list of main authors, and drop them a friendly note. I'm sure they'll be glad to chat with you. I already sent them the mail using Cc. But I am still missing the company name that you seem to know. Please do not contact me any further on this subject. And please do not copy the mailing lists with your reply. First you want to get paid for your information and now you stop without sending me your price model? Sincerely, I am, Catherine Lowenstein
[B.A.T.M.A.N.] 2012.2 OGMs over ethernet issue?
Hello again nice folks, I updated today another segment of the network with just 4 nodes, to batman-adv 2012.2 (the one i compiled yesterday with simon patches for blaII, marek stability fixes, and debug log enabled , yikes!) and i couldn't get batman to work over wired ethernet?? (?) P -(50mts wlan)- D -(ubnt transparent bridge) 2km -- C \eth---/ Node P and D connected by ethernet on eth0 but close enough that could also see each other through adhoc wlan, with bla enabled, correctly preferred ethernet connection to communicate between them (iperf yielded 92mbps), so far so good. now, node D and C, too far away from each other to communicate over wlan, but connected by a lng eth cable (mediated by a wds transparent bridge) wouldn't find each other batman originator. C originator table was empty, and D only showed P. I thought the transparent bridge was misbehaving, so I tried in a simpler setup using P and D, with the wifi off: but after disabling wlan0 (batctl if del wlan0-2) and adding eth0 (batctl if add eth0) on both nodes, batman could not see each other anymore :( i thought i was doing something wrong, so i tried in different ways, but could not get it to work. batctl td eth0 shows both outgoing OGMs from local , and incoming OGMs from remote, but batctl l only reported outgoing OGMs. http://pastebin.com/7DDUaXu1 diego is local node (D), palmeras is on the other side of the ethernet cable (P) (and jure is further away, connected to palmeras by adhoc wlan, not illustrated in the previous ascii art) i hope i'm overlooking something really obvious? Have a nice weekend! Gui
Re: [B.A.T.M.A.N.] BLAII + gw_mode, DHCP sometimes gets dropped
Your patch works flawlessly Simon, I sysupgraded f8d11504758 with the patched batman, and DHCP requests are back to normal when using gw_mode=client I patched colmena-casa first, but it didn't make a difference; which was expected, since colmena-casa is just a backbone gateway, and it doesn't have the actual DHCP server running, as such, it's only job was to forward unicast requests to f8d11504758, which was already doing fine. The problem was that f8d11504758 was dropping the packets, and with your patch it doesn't anymore. Thanks a lot! On Wed, Jul 4, 2012 at 3:46 PM, Guido Iribarren guidoiribar...@buenosaireslibre.org wrote: On Wed, Jul 4, 2012 at 3:30 PM, Simon Wunderlich simon.wunderl...@s2003.tu-chemnitz.de wrote: Sorry, my fault. Will send a patch based on maint in a minute. Applying ./patches/-batman-adv-check-incoming-packet-type-for-bla.patch using plaintext: patching file bridge_loop_avoidance.c patching file bridge_loop_avoidance.h patching file soft-interface.c Now i'm having fun, heh Thanks! Gui
Re: [B.A.T.M.A.N.] BLAII + gw_mode, DHCP sometimes gets dropped
On Wed, Jul 4, 2012 at 6:12 AM, Simon Wunderlich simon.wunderl...@s2003.tu-chemnitz.de wrote: Hello Guido, On Tue, Jul 03, 2012 at 05:07:17PM -0300, Guido Iribarren wrote: Hello there again, I have observed a problem since updating to 2012.2 and enabled BLAII I'm compiling logs to understand what's happening, but as always, reading logs only gets me more lost :( So here i am again begging for help There are some debug levels for BLA as well, and you can now get the claimlist with batctl (which is basically the list of clients a gateway feels responsible for) - this may help for debugging. But first, we should clarify some more details for your setup. Yes, I've seen the cl command, but didn't completely understand how to interpret it. For example, right now I see the clients claimed in the cl of mesh nodes, and even the same client claimed in different nodes. ( when I say mesh nodes, and in the rest of the email, i'm referring to http://www.open-mesh.org/wiki/batman-adv/Bridge-loop-avoidance-II#Definitions ) i.e. sample mesh-nodes: root@charly:~# batctl cl Claims announced for the mesh bat0 (origcharly, group id 6412) Client VID Originator[o] (CRC ) * 00:25:d3:f5:93:76 on-1 bycharly [x] (77f9) * f8d1113b6e66_eth0 on-1 bycharly [x] (77f9) root@hquilla:~# batctl cl Claims announced for the mesh bat0 (orig hquilla, group id 82cb) Client VID Originator[o] (CRC ) * 00:25:d3:f5:93:76 on-1 by hquilla [x] (c72e) * 00:24:81:4b:ea:6d on-1 by hquilla [x] (c72e) maybe that's fine because they have different group ids? (??) is there any documentation on the cl output? as far i could interpret, CRC identifies a particular version of a table, [o] = [x] means this is claimed by myself group id identifies different backbones (like in this case:) http://www.open-mesh.org/wiki/batman-adv/Bridge-loop-avoidance-Testcases#Two-LANs-connected-by-one-mesh and VID, is always set to -1 :P oh, mybe it's vlan id (?) since i'm not using VLANs the setup is the same I described in yesterday's attachment, but what's not pictured is an ethernet cable between colmena-casa and f8d11504758. f8d11504758 is the only router that connects to the internet (through WAN cable), and it's also the only one that has dnsmasq running and gw_mode=server. All the other nodes have gw_mode=client All of the nodes have bridge_loop_avoidance=1 (even though there are no other utp connections, so it could in fact be enabled only on colmena-casa and f8d11504758) with this setup, dhcp requests from the mesh sometimes get lost, either they don't reach f8d11504758 or the reply doesn't get out Questions: * which node runs the DHCP server? colmena-casa, f8d11504758 or something else? Only the node f8d11504758 runs a DHCP server (dnsmasq) on its interface br-lan no other dhcp server is running on the network * at which point is DHCP getting lost? is the DISCOVER/REQUEST from the client getting lost, or the reply from the server? Well, I just managed to get a clarifying tcpdump! hquilla sent a select (REQUEST) that reached the wlan0-2 (mesh) interface of f8d11504758 and it was silently dropped (didn't appear on a batctl td of bat0) this repeated several times, until a lucky REQUEST managed to pass through, was sniffed at bat0, and got a reply from dnsmasq I couldn't see any difference between the unlucky and lucky REQUESTs or DISCOVERs, but running a batctl cl -w1 did the trick: when the client is currently claimed by f8d11504758 as in * hquilla_eth0 on-1 by f8d11504758 [x] (d38b) both the REQUESTs and DISCOVERs reach dnsmasq fine but if the client is currently claimed by colmena-casa as in * hquilla_eth0 on-1 by colmena-casa [ ] (3d7f) these discover/requests get dropped by batman when they arrive through wlan0-2 * Can you specify sometimes a little bit more? What are the circumstances, how often does it happen? Well, most of the time :) dhcp clients keep trying and eventually they get the lease, but in unlucky times that might even take hours :( at any point in time, there are lucky clients who can get a lease and renew it without problem, and other unlucky that can't get a reply at all. from what i've just seen at the batctl cl, this luck is related to being claimed by the right backbone node. this didn't happen with batman 2012.1 , setup as indicated by the BLAI wiki page (batctl if add br-lan) furthermore, with batman 2012.2 , BLAII activated, but gw_mode=off in all nodes, DHCP also works fine. Mhm, that's rather strange ... we had a similar problem when ap isolation was activated. Do you have this feature turned on? Nope So DHCP is only having problems when gw-mode is turned on colmena-casa and f8d11504758? gw-mode is activated in all mesh nodes, not only in colmena-casa and f8d11504758 it's set to client
Re: [B.A.T.M.A.N.] BLAII + gw_mode, DHCP sometimes gets dropped
On Wed, Jul 4, 2012 at 9:43 AM, Guido Iribarren guidoiribar...@buenosaireslibre.org wrote: On Wed, Jul 4, 2012 at 6:12 AM, Simon Wunderlich simon.wunderl...@s2003.tu-chemnitz.de wrote: Hello Guido, gw-mode is activated in all mesh nodes, not only in colmena-casa and f8d11504758 it's set to client on every node except f8d11504758, which has gw_mode=server As far as i can recall, disabling gw_mode=client in every mesh node, solved the problem. But now that i found out about this batctl td thing, i'm in doubt about the validity of the previous statement :( i should check again and report. I can now confirm this. if i set gw_mode=off in a particular mesh node, DHCP requests originating from that node work correctly, even when the mesh node client is claimed by the wrong backbone node. in this scenario: * ruth_eth0 on-1 by colmena-casa [ ] (7a27) * hquilla_eth0 on-1 by colmena-casa [ ] (7a27) root@ruth:~# batctl gw off root@ruth:~# /sbin/udhcpc -t 0 -i br-lan:ipv4 -f -R udhcpc (v1.19.4) started Sending discover... Sending select for 10.254.0.131... Lease of 10.254.0.131 obtained, lease time 600 root@hquilla:~# batctl gw client root@hquilla:~# /sbin/udhcpc -t 0 -i br-lan:ipv4 -f -R udhcpc (v1.19.4) started Sending discover... Sending discover... Sending discover...^C when hquilla sends the request, this is received at f8d11504758 interface wlan0-2 BAT colmena-casa f8d11504758: UCAST... and gets dropped (doesn't reach dnsmasq) when ruth (gw_mode=off) sends the request, this is received at f8d11504758 interface wlan0-2 BAT colmena: BCAST, orig ruth, .. (then rebroadcasted several times) and it reaches dnsmasq properly. If you prefer the raw batctl td for some eye-injuring reason, here you go: http://pastebin.com/HNBg01hR hope that helps! Gui
Re: [B.A.T.M.A.N.] BLAII + gw_mode, DHCP sometimes gets dropped
On Wed, Jul 4, 2012 at 11:05 AM, Simon Wunderlich simon.wunderl...@s2003.tu-chemnitz.de wrote: Hey Guido, thanks again for the good debugging, that really helped to understand the problem :) Thanks free software! :D I've sent a patch, is it possible for you to apply it and retry? it should be enough to update the two gateway nodes. Definitely! here's the output, tho: Applying ./patches/-batman-adv-check-incoming-packet-type-for-bla.patch using plaintext: patching file bridge_loop_avoidance.c Hunk #1 succeeded at 1351 with fuzz 1 (offset -17 lines). Hunk #2 FAILED at 1378. Hunk #3 FAILED at 1423. 2 out of 3 hunks FAILED -- saving rejects to file bridge_loop_avoidance.c.rej patching file bridge_loop_avoidance.h Hunk #1 FAILED at 21. Hunk #2 FAILED at 42. 2 out of 2 hunks FAILED -- saving rejects to file bridge_loop_avoidance.h.rej patching file soft-interface.c Hunk #1 FAILED at 274. Hunk #2 FAILED at 323. 2 out of 2 hunks FAILED -- saving rejects to file soft-interface.c.rej Patch failed! Please fix ./patches/-batman-adv-check-incoming-packet-type-for-bla.patch! i'm trying to apply against openwrt@torvic:~/trunk/feeds/packages/net/batman-adv$ svn info Path: . URL: svn://svn.openwrt.org/openwrt/packages/net/batman-adv Repository Root: svn://svn.openwrt.org/openwrt Repository UUID: 3c298f89-4303-0410-b956-a3cf2f4a3e73 Revision: 32587 Node Kind: directory Schedule: normal Last Changed Author: marek Last Changed Rev: 32579 Last Changed Date: 2012-07-02 13:20:20 -0300 (Mon, 02 Jul 2012) Visually inspecting the rejects, seems my source code still doesn't have the batadv_ prefix in functions names. i.e.: int bla_rx(struct bat_priv *bat_priv, struct sk_buff *skb, short vid) I've seen many patches flying around dealing with the batadv_ prefix for dave, but didn't pay much attention to them: which of those should i grab? Or, Simon, could you kindly send another patch that i can apply cleanly to r32587 of svn://svn.openwrt.org/openwrt/packages/net/batman-adv in any case, i see the changes are simple, so i *could* try a manual apply of the patch... but last time i tried (with other patch), it got overwritten by openwrt build system. Thanks a lot for the support! Gui Cheers Simon -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk/0TYwACgkQrzg/fFk7axbznwCg5oyyF4UaWJBV8GXztFSGG8sa vnAAoJYcgNuCcdA5fZKrIvaUE888FzSI =zd3Q -END PGP SIGNATURE-
Re: [B.A.T.M.A.N.] BLAII + gw_mode, DHCP sometimes gets dropped
On Wed, Jul 4, 2012 at 3:30 PM, Simon Wunderlich simon.wunderl...@s2003.tu-chemnitz.de wrote: Sorry, my fault. Will send a patch based on maint in a minute. Applying ./patches/-batman-adv-check-incoming-packet-type-for-bla.patch using plaintext: patching file bridge_loop_avoidance.c patching file bridge_loop_avoidance.h patching file soft-interface.c Now i'm having fun, heh Thanks! Gui
[B.A.T.M.A.N.] BLAII + gw_mode, DHCP sometimes gets dropped
Hello there again, I have observed a problem since updating to 2012.2 and enabled BLAII I'm compiling logs to understand what's happening, but as always, reading logs only gets me more lost :( So here i am again begging for help the setup is the same I described in yesterday's attachment, but what's not pictured is an ethernet cable between colmena-casa and f8d11504758. f8d11504758 is the only router that connects to the internet (through WAN cable), and it's also the only one that has dnsmasq running and gw_mode=server. All the other nodes have gw_mode=client All of the nodes have bridge_loop_avoidance=1 (even though there are no other utp connections, so it could in fact be enabled only on colmena-casa and f8d11504758) with this setup, dhcp requests from the mesh sometimes get lost, either they don't reach f8d11504758 or the reply doesn't get out this didn't happen with batman 2012.1 , setup as indicated by the BLAI wiki page (batctl if add br-lan) furthermore, with batman 2012.2 , BLAII activated, but gw_mode=off in all nodes, DHCP also works fine. So, a few questions arise: is it a problem to activate bridge_loop_avoidance=1 in all nodes, regardless of the fact that they need it or not? (that is, it is activated on nodes that don't have any ethernet cables connected and couldn't possibly create a bridge loop) would it make a difference, if I add br-lan to bat0 (batctl if add br-lan) the way I used to do with batman 2012.1 ? any other thoughts or ideas? thanks as always! Gui
Re: [B.A.T.M.A.N.] batman majareta? I can batctl ping but not ping
I used arping, with and without -b , and seemed like i could narrow the problem down to incoming broadcast packet handling, but further tests just left me more puzzled! Well, seems colmena is the uncooperative bathost another log: http://pastebin.com/FMD9Lieq that can be summarized as follows ### From COLMENA-CASA, can ping bochita but not ana ### From PEREYRA, can ping bochita but not ana ### From COLMENA, works perfect to both destinations colmena-casa and pereyra must pass through colmena, which is for some reason allowing batctl pings , ogms , and whatnot passthrough in its way to ana, but no ICMP echo requests, or tcp traffic whatsoever if it's final destination is ana. if final destination is bochita, everything works as expected. Any ideas? I'm going to delay rebooting colmena as long as i can, in case someone comes up with an insightful test to run :) Gui
Re: [B.A.T.M.A.N.] batman majareta? I can batctl ping but not ping
Hi Marek! Just to confirm and avoid useless compiling PKG_VERSION:=2012.2.0 BATCTL_VERSION:=2012.2.0 PKG_MD5SUM:=68967ed1df709de18ab795722dde9341 BATCTL_MD5SUM:=7abd284098c514d3f2858e8a956c495e ~/trunk/feeds/packages/net/batman-adv$ svn info . Path: . URL: svn://svn.openwrt.org/openwrt/packages/net/batman-adv Repository Root: svn://svn.openwrt.org/openwrt Repository UUID: 3c298f89-4303-0410-b956-a3cf2f4a3e73 Revision: 32578 Node Kind: directory Schedule: normal Last Changed Author: marek Last Changed Rev: 32578 Last Changed Date: 2012-07-02 12:51:27 -0300 (Mon, 02 Jul 2012) Given the date and the author ;) I assume this rev should do the trick, right? Thanks a lot! Gui On Mon, Jul 2, 2012 at 12:52 PM, Marek Lindner lindner_ma...@yahoo.de wrote: On Monday, July 02, 2012 16:36:04 Antonio Quartulli wrote: Recently we fixed a bug that which fix has not been released yet. If we are sure that this is the cause, you could eventually try an upgrade to a more recente dev-version. But let's see the log first (if possible) You don't need the development version. I pushed these fixes into the latest batman-adv trunk package. If you update your package you should get them. Cheers, Marek
[B.A.T.M.A.N.] batman-adv gw_mode and ipv6 router advertisements
Hello everyone, in the deploy of DeltaLibre (a local WCN very similar to EigenNet (part of ninux) in Italy) i'm facing a dilemma: i'm currently using batman-adv gw_mode client in all nodes, and the ones that connect directly to internet through an ISP have gw_mode = server This way, clients have their DHCP requests transparently unicasted to the 'best' gateway, and get a corresponding IPv4 and default gw. Which is great. But in IPv6 there's no equivalent functionality. If two routers on the same broadcast domain (batman-adv cloud) run radvd and announce two different prefixes, all hosts on the network autoconfigure 2 ips, one in each prefix. Then, AFAIU, it's up to the client to choose between the announced gateways, to send the traffic. Are there any plans of implementing in batman-adv something analog to the mangling done on DHCPv4 packets, to RA packets as well? (the mechanism would be the inverse: instead of unicasting queries and replies, propagate to clients only 1 RA packet out of all incoming; decide which one to propagate based on gw_mode current logic) Or, at least, extend the current mangling done in DHCPv4 packets to DHCPv6 packets as well? I would *love* to simply show some code instead of asking 'wishlist' questions, but sadly i'm not a programmer :( Thanks a lot, Guido pd. I'm pretty new to ipv6, so It's possible that i'm overlooking 'obvious' concepts in my questions: in that case you can politely tell me to RTFM :)
Re: [B.A.T.M.A.N.] batman-adv gw_mode and ipv6 router advertisements
On Sun, Jun 10, 2012 at 8:29 PM, Marek Lindner lindner_ma...@yahoo.de wrote: On Monday, June 11, 2012 07:14:27 Guido Iribarren wrote: Or, at least, extend the current mangling done in DHCPv4 packets to DHCPv6 packets as well? What makes you think DHCPv6 is not working ? It should ... Nothing but my own unfounded prejudice... loving batman-adv every day a bit more! one of these days i'm going to try batctl solve life cheers!
[B.A.T.M.A.N.] MAC discovery protocol for filling /etc/bat-hosts
Martin said: On 05/08/2012 10:52 PM, Guido Iribarren wrote: mDNS solutions like avahi translate between hostnames and ips, while batman visualization deals with MACs, and those cannot necessarily be obtained from IPs (in some cases, ARP will help, but won't work in interfaces without IPs) maybe i'm ignoring some MAC discovery protocol? While reading about TLV's on wikipedia[1], I came across a MAC discovery protocol[2], LLDP, which eventually lead me to OpenLLDP[3]. If this also works on 802.11, I think we have a winner :) Happy hacking! [1] http://en.wikipedia.org/wiki/Type-length-value [2] http://en.wikipedia.org/wiki/Link_Layer_Discovery_Protocol [3] http://openlldp.sourceforge.net/ -- Kind Regards Martin Hundebøll It looks promising: did on two different routers connected by batman 2012.1.0 with adhoc interfaces # opkg list lldpd lldpd - 0.3-3 - LLDP (Link Layer Discovery Protocol) # opkg install lldpd # /etc/init.d/lldpd ### wait a couple of minutes # lldpctl |head --- LLDP neighbors --- Interface: wlan0-2 ChassisID: 54:e6:fc:be:29:d1 (MAC) SysName: colmena SysDescr: Linux 3.3.2 #1 Thu May 24 17:06:23 UTC 2012 mips MgmtIP:10.6.2.170 Caps: Bridge(E) Wlan(E) # lldpctl |egrep (SysName|PortID|PortDescr)|sed -rn s/[^:]*: *([[:graph:]]*)( \(MAC\))?$/\1/;p; | sed -nr N;N;s/\n/|/g;s/(.*)\ |(.*)\|(.*)/\2 \1_\3/;p /etc/bat-hosts # cat /etc/bat-hosts 56:e6:fc:be:29:d4 colmena_wlan0-2 3a:3c:98:fe:55:2f colmena_bat0 ### Yes, that's a repulsive 5 min sed hack. I feel sorry for your eyes. Unfortunately, lldpd 0.3 is designed to work with just 1 neighbour on each interface. So when i started lldpd on a third node in the mesh network, didn't work as expected. Version 0.4alpha has an option to disable this behaviour and apparently show many neighbours per interface. Haven't had the time to compile and try it. Thanks Martin! Guido
Re: [B.A.T.M.A.N.] Fwd: Batman-adv simple configuration example
On Thu, May 10, 2012 at 7:16 PM, Pedro Nuno Costa Rodrigues pedro...@sapo.pt wrote: (the problem is probably the definition who is the master -IP distribution and so on...)(i used the option force 1 in the dhcp configuration file, but didn't worked...) if we start the client first it will not be possible to access the internet, supposed the ISP is connected with the server router... the ad-hoc mode and the mesh network works the same way (works fine)... You probably want to use config dhcp lan option ignore 1 in client router, instead of using option force 1 in server router http://wiki.openwrt.org/doc/uci/dhcp#dhcp.pools is a issue to study (yes i know that is a openwrt problem, and there are a bunch of openwrt problems here).My gold is to contribute with something here, and to get my job done as well. Of all the problems I bumped into, just a couple turned out to be openwrt problems, and because of using Attitude Adjustment. Most of the issues were my fault, of not reading the documentation thoroughly, or not understanding it :) Regards, Guido
Re: [B.A.T.M.A.N.] [PATCHv2] batman-adv: fix visualization output without neighbors on the primary interface
supply its own hostname for vis in my opinion. I think one possibility to add this without breaking compatiblity would be adding a hostname record after the neighbor entries in the vis packets. Flooding the network with arbitrary data like hostnames, service announcements, weather info, etc comes up from time to time but it often boils down to the question: Why does it have to be in the kernel ? There are several ways to implement this feature in user space today without changing the kernel code. Regards, Marek I see your point, but then one could also ask why the visualization has to be in the kernel at all... visualization just means collecting information batman is already handling. neighbour information is essential to normal working, and generating a vd dot just exports that info. hostnames, (ip addresses, etc) on the other hand, are not of interest to current code That said, I would also love to find a solution to this, since maintaining the /etc/bat-hosts in the nodes simply doesn't escalate in my opinion, and Marek' suggestion about several ways to implement this feature in user space today is not entirely clear to me: mDNS solutions like avahi translate between hostnames and ips, while batman visualization deals with MACs, and those cannot necessarily be obtained from IPs (in some cases, ARP will help, but won't work in interfaces without IPs) maybe i'm ignoring some MAC discovery protocol? Cheers, Guido
Re: [B.A.T.M.A.N.] Batman-adv simple configuration example
On Tue, May 1, 2012 at 4:34 PM, Sven Eckelmann s...@narfation.org wrote: Some questions here can be answered by reading the documentation section under http://www.open-mesh.org/wiki/batman-adv/ - I will not mention it in this text. Please just check it out and read about things like gateway support and so on. In case you're still fighting with this, I've just added to the documentation some simple configuration examples that actually work. http://www.open-mesh.org/wiki/batman-adv/Openwrt-config-examples While the examples are a bit more complex since it handles up to 3 radios per node, you can understand the logic in there (how is the bridge setup, and which interfaces are added to bat0) and scale it down. Hope that helps, On Tue, May 1, 2012 at 4:06 PM, Pedro Nuno Costa Rodrigues pedro...@sapo.pt wrote: WLAN configuration config interfacewifi option protostatic option ifname wlan0 option ipaddr 10.1.1.1 for router 2 is 10.1.1.2 option netmask 255.255.255.0 option mtu 1528 You should never assign an IP to an interface which forms part of a bridge, or is managed by batman-adv (i.e. it was added to bat0) that config snippet should only have ifname, mtu and proto(=none) Cheers!
Re: [B.A.T.M.A.N.] [Interop-dev] collaboration-group on batman-adv installation application
On Sat, Apr 28, 2012 at 5:57 PM, 3zl Trizonelabs trizonel...@googlemail.com wrote: good to have some input ! i do agree on the poit to have relevant informations on the batman wiki, but i don't feel a wiki is the right tool for interactive collaboration. It might be suitable more for nearly finished dokumentation. Teamwork must have some noise which ist filtered out once cooking is done and dinner is ready. ;-) I agree on that.. my proposal was a simple maillist for that, even though i'm aware there are much more complete / complex solutions Anybody might have a look at http://joker.eu5.org/ which represents ROUGHLY what i have in mind. At first glance I thought it was simply a static PNG mockup. When I found out it was actually interactive, I gave it a couple of clicks but got lost :( It's done with Mindmanager and exported to html so for me it's very easy to reoganize the subjects whilst orking on it. Whatever tool we agree to use, its fine for me; giving a chance someone has time and have a look at Teamlab or similiar pse send me a personal msg to hand the access code for playing around. I must confess I never heard of Mindmanager or Teamlab, but it should be noted that I only have access to an unmetered, broadband, stable connection recently (months) for the last couple of years, internet for me has implied ~1000ms latency = no-keyboard-feedback ssh, gmail through mobile app,... and ajax = definitely *asynchronous*jax :P 2012/4/28 Guido Iribarren guidoiribar...@buenosaireslibre.org: On Sat, Apr 28, 2012 at 8:40 AM, Mitar mi...@tnode.com wrote: Hi! To keep things tidy, should we nest everything under http://interop.wlan-si.net/wiki/WikiSquatters/ ? ;) No need for that. Maybe just /wiki/Gudes/ or /wiki/Tutorials/? Done, http://www.open-mesh.org/wiki/batman-adv/Openwrt-config-examples made a quick link at the end of http://www.open-mesh.org/wiki/batman-adv/Quick-start-guide Again, i'm still not sure if it's too openwrt-specific to be there, so if i'm going offtopic just say so :) Cheers!
Re: [B.A.T.M.A.N.] Batman with Ubiquiti SDK
On Sun, Apr 29, 2012 at 5:27 AM, fboehm fbo...@aon.at wrote: Hi Mitar, what Ubiquiti products are you using? Because they have the older 802.11a/b/g based product series and the newer 802.11n based with their proprietary Airmax wireless drivers. I am asking because the Airmax products have been upgraded to kernel 2.6.32 recently. Indeed, XM.v5.3# uname -a Linux hostname 2.6.15-5.2 #1 Fri Jan 14 14:43:07 EET 2011 mips unknown XM.v5.5# uname -a Linux hostname 2.6.32.54 #1 Fri Apr 6 14:56:27 EEST 2012 mips unknown (run on two nano loco m900, the latter with latest firmware)
Re: [B.A.T.M.A.N.] collaboration-group on batman-adv installation application
19 apr 2012 kl. 18:39 skrev 3zl Trizonelabs: I would like to organize a kind of collaboration-site on all practical aspects of batman-adv installation. It could be a platform to discuss, interchange know how dealing with all aspects of batman-adv mesh application A maillist + wiki sounds too oldskool? I like the surprising visibility that pipermail archives have on google searches, and OTOH i personally read write emails on several (mobile) devices, while AJAX webguis restrict my collaboration to the few times i'm sitting in front of a computer. maybe do something 'inside' the interop project, so that there's space to share config snippets and talk about use cases, which serves two purposes: 1) we can help each other solve herenow the challenges we are facing building the networks, until the interop team develops a common solution.. 2) the experiences can feed the development process of the common solution. The actual interop wiki sounds compatible and welcoming: 'This site is as a common wiki, playground, drawing board, ideas thrasher and everything else for different aspects of open networks interoperability and cooperation.' To keep things tidy, should we nest everything under http://interop.wlan-si.net/wiki/WikiSquatters/ ? ;) What do you interop-people think? If it sounds too OT, do you have any pointer to give? Guido
Re: [B.A.T.M.A.N.] Traffic Control in batman-adv
Hi gabriel, maybe rate limiting is not what you're looking for, but instead TOS marks on packets, which allow you to reorder packets in the queue, so as to give priority to some protocols, without limiting overall rate (or maybe i got it all wrong about what TOS is intented for :) ) on the other hand, you might check out a feature of gargoyle firmware as inspiration. it's based on openwrt backfire, and implements an 'active congestion check' mechanism, that measures ping times along the link, to estimate the actual troughput and adjust the qdisc max rate accordingly, so that QoS rules continue working properly. Cheers! Guido On 4/27/12, gto...@inti.gob.ar gto...@inti.gob.ar wrote: 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.] Problem with multi-radio, multi-channel in batman-adv
Hi!
I guess you're planning a two.radio mesh to improve troughput.
I recently went trough a similar experience and learnt thanks to this list,
turns out, this might sound counterintuitive at first, but in some
setups, using just 2 channels, spaced further apart, will avoid
interference better than 3 ('almost') overlapping channels.
I.e. Using channel 1 and 11 works better than 1 and 6.
I'm assuming you're not using 5.8g , etc
I suggest you to check a thread on this list last month archives,
'bandwidth degradation on p2p links', there are some interesting
references to read on the subject.
On 4/16/12, puyou.lu puyou...@gmail.com wrote:
Hi guys.
I’m trying to make a for nodes WMN using four devices with two wireless
cards each. I would like to use three different channels to reduce the
interference, like this:
[Node A] - channel 1 - [Node B] - channel 2 - [Node C] - channel
3 - [Node D]
First I configure eight wireless cards to the specific channel in ad-hoc
mode using “iw dev wlan0 ibss join …”.
Then, I think I should add wlan0 and wlan1 to the same batman-adv
interface (that is bat0) in every device. So I need to configure four nodes
with the same commands like:
echo bat0 /sys/class/net/wlan0/batman_adv/mesh_iface
echo bat0 /sys/class/net/wlan1/batman_adv/mesh_iface
Last configure an IP address to each bat0. (Node A-10.0.0.1, Node
B-10.0.0.2, Node C-10.0.0.3, Node D-10.0.0.4).
But it seem Node A can reach Node B and Node C(using ping), but can’t for
Node D.
Am I following the right procedure?
Sorry for my poor English. Any help would be appreciated.
Puyou Lu.
Re: [B.A.T.M.A.N.] any throughput mechanism or plans?
On Sat, Mar 31, 2012 at 11:39 PM, Guido Iribarren guidoiribar...@buenosaireslibre.org wrote: On Sat, Mar 31, 2012 at 11:02 PM, dan danden...@gmail.com wrote: Regarding your idea, how would you measure the maximum throughput? An easy way might be to just pull the info from ifconfig on a timer: eth0 RX bytes:2841699391 (2.6 GiB) TX bytes:2681928474 (2.4 GiB) + 5 seconds RX bytes:2842069649 (2.6 GiB) TX bytes:2682282969 (2.4 GiB) =RX of 361.5Kb, TX of 346.2Kb just update a value for the MAX of both as they change Compare the stored value to the last 5 second interval so see what amount of the connection is available. In my case, I have a 20Mb/10Mb connection so I have 19.3Mb/9.3Mb available. That sounds like a nice start! I'm not sure, though, if that number includes retransmissions and/or unacknowledged frames. Oh, i forgot to add, iw does discriminate between succesfully sent packets, and unsuccessfull retries or failed packets. For example # batctl o -n [B.A.T.M.A.N. adv 2012.0.0, MainIF/MAC: wlan0-1/56:e6:fc:be:29:d3 (bat0)] Originator last-seen (#/255) Nexthop [outgoingIF]: Potential nexthops ... 56:e6:fc:be:26:130.270s (145) 56:e6:fc:b9:b6:48 [ wlan1]: 56:e6:fc:b9:b6:47 (134) 56:e6:fc:b9:b6:48 (145) ### Let's find out how good looks that Nexthop 56:e6:fc:b9:b6:48 on wlan1 # iw wlan1 station get 56:e6:fc:b9:b6:48 Station 56:e6:fc:b9:b6:48 (on wlan1) inactive time: 20 ms rx bytes: 3593056580 rx packets: 2728661 tx bytes: 915427424 tx packets: 1677330 tx retries: 0 tx failed: 0 signal: -71 dBm signal avg: -70 dBm tx bitrate: 72.2 MBit/s MCS 7 short GI rx bitrate: 72.2 MBit/s MCS 7 short GI Those tx bytes do not include retries or failed transmissions, only ACKed packets (AFAIK) of course, making batman peek into this would definitely deviate from the bat-idea of i don't care if physical is wired, wifi, wimax or avian carriers my 2c
Re: [B.A.T.M.A.N.] BW degradation on p2p links?
Simon, you saved my day, On Thu, Mar 29, 2012 at 9:51 AM, Simon Wunderlich simon.wunderl...@s2003.tu-chemnitz.de wrote: the problem using one radio is explained further here (from another company, but this applies to any WiFi mesh technology) http://revolutionwifi.blogspot.com/2012/02/mesh-network-performance-impact.html I was fully aware of this problem with single-radio nodes, and that's why I was trying to build cheap two-radio nodes using mr3220 + usb dongles. Also, if you use two-radio nodes, they may interfere with each other if the antennas are near to each other. There are quite a few ppl who can confirm this, e.g. check this: https://hackerspace.be/Wbm2009v2/TestInterferenceResults Ah! you hit the nail right in the head! I walked around the battlemesh wiki a couple of weeks ago, interested into past events results, but only came across an rsync daemon serving a tree with videos, photos and results, mostly in raw data form, collected during the last (before athens) WBM edition. I think i was a bit short-sighted, since the Wbm2009v2 link (and the rest of that wbm wiki) was a wonderful read! I did a couple of tests, and indeed increasing the distance between the dongle and the router makes the whole difference. I googled more on the subject and found a paper with thorough testing results http://edoc.hu-berlin.de/oa/conferences/reSNAVwf8bA/PDF/28TjAjjEtU7ts.pdf and even finer-grained testing here http://userver.ftw.at/~valerio/files/wons.pdf None of them use 802.11n equipment, so i set out to make my own experiment. In my case, i needed about 1.5 meter between omni antennas to achieve full throughput, placing both omni antennas perpendicular to the ground and on the same plane. On the other hand, if i place them one over the other (that is, align their vertical axis, while holding them at different altitudes) a distance as little as 20cm was enough to overcome interference. (Sounds reasonable given the omnis gain spatial pattern) I was able to get 20mbps from A to C (and viceversa), hopping on B. [A ch=11] -- [ ch=11 B(2 radio) ch=1] -- [ch=1 C] This was done using either BATMAN or static routing, giving almost equal results (~1mbps less using batman) If i put the two radios in B really close to each other (5 cm) throughput fell down to 8 mbps. It's a relief it was such a simple issue! Thanks a lot Simon and Marek for getting me into the right path, So far we haven't heard of anyone implementing OpenWRT+batman-adv on mr3220+usb to build two-radio-nodes mesh network, which means we're mostly in a solo adventure so your help and attention was even more appreciated! Guido
Re: [B.A.T.M.A.N.] BW degradation on p2p links?
Hey thanks marek! I'm sorry i didn't think of trying that in the first place. Ath9k_htc has indeed a few issues so i wouldn't be suprised it's the culprit. I was aware of the battlemesh v5 and last week i even piperlurked the mail archives, but didn't realize it would happen this week. Best luck in athens then! I will continue my little mesh-battle here. Will try static routes tomorrow and report anything interesting. Cheers, guido On 3/26/12, Marek Lindner lindner_ma...@yahoo.de wrote: Hi, i'm participating in the development of a wireless mesh network in Delta de Tigre, near Buenos Aires, Argentina. Landscape is absolutely flat, with dense forest 15-20mts tall. Nodes are being installed along the river, 50 - 150mts apart, with clear LOS at ground level. I collaborated with Nico Echaniz last month, bulding another community network in Cordoba, and given the success, I decided to start one more here. I'm also really thankful with Elektra, for recommending the tl-m3220 to Nico! We chose batman over olsr, in part because of avahi stuff, but also to have a real-world implementation and thus collaborate in testing / debugging :) So far, there are only 4 working nodes, but luckily I'm already facing unexpected behaviour. I'm sorry for the long email, it's mostly terminal logs. In short, iperf between two neighbouring nodes reports 20mbps, yet running the same iperf between nodes separated by one hop reports inexplicably low 5mbps. [..] Any ideas, thoughts, pointers? Any additional info needed? welcome on the list! I admit not having dived into all the details of your mail - the bigger part of the batman team is sitting in Athens at the moment (see battlemesh.org). The best next step is to find out whether this performance issue is a batman- adv or a wifi driver problem. May I suggest you remove batman-adv and repeat the same test using static routing ? If you still see the problem it is the wifi that is not working otherwise we have to fix batman-adv. Regards, Marek
[B.A.T.M.A.N.] BW degradation on p2p links?
Hi, i'm participating in the development of a wireless mesh network in Delta de Tigre, near Buenos Aires, Argentina. Landscape is absolutely flat, with dense forest 15-20mts tall. Nodes are being installed along the river, 50 - 150mts apart, with clear LOS at ground level. I collaborated with Nico Echaniz last month, bulding another community network in Cordoba, and given the success, I decided to start one more here. I'm also really thankful with Elektra, for recommending the tl-m3220 to Nico! We chose batman over olsr, in part because of avahi stuff, but also to have a real-world implementation and thus collaborate in testing / debugging :) So far, there are only 4 working nodes, but luckily I'm already facing unexpected behaviour. I'm sorry for the long email, it's mostly terminal logs. In short, iperf between two neighbouring nodes reports 20mbps, yet running the same iperf between nodes separated by one hop reports inexplicably low 5mbps. Links are point to point, with different radios on different channels, no freq overlap. A=[ath9k]--(50m)--[ath9k]=B=[ath9k_htc]--(150m)--[ath9k_htc]=C=[ath9k]--(50m)--[ath9k]=D A is a tplink mr3420 + wn722n B and C are tplink mr3220 + wn722n D is a tplink mr3220 (single interface) All of them are running openwrt trunk r30919. the internal iface of the mr3x20 uses ath9k, and the wn722n runs with ath9k_htc the link between B and C is done in infrastructure mode, B is ap and C is managed. Radios are set to channel 9, HT40-. C - D is made with ath9k , in channel 1 , HT20. (all hostnames have been obscured for readability :P ) nodeB - nodeC = 31mbps nodeC - nodeD = 21mbps nodeB - nodeD = 3mbps nodeD - nodeC = 21mbps nodeC - nodeB = 21mbps nodeD - nodeB = 10mbps nodeD# batctl tr B_mesh traceroute to B_mesh (56:e6:fc:be:29:d3), 50 hops max, 20 byte packets 1: C_mesh (56:e6:fc:b9:b6:47) 1.155 ms 0.834 ms 0.796 ms 2: B_mesh (56:e6:fc:be:29:d3) 6.523 ms 2.719 ms 1.917 ms nodeB# batctl tr D_mesh traceroute to D_mesh (56:e6:fc:b9:b7:01), 50 hops max, 20 byte packets 1: C_mesh (56:e6:fc:b9:b6:47) 1.323 ms 1.117 ms 0.974 ms 2: D_mesh (56:e6:fc:b9:b7:01) 2.278 ms 1.839 ms 2.164 ms ### iperf between nodeB - nodeC root@nodeB:~# iperf -c nodeC -w 320k -i 1 Client connecting to nodeC, TCP port 5001 TCP window size: 320 KByte [ 3] local 10.6.0.1 port 35759 connected with 10.6.0.32 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0- 1.0 sec 3.63 MBytes 30.4 Mbits/sec [ 3] 1.0- 2.0 sec 3.63 MBytes 30.4 Mbits/sec [ 3] 2.0- 3.0 sec 4.00 MBytes 33.6 Mbits/sec [ 3] 3.0- 4.0 sec 3.63 MBytes 30.4 Mbits/sec [ 3] 4.0- 5.0 sec 3.88 MBytes 32.5 Mbits/sec [ 3] 5.0- 6.0 sec 3.88 MBytes 32.5 Mbits/sec [ 3] 6.0- 7.0 sec 4.00 MBytes 33.6 Mbits/sec [ 3] 7.0- 8.0 sec 3.75 MBytes 31.5 Mbits/sec [ 3] 8.0- 9.0 sec 3.75 MBytes 31.5 Mbits/sec [ 3] 9.0-10.0 sec 3.75 MBytes 31.5 Mbits/sec [ 3] 0.0-10.1 sec 38.0 MBytes 31.7 Mbits/sec ### iperf between nodeC - nodeD nodeC# iperf -c nodeD -w 320k -i 1 Client connecting to nodeD, TCP port 5001 TCP window size: 320 KByte [ 3] local 10.6.0.32 port 43655 connected with 10.6.0.16 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0- 1.0 sec 2.50 MBytes 21.0 Mbits/sec [ 3] 1.0- 2.0 sec 2.63 MBytes 22.0 Mbits/sec [ 3] 2.0- 3.0 sec 2.50 MBytes 21.0 Mbits/sec [ 3] 3.0- 4.0 sec 2.88 MBytes 24.1 Mbits/sec [ 3] 4.0- 5.0 sec 2.63 MBytes 22.0 Mbits/sec [ 3] 5.0- 6.0 sec 2.63 MBytes 22.0 Mbits/sec [ 3] 6.0- 7.0 sec 2.50 MBytes 21.0 Mbits/sec [ 3] 7.0- 8.0 sec 2.25 MBytes 18.9 Mbits/sec [ 3] 8.0- 9.0 sec 2.63 MBytes 22.0 Mbits/sec [ 3] 9.0-10.0 sec 2.63 MBytes 22.0 Mbits/sec [ 3] 0.0-10.1 sec 25.9 MBytes 21.5 Mbits/sec ### Now, enter the mistery.. ### Best iperf run after several attemps yielding 1 - 2 mbps # iperf -c charly-muelle -w 320k -i 1 -t 20 Client connecting to charly-muelle, TCP port 5001 TCP window size: 320 KByte [ 3] local 10.6.0.1 port 55093 connected with 10.6.0.16 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0- 1.0 sec 896 KBytes 7.34 Mbits/sec [ 3] 1.0- 2.0 sec 256 KBytes 2.10 Mbits/sec [ 3] 2.0- 3.0 sec 128 KBytes 1.05 Mbits/sec [ 3] 3.0- 4.0 sec 128 KBytes 1.05 Mbits/sec [ 3] 4.0- 5.0 sec 256 KBytes 2.10 Mbits/sec [ 3] 5.0- 6.0 sec 384 KBytes 3.15 Mbits/sec [ 3] 6.0- 7.0 sec 128 KBytes 1.05 Mbits/sec [ 3] 7.0- 8.0 sec 384 KBytes 3.15 Mbits/sec [ 3] 8.0- 9.0 sec 256 KBytes 2.10 Mbits/sec [ 3] 9.0-10.0 sec 512 KBytes 4.19 Mbits/sec [ 3] 10.0-11.0 sec 512 KBytes 4.19 Mbits/sec [ 3]
