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
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
