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

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

13 participants
22 discussions

by tetzlav

Today I tried batmand 0.3-beta rv791 (on ASUS-WL-500gPremium) and noticed that batmand set definitly wrong ip rules or has problems with alias-Interfaces and/or olsrd: > root@17-3:~# ip addr show eth2 > 4: eth2: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc prio qlen 1000 > link/ether 00:90:4b:7d:20:7a brd ff:ff:ff:ff:ff:ff > inet 104.61.17.3/8 brd 104.255.255.255 scope global eth2 > inet 10.61.17.3/24 brd 10.61.17.255 scope global eth2 > root@17-3:~# ip rule > 0: from all lookup local > 6597: from all lookup main > 6598: from all to 104.0.0.0/8 lookup olsr > 6599: from 104.0.0.0/8 lookup olsr > 32766: from all lookup main > 32767: from all lookup default > root@17-3:~# ip addr add dev eth2 105.61.17.3/8 broadcast + label eth2:bat > root@17-3:~# ip addr show eth2 > 4: eth2: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc prio qlen 1000 > link/ether 00:90:4b:7d:20:7a brd ff:ff:ff:ff:ff:ff > inet 104.61.17.3/8 brd 104.255.255.255 scope global eth2 > inet 10.61.17.3/24 brd 10.61.17.255 scope global eth2 > inet 105.61.17.3/8 brd 105.255.255.255 scope global eth2:bat > root@17-3:~# batmand -r2 eth2:bat > Using interface eth2:bat with address 105.61.17.3 and broadcast > address 105.255.255.255 > root@17-3:~# ip rule > 0: from all lookup local > 6597: from all lookup main > 6598: from all to 104.0.0.0/8 lookup olsr > 6599: from 104.0.0.0/8 lookup olsr > 6600: from all to 105.0.0.0/8 lookup 66 > 6699: from all lookup 65 > 6700: from all to 105.0.0.0/8 lookup 67 > 6800: from all iif lo lookup 68 > 6801: from 127.0.0.0/8 lookup 68 > 6802: from 104.0.0.0/8 lookup 68 > 6803: from 104.0.0.0/8 lookup 68 > 6804: from 192.168.1.0/24 lookup 68 > 32766: from all lookup main > 32767: from all lookup default batmand delete olsr-rules and set "from 104.0.0.0/8 lookup 68"!? Regards tetzlav

15 years, 4 months

AW: [B.A.T.M.A.N.] 0.3-beta-rv779 and rv780

by Marek Lindner

> The non-usual setup: you have different parts of your mesh operating in > different subnets you need an additional ip rule to make the nodes in the > non-homed subnet reachable from a node which has no interface in that subnet. > So for example, if your setup looks like: > A---------------------B1_B2---------------C > 10.0.0.1/24 10.0.0.2/24 10.0.1.2/24 10.0.1.3/24 > > the easiest way to do achieve that at A and C is: > $ ip rule add from all pref 6500 t 66 Wouldn't be HNA the much better solution ? Node B should announce one of the networks. To not rebroadcast OGMs from the wrong network batman should check if the received originator IP is within the own network. Regards, Marek Jetzt Mails schnell in einem Vorschaufenster überfliegen. Dies und viel mehr bietet das neue Yahoo! Mail - www.yahoo.de/mail

15 years, 4 months

[B.A.T.M.A.N.] 0.3-beta-rv779 and rv780

by Predrag Balorda

My test setup comprises 3 dual-radio (a and bg) units running openwrt kamikaze 7.09. For some reason (or another?) my middle unit keeps re-creating the gate0 every few seconds. Sometimes it loses it completely and sometimes it keeps it for 10 seconds or so. The furthest node from the gw keeps it's tunnel permanently configured (which is nice). Basically, node-to-node traffic is ok, very stable and very nice but node-through-gw is flaky. This above is with bg-only radios. Also I have tried using a dual-radio setup. I have tried to set bg-radios to one subnet and a-radios to a different one, I have also Tried setting them all on the same subnet but all hell breaks loose. I don't know if it's loops or what but it doesn't seem usable to me. Yes I know I'm playing with 0.3beta and exp but I believe this would be a far more usable setup than olsr 5.3 that I also tried. Any help appreciated in solving this issue. Pele

15 years, 4 months

[B.A.T.M.A.N.] routing tables

by tetzlav

> root@13-18:~# batmand -v > B.A.T.M.A.N. 0.3-beta rv780 (compatibility version 4) > root@13-18:~# ip r s t 65 > throw 105.61.89.81 proto static > 105.61.89.86 dev vlan1 proto static scope link 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 > 105.61.89.92 dev vlan1 proto static scope link src 105.61.89.81 > root@13-18:~# ip r s t 66 > 105.61.17.1 via 105.61.89.92 dev vlan1 proto static src 105.61.89.81 > 105.61.17.17 via 105.61.89.92 dev vlan1 proto static src 105.61.89.81 > 105.61.17.32 via 105.61.89.86 dev vlan1 proto static src 105.61.89.81 > throw 105.61.89.81 proto static > 105.61.17.2 via 105.61.89.89 dev vlan1 proto static src 105.61.89.81 > 105.61.17.18 via 105.61.89.89 dev vlan1 proto static src 105.61.89.81 > 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.86 dev vlan1 proto static scope link 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 > 105.61.89.92 dev vlan1 proto static scope link src 105.61.89.81 The 105.61.89.x-IPs are secandary BATMAN-interfaces (cable-connections). Why are routes to this IPs in the table 65 (for announced networks)? Bug or Feature? I think this is new in rv780... Regards tetzlav

