B.A.T.M.A.N

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

3 participants
4259 discussions

[B.A.T.M.A.N.] problems running batman rev350
by Dragan Noveski 21 May '07

21 May '07

hi list, i am new here and just trying to use batman rev350 compiled on 2.6.21.1-rt3 kernel on ibm-thinkpad-R50e. the rt-patch (for low-latency audio work) comes from: http://people.redhat.com/mingo/realtime-preempt/ i am using a atmel-wlan adapter and the atmel driver from: git-clone http://honk.sigxcpu.org/git/at76c503a.git/ the driver runs pretty stable, if i use olsrd to join the network here, i use following script to start the protocol: #!/bin/sh iwconfig eth2 mode ad-hoc essid olsr.freifunk.net channel 10 ap 02:CA:FF:EE ifconfig eth2 104.130.30.9 ifconfig eth2 up olsrd ......... except of some timeouts, which are pretty rarely, that runs good. i am starting batman with: #!/bin/bash iwconfig eth2 mode ad-hoc essid olsr.freifunk.net channel 10 ifconfig eth2 105.130.30.9 ifconfig eth2 up sleep 1 batmand -d 1 -p 105.131.41.5 -r 1 eth2 and #!/bin/bash batmand -c -d 2 in another terminal. when batman starts, the 'batmand -c' script shows, that i am connected to another gateway, but not to preferred one: Gateway Router (#/128) => 105.192.99.62 105.130.30.1 ( 3), gw_class 10 - 6 MBit, reliability: 0 105.192.99.61 105.130.30.1 ( 1), gw_class 7 - 2 MBit, reliability: 0 105.131.83.5 105.130.30.1 ( 1), gw_class 11 - >6 MBit, reliability: 0 105.131.41.5 105.130.30.1 ( 2), gw_class 11 - >6 MBit, reliability: 0 105.192.99.103 105.130.30.1 ( 3), gw_class 7 - 2 MBit, reliability: 0 105.192.99.192 105.130.30.1 ( 2), gw_class 10 - 6 MBit, reliability: 0 ........... this always is a number 105.192.99.....(.62, .103, .192). this condition than stays for 2 or 3 up to 10 minutes, and in that time i cannot even ping the 105.130.30.1 which is the next point here. after some minutes, the connection changes, so that 'batmand -c' shows that i am connected to 105.131.41.5 and i am able to ping 141.1.1.1. unfortunately, after some minutes (or even shorter), the batman script stops and the terminal is at the prompt again. there is no segfault, using 'ulimit -c unlimited' will not produce a core-dump. i suppose that this is not a driver bug, cause looking at this moment at 'dmesg', i can see that the driver is loaded using the 02:ca:ff:ee:ba:by - if i stop batmand and start olsrd, i will be connected to the internet as expected. i am really not aware of what else information i could provide to you, in order to make batmand running stable here, but if you have any idea, please let me know! cheers, doc

3 6

[B.A.T.M.A.N.] Re: Agree with Elektra
by CK ToH 20 May '07

20 May '07

BATMAN folks: Sorry I joined this list a bit late. I fully agree with ELEKTRA's email dated March 10, 2007 in his reply to Status of BATMAN in IETF. I attached ELEKTRA's comments again below: >>In my opinion the development cycle of many organizations >>is slow because they are too bureaucratic and too occupied with >>paperwork and their own hierarchical structure instead of developing >>useful things. I like the informal character of our development. Our >>research is a non-profit driven by fun and the will to empower people >>around the world to improve their communication on a grass root level. >>"On-line for all" is the agenda. >>Of course hoity-toity people with ties, suits and long academic titles >>tend to ignore a work of freaky people that don't bother about writing >>texts in the style of codes of law. That's alright with me. In their >>fancy-looking presentations about mesh-networks you see soldiers, tanks >>and robots building a mesh on the battlefield or bugging devices for >>their paranoid big-brother fantasies. I don't want to be supportive for >>that kind of development. We can't avoid it because of the open nature >>of open-source development. We are not doing things for our drawers or >>to keep it as a secret. >>Take the development of OLSR as an example. INRIA is still submitting >>new drafts about ideas that we have found not feasible in real life in >>the year 2004 when we did our first tests with 20 nodes on a conference >>(Wizard of OS III) in Berlin

1 0

