B.A.T.M.A.N

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

5 participants
4260 discussions

[B.A.T.M.A.N.] Testing
by Dan Flett 23 Jan '07

23 Jan '07

Hi all Seeing as how this list is pretty new, I figure it wouldn't be too rude to send a test message first. Happy BATMAN to you all! Dan

2 2

[B.A.T.M.A.N.] List Language
by Dan Flett 11 Jan '07

11 Jan '07

Hi Guys, At the risk of making myself unpopular at this early stage, could I make a request that all posts to this list be made in English? I am extremely interested in this new routing protocol - as I was in OLSR. I've spent a lot of time trying to translate German with google translator to get a better understanding of OLSR. I'd rather not have to go through that again with B.A.T.M.A.N.! The mailing list info page does list English as the list language, and http://www.open-mesh.net seems to be entirely in English too. If B.A.T.M.A.N. lives up to it's promise, it will be the best mesh protocol yet seen. I would like to see it become popular outside of Europe as soon as possible. Having this list in English will help that happen. Cheers, Dan Flett

2 1

[B.A.T.M.A.N.] make failure
by Pablo Osuna 10 Jan '07

10 Jan '07

Hi, We are having a problem with the first release of B.A.T.M.A.N. When we try to compile it (trying both gcc-3.4 and 4.0), we got the following error: root@Pablo:/home/pablo/Desktop/batman# make gcc -Wall -O0 -g3 -c -o batman.o batman.c batman.c: En la función `send_outstanding_packets': batman.c:889: error: error sintáctico before '<<' token batman.c:891: error: error sintáctico before ')' token batman.c:894: error: error sintáctico before '>>' token batman.c:896: error: error sintáctico before ')' token batman.c:891: aviso: statement with no effect batman.c:896: aviso: statement with no effect batman.c: En el nivel principal: batman.c:927: error: error sintáctico before '}' token make: *** [batman.o] Error 1 We are using Ubuntu distro. Regards: Pablo

2 1

[B.A.T.M.A.N.] IP Aggregation
by Marek Lindner 09 Jan '07

09 Jan '07

Hi, die folgende Idee ist auf dem Kongress in diversen Diskussionen entstanden und bei weitem noch nicht ausgereift. Mich würde eure Meinung dazu interessieren. Bisher rebroadcastet jeder batman Knoten alle batman Pakete (wir ignorieren die Ausnahmen jetzt mal). Können wir einen geschickten Algorithmus entwickeln / anwenden, der es uns gestattet an Stelle des Rebroadcasts der Nachbar-Nachrichten HNA informationen in unserem Paket mitzusenden ? So könnte das funktioneren: Mein batman Knoten merkt, dass er 3 one Hop Nachbarn hat, welche keine anderen Nachbarn hinter sich haben. Daher nehme ich diese Nachbarn als HNA auf. Meine anderen Nachbarn erhalten nun das Paket und können feststellen, dass meine IP und die IPs meine Nachbarn ziemlich dicht beieinander sind und stopfen uns alle in eine HNA Nachricht. Die Vorteil liegt auf der Hand: Weniger batman Pakete und weniger Routeneinträge. Wir müssten das aber so geschickt machen, dass wir nicht unsere eigene Statistik fälschen. Wenn ich zu meinem aggregierten Nachbarn 50% packet loss habe, ihn aber in jeder meine OGMs erwähne, könnte der Eindruck entstehen, dass der Link recht gut ist ?! Was meint ihr ? Gruß, Marek

2 2

FW: [Fwd: Re: [B.A.T.M.A.N.] B.A.T.M.A.N. läuft jetzt auch permanent auf der Zwingli-Nordost - 105.130.1.67]
by Lui 09 Jan '07

09 Jan '07

