B.A.T.M.A.N November 2007

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

13 participants
22 discussions

[B.A.T.M.A.N.] Experiences with B.A.T.M.A.N. 0.3-beta rv767
by tetzlav 04 Nov '07

04 Nov '07

We playing around with B.A.T.M.A.N. 0.3-beta rv767 in our leipziger Freifunk-testing-Firmware (based on v1.6.10): the Routing works fine (if i start "batmand eth1:bat vlan1:bat") - great work! but the gateway-function (option "-r 2") drives me mad: * why the tunnel-interface (gateX) now have IP-Adresses!? * what this log-message (on gateway) wants to tell me? (105.61.89.81 is an Node who wants to build up an gateway-tunnel) > Nov 3 16:49:38 (none) kern.err batmand[1819]: Error - got packet from > unknown client: 105.61.89.81 (virtual ip 104.61.13.37) > Nov 3 16:49:40 (none) kern.err batmand[1819]: Error - got packet from > unknown client: 105.61.89.81 (virtual ip 104.61.13.37) > Nov 3 16:49:41 (none) kern.err batmand[1819]: Error - got packet from > unknown client: 105.61.89.81 (virtual ip 104.61.13.13) > Nov 3 16:49:42 (none) kern.err batmand[1819]: Error - got packet from > unknown client: 105.61.89.81 (virtual ip 104.61.13.13) > Nov 3 16:49:43 (none) kern.err batmand[1819]: Error - got packet from > unknown client: 105.61.89.81 (virtual ip 104.61.17.28) > Nov 3 16:49:43 (none) kern.err batmand[1819]: Error - got packet from > unknown client: 105.61.89.81 (virtual ip 104.61.13.37) (there is no rule to throw 104/8 to batman tables) > root@13-18:~# ip rule show > 0: from all lookup local > 6600: from all to 105.0.0.0/8 lookup 66 > 6601: from all to 105.61.89.80/28 lookup 66 > 6699: from all lookup 65 > 6700: from all to 105.0.0.0/8 lookup 67 > 6701: from all to 105.61.89.80/28 lookup 67 > 32766: from all lookup main > 32767: from all lookup default > root@13-18:~# ip r s t 65 > throw 105.61.89.81 proto static > 105.61.89.89 dev vlan1 proto static scope link src 105.61.89.81 > 105.61.89.90 dev vlan1 proto static scope link src 105.61.89.81 > 105.61.88.193 via 105.61.89.90 dev vlan1 proto static src 105.61.89.81 > root@13-18:~# ip r s t 66 > 105.61.17.32 via 105.61.89.90 dev vlan1 proto static src 105.61.89.81 > throw 105.61.89.81 proto static > 105.61.17.35 via 105.61.89.89 dev vlan1 proto static src 105.61.89.81 > 105.61.17.21 via 105.61.89.90 dev vlan1 proto static src 105.61.89.81 > 105.61.89.89 dev vlan1 proto static scope link src 105.61.89.81 > 105.61.89.90 dev vlan1 proto static scope link src 105.61.89.81 > root@13-18:~# ip r s t 67 > throw 105.61.89.81 proto static > unreachable default proto static > root@13-18:~# batmand -bcd 2 > WARNING: You are using the unstable batman branch. If you are > interested in *using* batman get the latest stable release ! > Gateway (#/255) Nexthop [outgoingIF], gw_class ... > [B.A.T.M.A.N. 0.3-beta rv767, MainIF/IP: eth1:bat/105.61.13.18, UT: 0d > 0h 4m] > 105.61.89.89 (255) 105.61.89.89 [ vlan1:bat], gw_class 65 - > 16MBit/4MBit, reliability: 0 > 105.61.17.35 (255) 105.61.89.89 [ vlan1:bat], gw_class 65 - > 16MBit/4MBit, reliability: 0 * I noticed, that LAN-clients (on batmannodes) sometimes get 169.x.y.z Addresses per DHCP if i start batmand with "-r 2"-option? B.A.T.M.A.N. 0.2 worked fine, but we want/must use B.A.T.M.A.N. 0.3, because the available policy-routing cause no problems with parallel driven olsrd. Regards tetzlav

1 0

[B.A.T.M.A.N.] batmand-exp test in the developing world
by Jan Hetges 04 Nov '07

04 Nov '07

Hola todos after On Mon, Oct 15, 2007 at 04:14:36PM +0200, elektra wrote: > I'm sorry to say that 0.3beta is not usable at the moment. and my tests with 0.3-beta_~rv720 showed path-detection pretty broken, i tried exp-0.3. Finally i installed rv772 on 14 nodes real-world, rural nicaragua "non-profit-WISP/community network" parallel to existing olsrd(0.4.10/0.5.2/0.5.4pre)/ batmand_0.2-rv502. the solar powered nodes run bmxd-rv772 for almost 36hrs now, with no significant instabilities(with lots of tunneled download-traffic, the tunnel get's a bit unstable, what Axel already fixed in rv774). CPU-usage on client nodes looks less than in batmand_0.2, and slightly more than olsrd (would be interesting to see that scaling in a cloud with >100 nodes (how's the "massive parallel vm simulation" going btw?)), but is significantly higher (about factor 2) on gateway node. Best path-detection and usability/stability of routes so far. All nodes seem visible everywhere anytime, which is the case in olsrd as well, but not in batmand_0.2. I'm located two hops from the GW where my server also is. So i'm streaming music from there to check the stability of the route: with only olsrd it gets silent (with 1024KB disk cache in mplayer, ~40sec) pretty regularly (because of "collapsing routing tables" somewhere), with only batmand_0.2 it's even worse (because the GW node "doesn't hear my OGMs" too well). Both together are pretty usable. So i tried with only bmxd and disk cache set to 32KB (>1.5sec) and in tree hours music stopped once for <2sec ! from the "user-feeling" it's the way best mesh-daemon i tried so far. for fairness i have to say that my olsrds are neither all up to date, nor pretty well configured, but i beleave olsrd is a "historically crippled design" and the evolution of batmand will show the possibilities of wireless mesh networking. this all needs some further testing and improvements, but i'm pretty sure all the good bits will find their way into 0.3-final. Thanks to Elektra, Marek, Axel and everyone else who put so much energy into this amazing peace of free software. BatMan-eXperimental 0.3-alpha rv772 (compatibility version 5) /' '\ / \__^..^__/ \ / / _ \vv/ _ \ \ / \/ \ / \ May the bat guide your path ... cheers --Jan

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

B.A.T.M.A.N November 2007