B.A.T.M.A.N

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

11 participants
4293 discussions

[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

[B.A.T.M.A.N.] b.a.t.m.a.n & OLPC
by Diego Paez 21 Mar '07

21 Mar '07

Hi! i wonder if there are some chances to test b.a.t.m.a.n protocol over a olpc...I want to test it, but i know that we have some things to consider, like the ability for the protocol to run into the arm9e processor (the processor of the marvell libertas, some specifications here http://arm.com/products/CPUs/ARM946E-S.html ). Im gonna need some code and/or some documentation...anything :D... However my english isn't that good...Sorry! Thanks! Diego Facultad de Informatica UNLP

2 1

[B.A.T.M.A.N.] Visualisation software
by Andreas Langer 13 Mar '07

13 Mar '07

The visualisation software is a own programm, you can find it on s3d.berlios.org. When you have problems with install join irc at freenode channel #s3d , d0tslash is the lead developer and can help you with install. The visualisation for batman is in work and coming soon, i hope not later than april. regards, andreas

1 1

[B.A.T.M.A.N.] protocol performance
by Atis 13 Mar '07

13 Mar '07

Hi, a bunch of questions about B.a.t.m.a.n. performance and your future plans. After studying the source code, I understand that HNA information is included in every originator message. Isn't such excessive amount of routing information bad for typically limited-capacity wireless links? What are the results of real-world tests - there isn't much info in open-mesh.net about that. What is the largest network in which B.a.t.m.a.n. have been tested? Is there some actual evidence that B.a.t.m.a.n. outperforms OLSR? And if you concerned about its performance, too - have you considered using Fish-eye to improve the algorithm? It could be either periodical TTL modifications or not including all HNA information in each originator message (i.e. include them in only, say, every 10-th). The second approach could work if there some kind of route-request message. Another approach I can think of would be to introduce some kind of delay in forwarding as the originator packet get farther away from its originator. Or introduce random probability of not forwarding it. Have you thought of adding some re-active components (like in Hazy Sighted Link State protocol)? What about handling of asymmetrical links? Currently BATMAN appears to have an implicit assumption of symmetry. Is there any plans to incorporate asymmetrical link support? 'Neighbor Link Quality' field perhaps? Or do you feel that this is something unnecessary for real world setups? And, finally, what exactly is batman-experimental? A prototype for B.a.t.m.a.n.-IV implementation? Thanks, A.E.

3 2

[B.A.T.M.A.N.] Visualisation software
by Saurabh Gupta 13 Mar '07

13 Mar '07

Hi, I am going to test the batman-3 -0.2.0a release . Where can I find the visualisation software to use with the package. Please some one point me to some link. Thanks, Saurabh

1 0

[B.A.T.M.A.N.] Status in IETF
by elektra 12 Mar '07

12 Mar '07

Hello Dominik - we have not submitted a draft to the IETF yet. Rather than writing drafts according to IETF style about ideas, we are spending time on improving the performance of our protocol by testing it in real life. Within 12 months of development we have left behind B.A.T.M.A.N.-I and B.A.T.M.A.N.-II. The successor of B.A.T.M.A.N.-III will be available in the near future - I'm sure it will give the protocol a good boost in performance. 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. Of course our documentation can and will be improved. It would be nice if people find it easier to understand how B.A.T.M.A.N. works. But I think a animation movie with comments would be much more helpful than a text in the style of usual IETF documents. I guess the development team will have no objections if someone is going to write a IETF-Draft about the final version of B.A.T.M.A.N. We may write a draft of B.A.T.M.A.N.-IV as soon as it is properly implemented and thoroughly tested. cu elektra

3 2

Re: [B.A.T.M.A.N.] How does BATMAN work?
by Hendrik 06 Mar '07

06 Mar '07

Hi, first of all thanks for the quick and good help! It realy helped a lot (and gave me about 3 more pages to write about BATMAN ;oP)! Now I got two more Question (hope I don't bother you too much) 1. What Fields are there in the OGM-Package/Header? As to this point I got: - TTL - Seq.No. - Orig.IP - Unidrectional Flag and as possible extension - "Reachable Subnets" - "Is willing to Serve as a gateway". Are there any others? 2. Electra wrote: "A Originator will see others repeating its Originator messages if the radio conditions provide a bidirectional link. This is the only case when we send feedback to others [..] Of course a OGM with unidirectional flag is only helpful for its Originator, to learn: Hey, this node has seen me and I have seen it. So we have a bidirectional link!" about retransmitting an OGM. Can the Originator of an OGM use this Information to put his direct neighbor in his routingtable (since that is nessesary for knowing "So we have a bidirectional link" ;o) ), or does it has to wait for the OGM of his direct neighbor (neighbor is the originator) to arrive? (I guess waiting is the answer, I just want to be sure) Thanks Hendrik

2 1

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