Hallo Liste ;-) na dann dies auch gleich hier... Lui >-----Original Message----- >From: Ludger Schmudde [mailto:Lui@Schmudde.com] >Sent: Montag, 8. Januar 2007 22:52 >To: 'elektra' >Cc: 'Marek Lindner' >Subject: RE: [Fwd: Re: [B.A.T.M.A.N.] B.A.T.M.A.N. läuft jetzt >auch permanent auf der Zwingli-Nordost - 105.130.1.67] > >elektra, > >(ahh, Info hast'e ja schon) >>>> * Beim WLAN-Routing wählt BATMAN tendenziell den (schlechern?) >>>> direkten (1-Hop) Weg. >>>> [...] > >>habe Ich das richtig verstanden - BATMAN wählt von 3 direkten >>Linkstrecken ohne Zwischenhop die schlechtere? > >Ja: >_3.PharusEmmaus >WLAN-IP: LAN-IP: 2007.01.08-19:51:25 >105.192.192.66 105.192.192.83 >_______________ _______________ __________________________ >105.0.0.0 0.0.0.0 ---.0.0.0 U eth1 >105.130.30.1 105.192.192.87 ---.---.---.--- UGH br0 >105.192.192.1 105.192.192.81 ---.---.---.--- UGH br0 >105.192.192.133 105.192.192.85 ---.---.---.--- UGH br0 >105.192.192.166 105.192.192.86 ---.---.---.--- UGH br0 >105.192.192.199 105.192.192.87 ---.---.---.--- UGH br0 >105.192.192.225 105.192.192.88 ---.---.---.--- UGH eth1 [1] >105.192.192.33 105.192.192.82 ---.---.---.--- UGH br0 >105.192.192.80 0.0.0.0 ---.---.---.240 U br0 >105.192.192.81 0.0.0.0 ---.---.---.--- UH br0 >105.192.192.82 0.0.0.0 ---.---.---.--- UH br0 >105.192.192.84 0.0.0.0 ---.---.---.--- UH br0 >105.192.192.85 0.0.0.0 ---.---.---.--- UH br0 >105.192.192.86 0.0.0.0 ---.---.---.--- UH br0 >105.192.192.87 0.0.0.0 ---.---.---.--- UH br0 >105.192.192.88 0.0.0.0 ---.---.---.--- UH br0 >105.192.192.99 105.192.192.84 ---.---.---.--- UGH br0 >105.192.99.103 105.192.99.192 ---.---.---.--- UGH eth1 [3] >105.192.99.150 105.192.99.192 ---.---.---.--- UGH eth1 [3] >105.192.99.192 0.0.0.0 ---.---.---.--- UH eth1 [3] >105.192.99.50 105.192.99.192 ---.---.---.--- UGH eth1 >xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx xxx xxxx [2] > >[1] ??? via eth1(/WLAN) auf die LAN-IP des direkt via LAN > erreichbaren Nachbarn ??? >[2] hier fehlt noch etwas wie: >105.192.99.160 105.192.192.84 ---.---.---.--- UH br0 >105.192.99.60 105.192.192.84 ---.---.---.--- UGH br0 > >[3] = da wäre (s.o.) ein "via 105.192.192.84" (2-Hops) besser... >siehe - Vergleich 105../104...: > >root@_3:~# ping 105.192.99.192 >PING 105.192.99.192 (105.192.99.192): 56 data bytes >64 bytes from 105.192.99.192: icmp_seq=1 ttl=63 time=32.5 ms >64 bytes from 105.192.99.192: icmp_seq=2 ttl=63 time=43.4 ms >64 bytes from 105.192.99.192: icmp_seq=3 ttl=63 time=67.2 ms >64 bytes from 105.192.99.192: icmp_seq=5 ttl=63 time=22.2 ms > >--- 105.192.99.192 ping statistics --- >8 packets transmitted, 4 packets received, 50% packet loss >round-trip min/avg/max = 22.2/41.3/67.2 ms > >root@_3:~# ping 104.192.99.192 >PING 104.192.99.192 (104.192.99.192): 56 data bytes >64 bytes from 104.192.99.192: icmp_seq=0 ttl=63 time=12.2 ms >64 bytes from 104.192.99.192: icmp_seq=1 ttl=63 time=11.6 ms >64 bytes from 104.192.99.192: icmp_seq=2 ttl=63 time=7.0 ms >64 bytes from 104.192.99.192: icmp_seq=3 ttl=63 time=7.6 ms >64 bytes from 104.192.99.192: icmp_seq=4 ttl=63 time=7.8 ms >64 bytes from 104.192.99.192: icmp_seq=5 ttl=63 time=11.6 ms > >--- 104.192.99.192 ping statistics --- >6 packets transmitted, 6 packets received, 0% packet loss >round-trip min/avg/max = 7.0/9.6/12.2 ms root@_3:~# rt > >>Kannst Du mal da Daten drüberjagen und schauen wie sich das mit der >>Geschwindigkeit verhält? >>Einfach mal n wget von der 105er und der 104er Adresse aus /dev/zero >>vielleicht? > >Das probiere ich schon länger - die Ergebnisse steuen aber >derart, daß daraus nichts zu sehen ist außer, das _während_ >eines 10Sek. >Testtransfers die Routen mehrfach wechseln oder wegbrechen (->Anhang) > >...gerade auch entdeckt: >m99_PharusE >WLAN-IP: LAN-IP: 2007.01.08-19:54:55 >105.192.99.192 105.192.99.62 >_______________ _______________ __________________________ >105.0.0.0 0.0.0.0 ---.0.0.0 U eth1 >105.130.30.1 105.192.192.66 ---.---.---.--- UGH eth1 [1] >105.192.192.1 105.192.192.99 ---.---.---.--- UGH eth1 >105.192.192.133 0.0.0.0 ---.---.---.--- UH eth1 >105.192.192.166 105.192.192.99 ---.---.---.--- UGH eth1 >105.192.192.199 105.192.192.99 ---.---.---.--- UGH eth1 >105.192.192.33 105.192.192.99 ---.---.---.--- UGH eth1 >105.192.192.81 105.192.192.133 ---.---.---.--- UGH eth1 >105.192.192.82 105.192.192.133 ---.---.---.--- UGH eth1 >105.192.192.83 105.192.192.66 ---.---.---.--- UGH eth1 [1] >105.192.192.84 105.192.192.99 ---.---.---.--- UGH eth1 >105.192.192.85 105.192.192.133 ---.---.---.--- UGH eth1 >105.192.192.86 105.192.192.133 ---.---.---.--- UGH eth1 >105.192.192.87 105.192.192.66 ---.---.---.--- UGH eth1 [1] >105.192.192.88 105.192.192.133 ---.---.---.--- UGH eth1 >105.192.192.99 0.0.0.0 ---.---.---.--- UH eth1 >105.192.99.0 0.0.0.0 ---.---.---.192 U br0 >105.192.99.103 105.192.99.160 ---.---.---.--- UGH eth1 >105.192.99.150 0.0.0.0 ---.---.---.--- UH eth1 >105.192.99.160 0.0.0.0 ---.---.---.--- UH eth1 >105.192.99.50 0.0.0.0 ---.---.---.--- UH eth1 >105.192.99.60 105.192.99.160 ---.---.---.--- UGH eth1 >105.192.99.61 0.0.0.0 ---.---.---.--- UH br0 > >[1] 3x via 105.192.192.66 aber *dorthin* fehlt die Route!? > >[Restart+1h]: m99_PharusE >WLAN-IP: LAN-IP: 2007.01.08-21:00:25 >105.192.99.192 105.192.99.62 >_______________ _______________ __________________________ >105.0.0.0 0.0.0.0 ---.0.0.0 U eth1 >105.192.192.1 105.192.192.99 ---.---.---.--- UGH eth1 >105.192.192.133 0.0.0.0 ---.---.---.--- UH eth1 >105.192.192.166 105.192.192.133 ---.---.---.--- UGH eth1 >105.192.192.199 105.192.192.133 ---.---.---.--- UGH eth1 >105.192.192.225 105.192.192.133 ---.---.---.--- UGH eth1 >105.192.192.66 105.192.192.133 ---.---.---.--- UGH eth1 >105.192.192.81 105.192.192.133 ---.---.---.--- UGH eth1 >105.192.192.82 105.192.192.133 ---.---.---.--- UGH eth1 >105.192.192.83 105.192.192.66 ---.---.---.--- UGH eth1 [...] >105.192.192.85 105.192.192.133 ---.---.---.--- UGH eth1 >105.192.192.86 105.192.192.133 ---.---.---.--- UGH eth1 >105.192.192.87 105.192.192.66 ---.---.---.--- UGH eth1 [...] >105.192.192.88 105.192.192.99 ---.---.---.--- UGH eth1 >105.192.192.99 0.0.0.0 ---.---.---.--- UH eth1 >105.192.99.0 0.0.0.0 ---.---.---.192 U br0 >105.192.99.103 105.192.99.150 ---.---.---.--- UGH eth1 >105.192.99.150 0.0.0.0 ---.---.---.--- UH eth1 >105.192.99.160 0.0.0.0 ---.---.---.--- UH eth1 >105.192.99.50 0.0.0.0 ---.---.---.--- UH eth1 >105.192.99.60 105.192.99.160 ---.---.---.--- UGH eth1 >105.192.99.61 0.0.0.0 ---.---.---.--- UH br0 > >Nun fehlt z.B. das WLAN-IF (.33) von _2 (.82) - und so weiter... > >Routing- und Last- /Auffälligkeiten/ sind nicht wirklich >reproduzierbar... > >Auch Dinge wie diese: >>>> top/%MEM ist (_1 bis _8): 5.0/6.5/12.1(!)/6.6/6.7/4.8/3.0(!)/5.6 > >ändern sich z.B. beim Restart eines (beliebigen) Knoten u.U. >komplett... > >Das hat offensichtlich nichts mit dem lokalen Code, sondern dem >Gruppen/Zeit- Verhalten zu tun; sicher sind auch externe >Einflüsse von Bedeutung. Von meiner Überlegung diese mal >auszuschließen ("Batman-Only Test") bin ich selbst nicht >wirklich überzeugt (->Falsche Sicherheit...). > >Schon bei einer handvoll von Routern sind via Console/WebUI >solcherlei Dynamik nicht mehr auseinander zu dröseln - da >müßten Tools für her... > >...irgendwas, das Routing- & Last-Verhalten eines >Router-Clusters /sichtbar/ machen kann - ohne freilich selbst >Einfluss zu nehmen. > >Sonst ist das irgendwie fischen im Trüben... > >Grüße >Lui >

1 0

[B.A.T.M.A.N.] path selection
by axel 09 Jan '07

09 Jan '07

Hi, there is also one concern bothering my mind since a while. I think the protocol currently establishes routes between nodes, but optimizes them the wrong way around. More concrete, the originatorMessages (OGMs) initiated by each node install routing information for DOWN-link traffic in the mesh which are actually optimized for UP-link traffic. The following scenario and attached figure (is of course a little bit constructed but it) may illustrate this. The figure shows 4 nodes (A,b,c,D) and 4 existing links between them A-b, b-D, A-c, and c-D - thus, two potential routes between node A and D. The links b-D and c-D are symmetric, perfect links with 0% packet loss. The links A-b and A-c are asymmetric links with 0% packet loss for A->b and A<-c, but 50% loss for A<-b and A->c (See attached figure). However, each of the 4 links can be assumed as a bidirectional link since at least every second OGM will reach the corresponding link neighbor. Now, node A would receive 100% of the OGMs initiated by D and rebroadcasted via node c but wouldreceive only 50% via node b. Therefore A would select c as its best nighbor towards D (obversely D would select b as its best neighbortowards A). However, in this case, that is not the best choice since every second packet send via A-c-D needs to be retransmitted on the link A-c, which would not be necessary if send via A-b-D . Don't know if you agree, ...is that reasonable? Also I don't have any simple approach in mind to solve this but it might be worth to reconsider. ciao, axel

2 1

[B.A.T.M.A.N.] invitation to B.A.T.M.A.N@list.open-mesh.net mailing list
by yokoy 08 Jan '07

08 Jan '07

Vielen Dank fuer die Einladung. Und fuer B.A.T.M.A.N. yky

1 0

[B.A.T.M.A.N.] Fwd: RE: Version 0.1.1.x?
by Marek Lindner 08 Jan '07

08 Jan '07

Hi, bin jetzt auch auf der Liste. Hier mal die aktuellen News ... :-) Spricht was dagegen die anderen batman Aktivisten einzuladen auf die Liste zu kommen ? Oder die Liste von der Webseite zu verlinken ? Gruß, Marek PS: Finde super, dass es diese Liste nun gibt - gute Arbeit ! ---------- Weitergeleitete Nachricht ---------- Subject: RE: Version 0.1.1.x? Date: Freitag, 5. Januar 2007 18:37 From: "Ludger Schmudde" <Lui(a)schmudde.com> To: "'Marek Lindner'" <lindner-marek(a)diderot.phidelu> Holla, >> ...wollte Emma gerade updaten - Du hattest (AFAIR) von '0.1.1a(lpha)' >> gesprochen - liegt noch 'n ...b(eta)? which is 'nu what? > >jo - nimm die beta. Habs noch ein bisschen verbessert. :-) ...da hat sich ja über meine Weihnachtspause schön was getan ;-) 4+8 Router (8+16 IFs): ---------------------- * LAN-Packetloss (wenn überhaupt) nahe 1/100... das waren bei den Netzspielreien der letzten Tage *ohne Batman* eher 3-10 von 100...? (zwischenzeitlich gab es aber mal /bursts/ bis zu 10%...??? Evtl. durch meine intensiven http-requests verursacht, oder irgendwer hat nochmal gespielt...?) * Das LAN-Routing schaut quasi handoptimiert aus ;-) Beispiel: _6.PharusEmmaus WLAN-IP: LAN-IP: 2007.01.05-18:17:20 105.192.192.166 105.192.192.86 _______________ _______________ __________________________ 105.0.0.0 0.0.0.0 ---.0.0.0 U eth1 105.130.30.1 0.0.0.0 ---.---.---.--- UH eth1 105.192.192.1 105.192.192.81 ---.---.---.--- UGH eth1 105.192.192.133 105.192.192.85 ---.---.---.--- UGH eth1 105.192.192.225 105.192.192.88 ---.---.---.--- UGH eth1 105.192.192.33 105.192.192.82 ---.---.---.--- UGH eth1 105.192.192.66 105.192.192.83 ---.---.---.--- UGH eth1 105.192.192.80 0.0.0.0 ---.---.---.240 U br0 105.192.192.81 0.0.0.0 ---.---.---.--- UH br0 105.192.192.82 0.0.0.0 ---.---.---.--- UH eth1 105.192.192.83 0.0.0.0 ---.---.---.--- UH br0 105.192.192.84 0.0.0.0 ---.---.---.--- UH br0 105.192.192.85 0.0.0.0 ---.---.---.--- UH eth1 105.192.192.87 0.0.0.0 ---.---.---.--- UH eth1 105.192.192.88 0.0.0.0 ---.---.---.--- UH br0 105.192.192.99 105.192.192.84 ---.---.---.--- UGH eth1 105.192.99.103 105.192.192.133 ---.---.---.--- UGH eth1 105.192.99.150 105.192.192.133 ---.---.---.--- UGH eth1 105.192.99.192 105.192.192.85 ---.---.---.--- UGH eth1 105.192.99.50 105.192.99.192 ---.---.---.--- UGH eth1 105.192.99.60 105.192.192.83 ---.---.---.--- UGH eth1 105.192.99.62 105.192.192.83 ---.---.---.--- UGH eth1 Frage: die IF-Spalte (letzte) macht wenig Sinn. Hat das Einfluß? Welchen? (eigendlich sollte da überall br0 stehen, außer bei den ersten beiden Einträgen) * Beim WLAN-Routing wählt BATMAN tendenziell den (schlechern?) direkten (1-Hop) Weg. Z.B. zwischen Emmaus und m99 über #_3 (105.192.66/.83) statt #_4 (105.192.99/.84) oder #_5 (105.192.133/.85) OLSR sieht das so auf 104.192.99.192 (=GW & 'Sternpunkt' für _3, _4 und _5): Nachbarn: IP Hyst. LQ lost total NLQ ETX 104.192.192.33 0.00 0.23 77 100 0.00 0.00 104.192.192.66 0.00 0.42 58 100 0.48 4.98 # <- _3 | => von Batman gewählt. 104.192.192.99 0.00 0.94 6 100 0.57 1.87 # <- _4 | typische ETX-Differenz 104.192.192.133 0.00 0.93 7 100 0.66 1.63 # <- _5 | im Bereich +/-0,2 ... 104.192.192.166 0.00 0.50 50 100 0.00 0.00 ...das kann aber natürlich am OLSR-induzierten Traffic liegen. * top meint: Load bei ~1.50 (+/- 0.30) CPU typisch bei 22.0(+/- 5%) [Nachtrag (nach 11h Laufzeit):] top/%MEM ist (_1 bis _8): 5.0/6.5/12.1(!)/6.6/6.7/4.8/3.0(!)/5.6 _7 (3.0) - mit -p Option gestartet _3 (12.1) - OLSR routet ja via _4/_5 (s.o.), so ist das ein Kandidat, der (s.o.) häufiger komplett umroutet, weil der OLSR-induzierte Payload via _4/_5 schwankt...? Bei den anderen ist das ein schleichender Prozess... - ach ja, alles mit -r 2 Da dröppelt also noch irgend eine Speicher-Muffe... * Ins Log (nur _7) wird nix geschrieben... Ich würde ja mal einen Batman-Only Test fahren wollen... Evtl. frage ich mal auf der 36er Liste nach Widerspruch und mache *ein* Paket aus freifunk-batman mit batmand, testtools, etc., dessen Startscript den olsrd mal abdreht ;-) Grüße Lui -------------------------------------------------------

3 5

[B.A.T.M.A.N.] Hello B.A.T.M.A.N. Subscribers
by elektra 04 Jan '07

04 Jan '07

... cu elektra

1 0

[B.A.T.M.A.N.] Welcome to the B.A.T.M.A.N. mailing list
by axel 03 Jan '07

03 Jan '07

HeyHo, in the hope that such a list can boost communication and productivity... (... and also for testing purposes) have fun and a happy new year! axel

1 0

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