Fwd: Re: [B.A.T.M.A.N.] problems running batman rev350
by Axel Neumann 19 May '07

19 May '07

Hey again, ...sorry I forgot to mention: you need tun support loaded into your kernel and the libpthread library (but the latter should be default on most i386 based machines). ---------- Forwarded Message ---------- Subject: Re: [B.A.T.M.A.N.] problems running batman rev350 Date: Saturday 19 May 2007 17:49 From: Axel Neumann <axel(a)open-mesh.net> To: b.a.t.m.a.n(a)open-mesh.net Hey Dragan, > #!/bin/sh > iwconfig eth2 mode ad-hoc essid olsr.freifunk.net channel 10 ap > 02:CA:FF:EE ifconfig eth2 104.130.30.9 (just to be shure) this should be 02:CA:FF:EE:BA:BE .. > i am starting batman with: > > #!/bin/bash > iwconfig eth2 mode ad-hoc essid olsr.freifunk.net channel 10 > ifconfig eth2 105.130.30.9 > ifconfig eth2 up > sleep 1 > batmand -d 1 -p 105.131.41.5 -r 1 eth2 can you start batmand in background with: batmand -r 1 -p 105.131.41.5 eth2 instead and tell if the problem continues. This command instantly returns your prompt but a: ps -aux | grep batmand should show the running main-daemon in the background. Also please check that there are no predefined host routes for the 105.0.0.0/8 network before you start batmand and after it stopped. Meaning a: route -n | grep ^105 berfore and after the daemon is running should only show: 105.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eth2 While batmand is running it should of course show routing entries for all other known batman nodes but if such host routes are still there after the daemon stopped it is a definitive sign for an uncorect termination of teh daemon. > #!/bin/bash > batmand -c -d 2 > > in another terminal. It should of course always be possible to access the debug output from the running batmand main-daemon by launching a batmand-client with batmand -c -d <1-4> or in batch mode (providing just a single outputpage and returns to the prompt) with: batmand -c -d <1-4> -b However, it would be interesting to know if the crash is related to existence of a batmand-client connecting to the main daemon. For example for batmand-0.2.0-rc2-rv350 (and before) debug level 4: batmand -c -d 4 is known to cause the batmand to crash after a short time and it might be possible that this problems also occur with other debug-levels. Try batmand -c -d 1 and batmand -c -d 2 instead. ciao, axel > when batman starts, the 'batmand -c' script shows, that i am connected > to another gateway, but not to preferred one: > > Gateway Router (#/128) > => 105.192.99.62 105.130.30.1 ( 3), gw_class 10 - 6 MBit, > reliability: 0 > 105.192.99.61 105.130.30.1 ( 1), gw_class 7 - 2 MBit, > reliability: 0 > 105.131.83.5 105.130.30.1 ( 1), gw_class 11 - >6 MBit, > reliability: 0 > 105.131.41.5 105.130.30.1 ( 2), gw_class 11 - >6 MBit, > reliability: 0 > 105.192.99.103 105.130.30.1 ( 3), gw_class 7 - 2 MBit, > reliability: 0 > 105.192.99.192 105.130.30.1 ( 2), gw_class 10 - 6 MBit, > reliability: 0 > > ........... > > this always is a number 105.192.99.....(.62, .103, .192). > this condition than stays for 2 or 3 up to 10 minutes, and in that time > i cannot even ping the 105.130.30.1 which is the next point here. > > after some minutes, the connection changes, so that 'batmand -c' shows > that i am connected to 105.131.41.5 and i am able to ping 141.1.1.1. > unfortunately, after some minutes (or even shorter), the batman script > stops and the terminal is at the prompt again. there is no segfault, > using 'ulimit -c unlimited' will not produce a core-dump. i suppose that > this is not a driver bug, cause looking at this moment at 'dmesg', i can > see that the driver is loaded using the 02:ca:ff:ee:ba:by - if i stop > batmand and start olsrd, i will be connected to the internet as expected. > > i am really not aware of what else information i could provide to you, > in order to make batmand running stable here, but if you have any idea, > please let me know! > > cheers, > doc > _______________________________________________ > 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 -------------------------------------------------------

2 1

[B.A.T.M.A.N.] testbed for BATMAN?
by Benjamin Henrion 11 May '07

11 May '07

