B.A.T.M.A.N December 2007

b.a.t.m.a.n@lists.open-mesh.org

14 participants
10 discussions

[B.A.T.M.A.N.] batmand_0.3~r875 debian packages available
by Holger Levsen 25 Jan '08

25 Jan '08

Hi, yesterday night I've uploaded 0.3 svn r875 packages to Debian experimental, they are also available at http://layer-acht.org/batmand/ for etch and sid. Feedback welcome! regards, Holger

5 9

[B.A.T.M.A.N.] policy routing improved
by Marek Lindner 30 Dec '07

30 Dec '07

Hi, after several talks with different batman users / freifunk communities it became clear that we need more flexibility for the policy routing. Therefore I implemented a new option which takes a path to a executable / shell script as argument (--policy-routing-script). If this option is given batmand will send all routing table changes to this executable instead of manipulating the routing table itself. The messages contain all neccessary information to manipulate the routing table correctly. The executable can modify the parameters before changing the routing table (routing tables, interfaces, priorities, etc) or just ignore messages. I wrote a sample shell script which you can use as basis for your hacking: http://downloads.open-mesh.net/batman/useful-scripts-and-tools/policy_routi… This makes the --no-policy-routing option obsolete which was removed. Feedback is welcome. ;-) Greetings, Marek

1 0

[B.A.T.M.A.N.] Some issues in ahdemo and intra-mesh traffic (slow)
by Predrag Balorda 17 Dec '07

17 Dec '07

I'm running 5 nodes in 11b ahdemo + vap configuration, everything unbridged and on separate subnets, even lan ports. It's really self-explanatory, but for the uninitiated - being poor and not having money for a "proper" mesh router with two or more wireless cards I'm running batman on ahdemo interface for mesh routing and each router also has a vap for client access (atheros hardware here, Broadcom routers 105.0.4.4 and 105.0.4.5 attach to the mesh via another vap). I have chosen 11b over 11g for slightly better range and better stability. I'm experiencing strange behavior. Throughput between notes is roughly 2mbits (around 300KB/sec scp transfers). I have included my digraph in PS so that you can better visualize my network. After a minute, for example node 5 would stop responding to pings from node 3, or node 1 from 4 etc, so basically two-hop nodes, direct neighbours always seem ok. But the funny thing is that hosts on the internet, i.e. traffic that goes to the tunnel always respond to pings. I have tried experimenting with one-way tunnel mode but I have been unsuccessfull. Tried "--one-way-tunnel 1 --two-way-tunnel 0" on both gw and client batman nodes but nothing happens, batmand -c -d 2 always shows 2WT capability for the gateway. I have tried --dups-ttl 2 --re-brc-delay 15 --window-size 100 (reading from bmx tutorial pdf) and it has helped somewhat, but not completely. The problem is still there but to a lesser extent. I don't know whether this is down to ahdemo (maybe Antonio can help here with his experience) or down to batman. Any ideas? Also, is my throughput ok compared to yours? The most I ever got was around 450KB/s (roughly 5.5mbits data rate, distance 100m outside with 9dbi omni antennas and atheros 5112 - buffalo whr-hp-ag108 at both ends) but the 11Mbits evades me - even on a -55 signal and 40 rssi! It really is heart breaking, especially seeing such a good signal. Two nodes roughly 300m apart get 240KB/s at most. I know better is possible because in ap mode with that signal I used to get 1MB/s transfers (that was before I started using batman and ahdemo). Best regards, Pele P.S. digraph topology { "105.0.4.4" -> "105.0.4.5"[label="1.15"] "105.0.4.4" -> "105.0.3.3"[label="1.05"] "105.0.4.4" -> "10.0.4.0/255.255.255.0"[label="HNA"] "105.0.4.4" -> "10.1.4.0/255.255.255.0"[label="HNA"] "105.0.4.4" -> "105.0.2.4/255.255.255.255"[label="HNA"] "105.0.3.3" -> "105.0.0.1"[label="1.16"] "105.0.3.3" -> "105.0.4.4"[label="1.19"] "105.0.3.3" -> "105.0.3.2"[label="1.05"] "105.0.3.3" -> "105.0.4.5"[label="1.12"] "105.0.3.3" -> "10.0.3.0/255.255.255.0"[label="HNA"] "105.0.3.3" -> "10.1.3.0/255.255.255.0"[label="HNA"] "105.0.3.3" -> "105.0.0.3/255.255.255.255"[label="HNA"] "105.0.3.3" -> "105.0.2.3/255.255.255.255"[label="HNA"] "105.0.3.3" -> "105.0.1.3/255.255.255.255"[label="HNA"] "105.0.4.5" -> "105.0.4.4"[label="1.27"] "105.0.4.5" -> "105.0.3.3"[label="1.03"] "105.0.4.5" -> "10.0.5.0/255.255.255.0"[label="HNA"] "105.0.4.5" -> "105.0.2.5/255.255.255.255"[label="HNA"] "105.0.3.2" -> "105.0.0.1"[label="1.03"] "105.0.3.2" -> "105.0.3.3"[label="1.03"] "105.0.3.2" -> "10.0.2.0/255.255.255.0"[label="HNA"] "105.0.3.2" -> "10.1.2.0/255.255.255.0"[label="HNA"] "105.0.3.2" -> "105.0.0.2/255.255.255.255"[label="HNA"] "105.0.3.2" -> "105.0.2.2/255.255.255.255"[label="HNA"] "105.0.3.2" -> "105.0.1.2/255.255.255.255"[label="HNA"] "105.0.0.1" -> "105.0.3.3"[label="1.03"] "105.0.0.1" -> "105.0.3.2"[label="1.01"] "105.0.0.1" -> "10.0.1.0/255.255.255.0"[label="HNA"] "105.0.0.1" -> "10.1.1.0/255.255.255.0"[label="HNA"] "105.0.0.1" -> "105.0.2.1/255.255.255.255"[label="HNA"] "105.0.0.1" -> "105.0.1.1/255.255.255.255"[label="HNA"] "105.0.0.1" -> "0.0.0.0/0.0.0.0"[label="HNA"] }

