B.A.T.M.A.N April 2007

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

3 participants
3 discussions

[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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

B.A.T.M.A.N April 2007