Hi, I have seen a testbed made with UML instances here to test OLSR: https://wiki.funkfeuer.at/index.php/OLSR-NG I was wondering if it would be possible to setup such system to test BATMAN. Best, -- Benjamin Henrion <bhenrion at ffii.org> FFII Brussels - +32-484-566109 - +32-2-4148403

3 3

[B.A.T.M.A.N.] IPv6 support in batman
by Magesh mannar 10 May '07

10 May '07

Dear All Iam new to BATMAN routing protocol. So forgive me if my question is naive. Does BATMAN protocol support IPv6 addressing. In other words, does the protocol only support IP version 4 or supports v6 as well Kind regards Magesh ____________________________________________________________________________________ Need Mail bonding? Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users. http://answers.yahoo.com/dir/?link=list&sid=396546091

2 1

[B.A.T.M.A.N.] BSD port
by Lorenz Schori 08 May '07

08 May '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello all I looked into trunk/batman/bsd.c on WCW07 and began to work on it this weekend. I believe that i've fixed the routing code and that the tun stuff is working but i'm somehow to stupid to actually test the stuff. My setup is like this: == Mac OSX Intel/10.4 == internal network interface en3 (-> Virtual Machine): 192.168.129.130/25 $ ps auxwww | grep batmand root 2308 0.1 -0.0 28600 436 p2 S+ 8:21PM 0:00.83 ./batmand -d 2 -g 7 en3 $ ifconfig tun0 tun0: flags=8850<POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1500 open (pid 2308) Batman says: No gateways in range ... == Virtualized Debian Linux == eth0: 192.168.129.131/25 batmand -r 3 -d 2 eth0 $ ps auxwww | grep batman root 6784 0.2 0.1 34472 692 pts/1 Sl+ 20:22 0:01 ./ batmand -r 3 -d 2 eth0 Batman says: 192.168.129.130 via: 192.168.129.130(64), gw_class 7 - 2 MBit, reliability: 3 BUT: ifconfig -a does not show any tun device. Is this normal behavior? In my opinion the linux box should create a tun and point the default route to it. Am i wrong? LG Lorenz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGPiHSlNX+1hvKqPsRArYmAJwIJbf068yN+KKgGl/57cz1B+J9GgCbBFWx fswy4zNXXSzFLs0UZIJcXZc= =4w8Y -----END PGP SIGNATURE-----

3 2

[B.A.T.M.A.N.] Release 0.2 rc1
by Axel Neumann 03 May '07

03 May '07

Hello! Despite our optimistic presentation of the almost-stable b.a.t.m.a.n.-III-0.2b release, we could not refrain from applying a number of further changes. Besides some more bugfixes in the outputsystem, resolved crashes due to the hash code and lost unix-sockets, more comments in the code, vis-port-adaption, enhanced BDNB (bidirectional neighbor) check and finally the full implementation of the BNTOG (rebroadcast only packets from best neighbor) check, the most obvious enhancement comes with the new beautifull debug output. Unfortunately the reduction of the frame size in the bidirectional link check from three to two did not cause the improovement (in finding better routes in the mesh) as we expected. Still we want to give it another try with the changes we implemented (for the BDNB check) in this new release. batman-III-0.2.0rc1 is waiting on http://open-mesh.net/batman/downloads for your download. We appreciate your administration ;-) happy testing, the B.A.T.M.A.N. development team

1 0

[B.A.T.M.A.N.] BATMAN tests on BGP confederations
by Acinonyx 12 Apr '07

12 Apr '07

Greetings from Athens, we are planning to test BATMAN as an IGP protocol on BGP confederations in AWMN. AWMN is massive but not excactly a mobile network. It is a network consisted of nodes with many point-to-point links where each node is a BGP AS by itself. Some of us saw the limitations of BGP routing and created BGP confederation to be able to run a faster and smarter protocol among ourselves without disrupting the operation of the rest of the network. Until now we have been using OLSR as IGP with much success. We believe that BATMAN will perform better because it has the ability to measure not only packet loss but link latency and does not create routing loops. Originator Message overhead doesn't concern us at all cause our links have a capacity of more than 30Mbps. So, the tests are going to be made on a small confederation of 12-30 peers. When we have the first results/problems I'll report them to you. Thank you in advance... :-) Best Regards, Vassilis T.

