B.A.T.M.A.N

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

4 participants
4260 discussions

[B.A.T.M.A.N.] 0.3-beta vs. 0.3-exp
by Jan Hetges 15 Oct '07

15 Oct '07

Hello everyone first: nice work, i'm impressed! i'm migrating 15 node olsr network to batman. right now all nodes run olsrd and batman-0.2 parallel, but there are some issues with "hidden nodes" (thanks to Axel for the bmx-reference-manual) so my question, which of the switches from bmx (if any) are available in the 0.3-beta versions, or is the beta just something like 0.3-exp --bmx-defaults ? cheers --Jan

2 1

Re: [B.A.T.M.A.N.] Texas UML instances and OLSR+BATMAN tests
by Aaron Kaplan 09 Oct '07

09 Oct '07

On Oct 9, 2007, at 6:58 PM, Herbert Poetzl wrote: > On Tue, Oct 09, 2007 at 06:40:11PM +0200, Aaron Kaplan wrote: >> >> yep, I think so too! Definitely worth a try. > >> @Bertl: would you help us to get vserver running >> as the basis for olsr (mesh routing demon) tests? > > sure, but please get me some idea what you want to do > first :) ok, so we have the following issue (sorry): we want to test B.a.t.m.a.n (https://www.open-mesh.net/) and olsrd (http:// olsr.funkfeuer.at, http://wiki.funkfeuer.at//index.php/Olsrd-ng) on our test server. That test server has 8GB or RAM and is currently in repair. The idea is that in order to create a massive test with many instances of olsrd or b.a.t.m.a.n. we need lots of virtual hosts, they should all be connected via a virtual network. This network needs a possibility of (real) packetloss between each link. Furthermore each instance needs its own routing table. when? anytime, we can start on some devel server with a few instances. As soon as our 8GB RAM machine is repaired we should test it there. best, aaron.

1 0

[B.A.T.M.A.N.] Texas UML instances and OLSR+BATMAN tests
by Benjamin Henrion 09 Oct '07

09 Oct '07

Hi, I would like to test OLSR and BATMAN on UML instances, since I don't have the hardware to make real tests. Would it be possible to have a copy of the binaries running on the simulator of http://texas.funkfeuer.at/, in order to launch it on my computer? Best, -- Benjamin Henrion <bhenrion(a)ffii.org> FFII Brussels - +32-484-566109 - +32-2-4148403

6 19

[B.A.T.M.A.N.] switching from 0.2
by Stefano Scipioni 08 Oct '07

08 Oct '07

There is a sort of HOWTO to switch from 0.2 release (compilation, configuration, new features) to 0.3? I'm interested to make a package for kamikaze svn version to test batman in a 30 mesh network (now we use batman 0.2). Thanks

2 1

[B.A.T.M.A.N.] batmand terminates silently
by Freifunk Dresden 07 Oct '07

07 Oct '07

Hello Axel, few weeks agoe I had sometimes the problem that batmand (experimental) exits silently. Today I found maybe one reason for this. When you have batman running and insert the iptable rule iptables -I OUTPUT -o eth1 -j DROP batmand exits. This also happen for additional interfaces controlled by batmand. Maybe it helps you a little. Regards, Stephan

3 3

[B.A.T.M.A.N.] 0.3 beta released
by Marek Lindner 28 Sep '07

28 Sep '07

Hi, the 0.2 branch has proven to be quite stable and robust but with many rough edges. We used this fundament to work on annoyances and improvements all over the code to make the upcoming release a worthy successor. We are very proud to announce that B.A.T.M.A.N. has an official port assigned by the IANA now. It is 4305 and already in the code. You can see it for yourself: http://www.iana.org/assignments/port-numbers Pay attention to the fact that all ports used by B.A.T.M.A.N. are changing: 4305 for OGMs, 4306 for the tunneling and 4307 for the vis server. Adjust your firewall settings if required. Another big step forward is our new experimental routing code - we call it B.A.T.M.A.N. IV. It takes asymmetric routing into account. Currently we have several ideas competing for the final inclusion into the release. Feel free to join our testing team. If you use the stable branch you will find the TQ (Transmit Quality) algorithm enabled. Each node observes its neighbor nodes and measures the link quality and adds this information to all (re)broadcasted packets. The clients choose the route with the best tq value. Use debug level 1 to get the tq information. Also, we heavily worked to improve the overall performance of our buitin tunneling. Therefore we created mod_batgat - a linux kernel module which will do the job from within the kernel land. It still needs some love and to be backported to 2.4 but it certainly will be finished for the release. The whole gateway management received a lot attention. We have new gateway classes which support down- and upload rates. Just specify your speeds and B.A.T.M.A.N. will guess the appropriate gateway class. The routing classes have been reworked as well. The user can choose between fast, stable or fast-switching connection. The B.A.T.M.A.N. internet client can detect broken gateways (blackholes) to avoid them. All internet related options can be changed during runtime. Disabling the own gateway, change the preferred gateway or routing class is possible without restarting the daemon. We also improved the quality of our documentation and thanks to the hard work of Wesley we have a man page with a compete overview about all options accompanied by a usage example section. Our vis server was a bit hidden in the past but it steadily made progress and is now a stable powerful application. It can handle multiple interfaces, HNA and is small enough to run on embedded devices. We will provide precompiled packages for it from now on. Therefore we release its first beta version. In order to avoid confusion in the future the vis server will get the same version numer as the compatible batman release. That makes it 0.3 beta as well. The B.A.T.M.A.N. dev team

1 0

[B.A.T.M.A.N.] routing / direct connection
by Freifunk Dresden 25 Sep '07

25 Sep '07

Hello, Im using the batmand- experimental and have some problems with routing. First I like to know the meaning of all the fields of the debug level prints and how they are determined. It would be great If you can give a more detailed information when to use the extended options and what they do with batmand. For instance, why should I change the window size (seen in Graz experiment). My setup is the following. I have a laptop (linux debian) on a table. under the table I have a WRT54GS about 50cm below. A second router WRT54GL is places on the top of a cupboard which is about 1m higher than the laptop and about 3 m away. The laptop is offering a gatway. Table (wrt B 10.12.10.1) (laptop 10.12.0.1) ########### (wrt A 10.12.10.17) # cupbord ### laptop ------------ wrt A | | wrt B---------------+ My problem is that the connection from the laptop to B is bad (ssh,http connection). batman setups the routes so each device has a direct connection to the others. OLSR has detected this and does not use the direct connection between laptop and wrt B. It creates an routing entry to route over wrt A in laptop and wrt B. This results in a fast and better connection. laptop wrt A | | wrt B---------------+ My problem also causes that the wrt B looses the gatway (laptop) and removes the default routing entry. I have added some traces of the three devices. All devices stay directly connected to each other. After network start wrt B still shows the gatway of the laptop (over the bad connection). Later the gateway will vanish and come back only for a short time before vanishing again. LAPTOP: ----------- batmand -s 10.12.0.1 -g 1024/200 --no-unreachable-rule --no-throw-rules --no-prio-rules wlan0 bbs /t 1 /i bbc /t 1 /i" B.A.T.M.A.N. 0.3-exp, MainIF/IP: wlan0 10.12.0.1, WindSize: 128, BLT: 2, OGI: 1000, UT: 0d 0h 0m Originator viaIF Router (brc rcvd lseq lvld) [ viaIF l2q lq nlq].. alternatives... 10.12.10.1 wlan0 10.12.10.1 ( 46 47 217 0) [ wlan0 40 48 106] 10.12.10.17 ( 1) 10.12.10.17 wlan0 10.12.10.17 ( 47 48 239 0) [ wlan0 44 49 114] 10.12.10.1 ( 1) WRT A --------- batmand --no-unreachable-rule --no-throw-rules --no-prio-rules -r 1 eth1 B.A.T.M.A.N. 0.3-exp, MainIF/IP: eth1 10.12.10.17, WindSize: 128, BLT: 2, OGI: 1000, UT: 0d 0h 3m Originator viaIF Router (brc rcvd lseq lvld) [ viaIF l2q lq nlq].. alternatives... 10.12.0.1 eth1 10.12.0.1 ( 7 7 7 0) [ eth1 119 7 128] 10.12.10.1 ( 0) 10.12.10.1 eth1 10.12.10.1 (125 126 176 0) [ eth1 115 126 116] 10.12.0.1 ( 1) Gateway Router (#/128) => 10.12.0.1 10.12.0.1 (110), gw_class 33 - 1024KBit/256KBit, reliability: 1 WRT B --------- batmand --no-unreachable-rule --no-throw-rules --no-prio-rules -r 1 eth1 B.A.T.M.A.N. 0.3-exp, MainIF/IP: eth1 10.12.10.1, WindSize: 128, BLT: 2, OGI: 1000, UT: 0d 0h 3m Originator viaIF Router (brc rcvd lseq lvld) [ viaIF l2q lq nlq].. alternatives... 10.12.0.1 eth1 10.12.0.1 ( 23 23 23 0) [ eth1 119 22 128] 10.12.10.17 ( 0) 10.12.10.17 eth1 10.12.10.17 (113 124 213 1) [ eth1 120 113 128] 10.12.0.1 ( 11) Gateway Router (#/128) => 10.12.0.1 10.12.0.1 ( 82), gw_class 33 - 1024KBit/256KBit, reliability: 1 ################## after a while... LAPTOP: ------------ B.A.T.M.A.N. 0.3-exp, MainIF/IP: wlan0 10.12.0.1, WindSize: 128, BLT: 2, OGI: 1000, UT: 0d 0h55m Originator viaIF Router (brc rcvd lseq lvld) [ viaIF l2q lq nlq].. alternatives... 10.12.10.1 wlan0 10.12.10.1 (127 127 3503 0) [ wlan0 107 127 107] 10.12.10.17 ( 0) 10.12.10.17 wlan0 10.12.10.17 (128 128 3532 0) [ wlan0 124 128 124] 10.12.10.1 ( 0) WRT A --------- B.A.T.M.A.N. 0.3-exp, MainIF/IP: eth1 10.12.10.17, WindSize: 128, BLT: 2, OGI: 1000, UT: 0d 0h58m Originator viaIF Router (brc rcvd lseq lvld) [ viaIF l2q lq nlq].. alternatives... 10.12.0.1 eth1 10.12.0.1 (125 126 3301 0) [ eth1 123 125 125] 10.12.10.1 ( 1) 10.12.10.1 eth1 10.12.10.1 (126 128 3470 1) [ eth1 111 128 111] 10.12.0.1 ( 2) Gateway Router (#/128) => 10.12.0.1 10.12.0.1 (125), gw_class 33 - 1024KBit/256KBit, reliability: 1 WRT B --------- B.A.T.M.A.N. 0.3-exp, MainIF/IP: eth1 10.12.10.1, WindSize: 128, BLT: 2, OGI: 1000, UT: 0d 0h57m Originator viaIF Router (brc rcvd lseq lvld) [ viaIF l2q lq nlq].. alternatives... 10.12.0.1 eth1 10.12.0.1 (108 118 3264 0) [ eth1 123 108 128] 10.12.10.17 ( 10) 10.12.10.17 eth1 10.12.10.17 (114 121 3461 0) [ eth1 123 114 128] 10.12.0.1 ( 7) Gateway Router (#/128) 10.12.0.1 10.12.0.1 (109), gw_class 33 - 1024KBit/256KBit, reliability: 6 ################################################################################## still a little later LAPTOP: ---------- B.A.T.M.A.N. 0.3-exp, MainIF/IP: wlan0 10.12.0.1, WindSize: 128, BLT: 2, OGI: 1000, UT: 0d 1h11m Originator viaIF Router (brc rcvd lseq lvld) [ viaIF l2q lq nlq].. alternatives... 10.12.10.1 wlan0 10.12.10.1 (124 128 4411 0) [ wlan0 107 128 107] 10.12.10.17 ( 4) 10.12.10.17 wlan0 10.12.10.17 (127 127 4441 0) [ wlan0 121 128 121] 10.12.10.1 ( 0) WRT A --------- B.A.T.M.A.N. 0.3-exp, MainIF/IP: eth1 10.12.10.17, WindSize: 128, BLT: 2, OGI: 1000, UT: 0d 1h15m Originator viaIF Router (brc rcvd lseq lvld) [ viaIF l2q lq nlq].. alternatives... 10.12.0.1 eth1 10.12.0.1 (123 125 4308 0) [ eth1 121 123 125] 10.12.10.1 ( 2) 10.12.10.1 eth1 10.12.10.1 (126 128 4477 0) [ eth1 111 128 111] 10.12.0.1 ( 2) Gateway Router (#/128) => 10.12.0.1 10.12.0.1 (123), gw_class 33 - 1024KBit/256KBit, reliability: 1 WRT B --------- B.A.T.M.A.N. 0.3-exp, MainIF/IP: eth1 10.12.10.1, WindSize: 128, BLT: 2, OGI: 1000, UT: 0d 1h14m Originator viaIF Router (brc rcvd lseq lvld) [ viaIF l2q lq nlq].. alternatives... 10.12.0.1 eth1 10.12.0.1 (106 115 4277 0) [ eth1 123 106 128] 10.12.10.17 ( 9) 10.12.10.17 eth1 10.12.10.17 (117 122 4476 0) [ eth1 120 117 128] 10.12.0.1 ( 5) Gateway Router (#/128) 10.12.0.1 10.12.0.1 (110), gw_class 33 - 1024KBit/256KBit, reliability: 8

2 3

[B.A.T.M.A.N.] MAC and OLSR
by giuseppe de marco 25 Sep '07

25 Sep '07

I agree that OLSR and also BATMAN should be moved to link layer. Anyway, now I am trying to do some experiment with OLSR and BATMAN, but by using also the information of MAC layer. I am using linux and ieee80211. Does anybody know how to read the mac parameters, such as lost frames, number of retransmission and so on? Regards -- 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

3 4

[B.A.T.M.A.N.] a strange case
by a.anselmi＠oltrelinux.com 24 Sep '07

24 Sep '07

Hi all I'm experiencing a strange situation [AP_n]--wifi--[client]--mesh--[gateway]--wifi--[AP_g] | [xDSL]---[world] The two nodes (client and gateway) are running batman 0.3 (experimental rv636) in the right way with option --bmx-defaults. A wifi laptop associated with AP_g (gateway' AP) can browse internet pretty well while associated with AP_n (client' AP) it can't! Please note that client itself can browse internet! (I tryed ssh into node and then wget something). I verified no nameserver problem neither firewall blocking rules (gateway and node are flashed and run the same firmware) But what is puzzling me is that running batman 0.2 on nodes... laptop associated with AP_n (client' AP) can browse! (I've only changed the daemon, no others change into environment - procedures dinamically change batmand command string) . I noticed the parameter "--no-unreachable-rule" then tryed adding this parameter at the batman 0.3 command string but unfortunately with no results! Maybe I'm boring you... bat have any ideas about? -- Antonio

3 5

[B.A.T.M.A.N.] 0.3 alpha (today revison)
by a.anselmi＠oltrelinux.com 24 Sep '07

24 Sep '07

Hi, since you use mipsel device I think these mips log could be of more help in fixing mips/mipsel bug in 0.3 branches (alpha and experimental). Very simple scenario: [client 5.1.7.251]----mesh----[gateway 5.1.7.254] all node running 0.3 apha (the today latest rv6300.3-alpha) ##### d3 level debug at client ... 1) Adding throw route to 169.254.0.0/16 via 0.0.0.0 (table 68 - eth0:1) 2) Adding throw route to 127.0.0.0/8 via 0.0.0.0 (table 68 - lo) 3) Adding throw route to 10.7.251.128/25 via 0.0.0.0 (table 68 - ath2) 4) Adding throw route to 5.0.0.0/8 via 0.0.0.0 (table 68 - ath0) 5) Adding throw route to 10.7.251.0/25 via 0.0.0.0 (table 68 - br0) 6) Adding route to 5.1.7.254 via 0.0.0.0 (table 66 - ath0) 7) Found new gateway 5.1.7.254 -> class: 49 - 4MBit/1024KBit # after sliding windows if filled in by validate OGMs 8) Adding default route to 5.1.7.254 (gw_flags: 49, packet_count: 64, gw_product: 0) 9) Adding default route via tun0 (table 68) # ...ah this is great! now trying to ping outside mesh 10) Gateway client - got IP (1.0.254.169) from gateway: 5.1.7.254 11) Gateway client - gateway (5.1.7.254) says: IP (1.0.254.169) is expired # client can't exit off mesh ##### d3 level debug at gateway ... 1) gateway class: 49 -> propagating: 4MBit/1024KBit 2) Error - can't add route to 0.0.254.169/24 via 0.0.0.0 (table 254): Invalid argument # (don't know why previous error) # ...gateway is learned about client wants ping outside mesh 3) Gateway - assigned 1.0.254.169 to client 5.1.7.251 4) Error - got packet from unknown client: 5.1.7.251 (virtual ip 1.0.254.169) What I see: FIRST BUG (?) Client prepare route to 169.254.0.0/16 in table 68 (line 1-log_client) while gateway arrange a 169.254.0.0/24 space (line 2-log_gateway): suffix bits differs (16 bit netmask client side vs 24 bit netmask server side) SECOND BUG Client wants ping outside mesh and receives a *little endian formatted* IP 1.0.254.169 (line 10-log_client and line 3-log_gateway) which is out of previous arrangement (this IP address is malformed by gateway). Client tryes sending outgoing packet to gateway Gateway receives client' outgoing packect but doesn't recognize IP source address (line 4-log_gateway) expecting one in 0.0.254.169/24 space. Thus gateway informs client about wrong IP, so client pinging fails (line 11-log_client). Hopeing this will be usefull... I know today weekend begins :) -- Antonio

6 11

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

B.A.T.M.A.N