3 2

[B.A.T.M.A.N.] (no subject)
by giuseppe de marco 11 Dec '07

11 Dec '07

Anybody know a good embedded harware to use for test batman? G -- Giuseppe De Marco, PhD Toyota Technological Institute 468-8511 Aichi 2-12-1 Hisakata, Tenpaku-ku, Nagoya, Japan Email: demarco at toyota-ti dot ac dot jp Tel (int): +81 (052)-809-1802 Skype-Id: giuseppe_dem2

5 4

[B.A.T.M.A.N.] strange batman aborting
by Jan Hetges 10 Dec '07

10 Dec '07

Hi All after two weeks uptime bmxd_rv804 just died! and not only that one, but on a neighbouring node (~5 days uptime) as well. So i restarted them, and about 26hrs later, they are both dead again. So i enabled Lui's watchout4batman, maybe i see at least, which one dies first. Only unnormal in the log: user.warn kernel: nf_conntrack: table full, dropping packet. any ideas? cheers --Jan p.s. both boxes run kamikaze 7.07 i386

4 7

[B.A.T.M.A.N.] In-the-field Protocol Migration (was: exp-rv811 and exp-864 non-interoperable?)
by Axel Neumann 10 Dec '07

10 Dec '07

Hi, On Montag 10 Dezember 2007, Predrag Balorda wrote: > Before I go round upgrading my routers, are these two incompatible because > it seems so? Yes, everyting < 863 is incompatible with revisions >= 863 > If so then I'll need to figure out the exact order of > upgrading (i.e furthest first - I don't want to have to climb roofs or walk > too long) The following should be possible even without any upgrading order - allowing a completely seamless, in-the-field protocol migration. May sound a bit oversized but is probably the only way for large-chaotic mesh networks. In short this approach involves three steps: 1) Install the new batman version in parallel to the existing one (ensure independent operation of the two protocols, more details below...) 2) Test the new batman version 3) Disable the old batman version Now the long and detailed howto. Don't be afraid it turns out to be much easier than it first sounds. 0) You keep your current revision running as it is. 1) Install the new version in parallel to the existing one. Do NOT enable GW-client mode (-r of -p) before step 2. Configure the new version with independent: a) alias interfaces and IP ranges ( e.g. use eth0:bmx 103.x.y.z/8 in addition to eth0:bat 105.x.y.z/8 ) Ensure that the old batmand gets (re-)started after the new alias interfaces and ip ranges have been configured. Thus, either - you only restart the old batmand after the new interface configuration or - you put the bat and bmx alias-interface configuration in your startup scripts and reboot your device. The reason for this is that batman learns about the networks of a node during its startup process and takes care that packets towards these networks are not routed into the batman tunnel. Because we don't want the 103.0.0.0/8 traffic (related to the new batmand) to be routed via the bat0 tunnel of the old batmand, we have to make sure that the old batmand knows about it. b) binary name (e.g. rename the binary to /usr/sbin/bmxd) c) protocol port numbers ( e.g. use 14305 instead of 4305 ) d) ip preference rules (e.g. use 14xxx instead of 6xxx) e) ip routing tables (e.g. use table 144-148 instead of 64-68 ) f) gateway tunnel ip ranges (e.g. use bat1 169.254.128.0/22 instead of bat0 169.254.0.0/22 ) g) unix-socket identifier to access debug messages The good thing is, the --neta option cares for task c,d,e,f,g automatically, so the only tasks left are the binary names and the interface configuration (and of course the annoying firewall configuration) 2) Now - when the new version is installed everywhere - it can be tested. So fare GW-Client mode should not have been activated with the new version. Therefore, the first testing can only involve the routing inside the mesh, the cpu load of the new version,... One note, to access the debug output of the new batman version use --neta -cd1 , the verbose output has moved to debug-level 8 (--neta -cd8) To test internet connectivity I assume that the nodes which were operating in GW-mode with the old batmand are also operating in GW-mode with the new batman version. But so fare GW-Client mode has not been activated with the new version. The GW-Client mode (e.g. -r 3) configures your default route and there can be only ONE default route per node. So here each node/user has to make a choice. The good thing is, this choice can now be done independently at each node. Since revision 811 (this is before the compatibility change) you can use -c -r 0 to dynamically deactivate GW-client mode with the old batman and --neta -c -r 3 to dynamically activate GW-client mode with the new version. 3) Once every node and user is convinced that using the new batman version for routing and surfing the internet pays out (thus uses -r 0 with the old batman and -r 3 with the new version) the old version can be gradually deactivated. happy routing, axel > > Best regards, > > Pele > > P.S. also has anyone compared network throughput between beta and exp and > are there any benefits to beta over exp? > P.P.S I'm experimenting with PoE and guess which process is the first that > gets killed because of undervoltage?! :-) > > _______________________________________________ > B.A.T.M.A.N mailing list > B.A.T.M.A.N(a)open-mesh.net > https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n