1 0

[B.A.T.M.A.N.] Release 0.2 beta
by axel＠open-mesh.net 08 Apr '07

08 Apr '07

Hi - we, the B.A.T.M.A.N. development team are happy to release B.A.T.M.A.N.-III-0.2.0-beta. We are calling you to download ( http://open-mesh.net/batman/downloads ), update and test now! Since our last release a lot of code has been (re-)written and intermediate code revisions have been tested in real-live deployments, keeping the responsible mesh-node administrators busy with updating, monitoring and writing bug reports. Many thanks to them and especially to Ludger Schmudde who (by constantly challenging the latest revision in an eight-node-16-interfaces-real-life setup) provided invaluable key-informations for finding the most hidden implementation and design bugs. Many sections in the implementation have also undergone improvements to reduce memory consumption and CPU-load like a new hash algorithm implemented by Simon Wunderlich. Now we believe that version 0.2 will bring major improvements in performance, usability and stability. We think that our code base is - despite many changes since version 0.1.2 - reasonably stable now and has been thoroughly tested. There is still no such thing like a configuration file... B.A.T.M.A.N. does not need much tweaking for different deployment situations. This means values for reasonable behavior of the algorithm are hard-coded in the B.A.T.M.A.N. daemon. Of course finding the best hard-coded values to optimize the behavior needs some playing with the algorithm. Our last step before we release 0.2 will be to tweak the hard coded value of the 'bidirectional link checking' algorithm and test the results. Ranking and forwarding of B.A.T.M.A.N. packets is - of course - different if a link between neighbors is bidirectional or unidirectional. So far a link to a single-hop neighbor was considered bidirectional as long as at least one out of the recently self-initiated originator messages came back from this single-hop neighbor within the last *three* seconds. We are going to test the results if this bidirectional-check is made more strict. This release will consider a link as bidirectional as long as at least one of the self-initiated originator messages comes back from this single-hop neighbor within the last *two* seconds. The B.A.T.M.A.N.-III algorithm does support asymmetrical routing *but* if the bidirectional link check algorithm is not strict enough it will prefer asymmetrical routes in the unfavorable direction. If the bidirectional link check is strict enough it will select routes similar to an ETX-like metrik. *Important* Since we are tweaking an important setting in the daemon's behavior we raised the compatibility value - so the new B.A.T.M.A.N.-version will ignore packets from older versions and vice versa. It is possible that we are performing further testing with even stricter values for bidirectional link checking. These versions will also have different compatibility values. Be assured that we won't bother you with tests and updates without reason. The 0.2-release will be available soon. We are calling you to download ( http://open-mesh.net/batman/downloads ), update and test now! The easiest way for updating your openWrt/whiterussian based freifunk router is to issue an: # ipkg install http://downloads.open-mesh.net/batman/mips-whiterussian/batman_III-0.2.0b_m… and restart. If are looking for a freifunk-based web interface (and have not already installed it) run: # ipkg install http://freifunk.schmudde.com/ipkg/freifunk-batman_0.83.ipk happy testing the B.A.T.M.A.N. development team

1 0

[B.A.T.M.A.N.] freifunk-batman-de (0.73 "vampimated")
by Lui 06 Apr '07

06 Apr '07

Hi all, cleanups - and more... ;-) !!!Important!!! For those of you, who have installed any previous versions - 1st: #>ipkg remove freifunk-batman-de For others: freifunk-batman-de is a WebUI-Plugin for the freifunk-firmware (->[1]) It allows to easily configure and manage all aspects of the batman-daemon in a side-by-side environment with olsr (even for unskilled users). The main target have been users in the berlin-freifunk community (104/8 net). The main goal is to raise the amount of batman-nodes in 'a mesh' of heterogeneous skilled node owners over 'the critical-mass' in the phase of development and testing... and of course, to make it easy for myself to manage testing with 10++ batman-nodes. If the interface-config of your hardware differ from those of the Linksys wrt54g v2++/wrt54gl/...(->[2]) you have to use freifunk-batman-*std*-de... Find it at: http://freifunk.schmudde.com/ipkg Regards Lui [1] - http://ff-firmware.sourceforge.net/ [2] - http://wiki.openwrt.org/OpenWrtDocs/Configuration#head-b62c144b9886b221e0c4…

6 6

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