15 years, 4 months

AW: [B.A.T.M.A.N.] 0.3-beta-rv779 and rv780

by Marek Lindner

Hi, > For some reason (or another?) my middle unit keeps re-creating the gate0 > every few seconds. Sometimes it loses it completely and sometimes it keeps > it for 10 seconds or so. The furthest node from the gw keeps it's tunnel > permanently configured (which is nice). to get to the bottom of your problem I need debug level 3 output. If you start the daemon with "-d 3" or connect to the running daemon with "batmand -c -d 3" and send me that output I will be able to figure it out. > Basically, node-to-node traffic is ok, very stable and very nice but > node-through-gw is flaky. On all nodes or just from that one ? Greetings, Marek Heute schon einen Blick in die Zukunft von E-Mails wagen? www.yahoo.de/mail

15 years, 4 months

AW: [B.A.T.M.A.N.] Experiences with B.A.T.M.A.N. 0.3-beta rv767

by Marek Lindner

Hi, > 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! exciting to hear. Keep us informed about all the trouble you experience so that we can work on it. > but the gateway-function (option "-r 2") drives me mad: > > * why the tunnel-interface (gateX) now have IP-Adresses!? Simply said the "get virtual IP on demand" mode had some problems especially with the fact that the interface has no IP address when the first packets arrive. So we went through a whole process of fixing that following problems by setting the new address in these packets, then recalculating the checksums, implementing a lightweight NAT for returning packets. After all that there were still issues which could not be addressed easily. On the other hand we give away the chance to check whether the tunnel port is blocked or not until the user needs the connection. Now batman hands out IP addresses proactively. We are waiting for real world feedback to see if we run into new problems. So far it seems to work. > * 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) The batman gateway checks if the tunnelled packet has a known wifi IP address corresponding to a known virtual IP address. 104.61.13.37 is obviously a wrong IP address. I would guess that this is an OLSR address ? May be we have a problem with gatewaying alias interfaces ? @Axel: Did you experience that kind of problem ? May be we have to set the source address explicitely. I look into that. > * I noticed, that LAN-clients (on batmannodes) sometimes get 169.x.y.z > Addresses per DHCP if i start batmand with "-r 2"-option? If so that has nothing to do with batman. Even if batman has an internal mini "give IP" server it is an own lightweight protocol which is not compatible with the real DHCP. Actually this IP range is to be used if you can't connect to a DHCP server and have no fixed address set. > 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. I understand. Regards, Marek Heute schon einen Blick in die Zukunft von E-Mails wagen? www.yahoo.de/mail

15 years, 4 months

AW: AW: [B.A.T.M.A.N.] Experiences with B.A.T.M.A.N. 0.3-beta rv767

by Marek Lindner

> May be we have to set the source address explicitely. I look into that. I issued a patch. Could you test that for me (rev 779) ? At the moment I can't do it myself. Regards, Marek Machen Sie Yahoo! zu Ihrer Startseite. Los geht's: http://de.yahoo.com/set

15 years, 4 months

AW: [B.A.T.M.A.N.] ideas for 0.3

by Marek Lindner

> How about forwarding the average TQ-Value of the best ranking neighbor instead > of the actual incoming value? This should avoid inconsistency amongst > TQ-Values to a great degree! That is what we do now ! It is the reason for the "10 seconds loops". Therefore I proposed to forward the incoming value instead of the average. I think you mixed it up. ;-) Regards, Marek Machen Sie Yahoo! zu Ihrer Startseite. Los geht's: http://de.yahoo.com/set

15 years, 4 months

AW: [B.A.T.M.A.N.] batmand-exp test in the developing world

by Marek Lindner

>> We'll post a message to the list as soon as we think it is fixed and >> worth a try. > i never saw that post (maybe i missed it?), so i only tested exp-0.3 :) Right - i think it is ready to be tested now. @Elektra: What about activating my latest routing improvement ? Heute schon einen Blick in die Zukunft von E-Mails wagen? www.yahoo.de/mail

15 years, 4 months

AW: [B.A.T.M.A.N.] batmand-exp test in the developing world

by Marek Lindner

> We experienced ~ 200% increase in cpu efficiency and ~ 300% in > network efficiency between 0.4.10 and 0.5.4. > c.f. http://olsr.funkfeuer.at for graphs. Wow - you are part of the marketing team ? I guess B.A.T.M.A.N. has over 1000% increase in efficiency between 0.01 and now. ;-) >> 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 Well, rev720 is almost 3 weeks old. During that time the new routing algo was quite unstable. Did you also try the newer snapshots ? > 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. Thank you very much for your testing efforts and all the feedback. That is wait excites us most. :-) Keep up the routing, Marek __________________________________ Ihr erstes Baby? Holen Sie sich Tipps von anderen Eltern. www.yahoo.de/clever

15 years, 4 months

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