1 0

[B.A.T.M.A.N.] two-way-tunnel quirks
by Jan Hetges 06 Dec '07

06 Dec '07

Hi all as i'm running bmxd-rv804 only ;-) for almost two weeks now, almost without problems... now i found an issue which i didn't relate with batman first. I got several reports of users, hotmail/msn/live.com not being accessible anymore... Yesterday i found out theres also problems with some pop server not beeing accessible, but everything works fine directly at the upstream gw, without any batmand involved. reenableing the old one-way-tunnel solved all the problems. cheers --Jan

4 13

[B.A.T.M.A.N.] open-mesh certificate
by Marek Lindner 03 Dec '07

03 Dec '07

> Batman-0.3 and batman-adv disappeared from the ftp server? > > A major re-naming effort underway perhaps? > > P.S. I've grabbed some sources just in case your ftp server is dying J Thanks for your hints. But it is to earlier to bring open-mesh under the earth. ;-) The SSL certificate has expired and as soon as this is fixed everything will go back to normal. Regards, Marek

1 0

[B.A.T.M.A.N.] batmand in debian
by Holger Levsen 03 Dec '07

03 Dec '07

Hi, batmand is now in Debian/unstable, see http://packages.qa.debian.org/batmand :-) Which means, we can now prepare 0.3 for Debian/experimental, or to unstable if you you think that's better. regards, Holger

2 4

[B.A.T.M.A.N.] rv791 <---> rv824 incompatible?
by tetzlav 01 Dec '07

01 Dec '07

> root@17-21:~# batmand > -v > > B.A.T.M.A.N. 0.3-beta rv791 (compatibility version 4) > root@17-21:~# batmand -cd4 > [ 33051930] Received BATMAN packet via NB: 105.61.17.32, IF: eth1:bat > 105.61.17.21 (from OG: 4.0.50.0, via old OG: 31.213.16.210, seqno > 4384, tq 17, TTL 61, V 61, UDF 0, IDF 1) > [ 33051930] Is an internet gateway (class 105) > [ 33051930] Drop packet: incompatible batman version (61) --- > root@17-32:~# batmand -v > WARNING: You are using the unstable batman branch. If you are > interested in *using* batman get the latest stable release > ! > B.A.T.M.A.N. 0.3-beta rv824 (compatibility version 4) > root@17.32:~# batmand -cd4 > [ 7946500] Received BATMAN packet via NB: 105.61.17.21, IF: eth1:bat > 105.61.17.32 (from OG: 0.254.113.181, via old OG: 0.4.117.105, seqno > 26941, tq 61, TTL 18, V 105, UDF 0, IDF > 0) > > [ 7946500] Is an internet gateway (class 1) > [ 7946510] Drop packet: incompatible batman version (105) Regards tetzlav

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

B.A.T.M.A.N December 2007