Zeile 1: |
Zeile 1: |
| + | [[Kategorie:Howto]] |
| ===BATMAN fliegt durchs Weimarnetz=== | | ===BATMAN fliegt durchs Weimarnetz=== |
| *BATMAN ist ein neues, revolutionaeres ("ja, das sagen 'se alle...") Routingprotokoll, welches OLSR vielleicht mal abloesen wird | | *BATMAN ist ein neues, revolutionaeres ("ja, das sagen 'se alle...") Routingprotokoll, welches OLSR vielleicht mal abloesen wird |
− | *Am 10 Juli 2006 um 12 Uhr wurde BATMAN auf allen - ca. 100 - Routern im Weimarnetz aktiviert. | + | *Am 10 Juli 2006 um 12 Uhr wurde BATMAN auf allen - ca. 100 - Routern im Weimarnetz aktiviert. |
| + | *'''Deaktiviert:''' Aufgrund von uebermaessigem CPU-Verbrauch, wurde BATMAN in den fruehen Morgenstunden wieder deaktiviert. Siehe [[Batman-Test-Analyse]] |
| *Es laeuft auf einem Aliasinterface: 103.63.knotennummer.1 / wifi | | *Es laeuft auf einem Aliasinterface: 103.63.knotennummer.1 / wifi |
| *Ihr koennt in der Routentabelle mit <tt>ip route|grep 103.63</tt> sehen, wieviel Routen schon existieren | | *Ihr koennt in der Routentabelle mit <tt>ip route|grep 103.63</tt> sehen, wieviel Routen schon existieren |
Zeile 138: |
Zeile 140: |
| das Mesh reisen oder unterwegs irgendwann verloren gehen. Geht ein Broadcast | | das Mesh reisen oder unterwegs irgendwann verloren gehen. Geht ein Broadcast |
| verloren wird nicht nach dem Verbleib oder einer Neuübetragung gefragt - | | verloren wird nicht nach dem Verbleib oder einer Neuübetragung gefragt - |
− | anders als bei TCP-Daten, wo bis zu 7 mal die ?bertragung wiederholt wird, | + | anders als bei TCP-Daten, wo bis zu 7 mal die �?bertragung wiederholt wird, |
| wenn eine Bestätigung des Empfängers ausbleibt. | | wenn eine Bestätigung des Empfängers ausbleibt. |
| | | |
Zeile 193: |
Zeile 195: |
| | | |
| Herrscht Gleichstand an empfangenen Paketen von zwei oder mehreren Nachbarn | | Herrscht Gleichstand an empfangenen Paketen von zwei oder mehreren Nachbarn |
− | entscheidet die ?te TTL (geringster Hopcount). Herrscht Gleichstand auch | + | entscheidet die grö�?te TTL (geringster Hopcount). Herrscht Gleichstand auch |
| bei der TTL entscheidet wer das letzte eingegangene Orginator-Paket zum | | bei der TTL entscheidet wer das letzte eingegangene Orginator-Paket zum |
| Zielknoten gebroadcastet hat. | | Zielknoten gebroadcastet hat. |
Zeile 209: |
Zeile 211: |
| dass Verbindungen unsymmetrisch sein können. Die Annahme ist, dass auf dem | | dass Verbindungen unsymmetrisch sein können. Die Annahme ist, dass auf dem |
| Pfad auf dem die Pakete von Node A den Node F erreichen auch die beste | | Pfad auf dem die Pakete von Node A den Node F erreichen auch die beste |
− | ?bertragung in die Gegenrichtung möglich ist. Das ist im Fall von
| + | �?bertragung in die Gegenrichtung möglich ist. Das ist im Fall von |
| unsymmetrischen Links ein Trugschluss. Unsymmetrische Links treten auf wenn | | unsymmetrischen Links ein Trugschluss. Unsymmetrische Links treten auf wenn |
| ein Router zwar einen anderen hört, aber umgekehrt nicht. Es kann sein, dass | | ein Router zwar einen anderen hört, aber umgekehrt nicht. Es kann sein, dass |
− | eine perfekte ?bertragung möglich ist - aber nur in eine Richtung. Das | + | eine perfekte �?bertragung möglich ist - aber nur in eine Richtung. Das |
| einfache B.A.T.M.A.N-Verfahren würde hier komplett scheitern. Es muss also | | einfache B.A.T.M.A.N-Verfahren würde hier komplett scheitern. Es muss also |
| geprüft werden ob Links symmetrisch sind und nur Informationen die von | | geprüft werden ob Links symmetrisch sind und nur Informationen die von |
Zeile 257: |
Zeile 259: |
| Elektra, Thomas, Axel, Felix | | Elektra, Thomas, Axel, Felix |
| </pre> | | </pre> |
| + | |
| + | ===BATMAN fliegt durchs Weimarnetz - die Zweite=== |
| + | =was wollen wir?= |
| + | * route vergleichen ->trace |
| + | ** laenge -> trace |
| + | ** bandbreite der links - werden auch schmalbandige links genutzt? -> infoseite |
| + | ** packetloss -> floodping |
| + | ** Wechseln der Routen |
| + | * wie schnell fuellt sich die routingtabelle |
| + | * cpu auslastung -> infoseite / monitoring |
| + | * speicher -> infoseite / monitoring |
| + | * Anzahl der Nodes |
| + | * Traffic des Protokoll -> codeschnipsel |
| + | |
| + | =wie= |
| + | * alle schalten batman ein -> infoseite |
| + | * wenige testen |
| + | * ein script fuer alle -> matas |
| + | * schoen waere die funktionalitaet vom monitoring zu nutzen -> jens |
| + | |
| + | ** Ideen: [[Benutzer:Storchi|Storchi]] 16:23, 24. Okt 2006 (CEST) und [[Benutzer:matas|matas]] |
| + | * wer macht mit? |
| + | ** [[Benutzer:matas|matas]] |
| + | ** [[Benutzer:Storchi|Storchi]] 16:23, 24. Okt 2006 (CEST) |
| + | ** [[Benutzer:Andi.braeu|Andi.braeu]] 08:37, 25. Okt 2006 (CEST) |
| + | ** [[Benutzer:MegaDave|MegaDave]] 15:31, 25. Okt 2006 (CEST) |
| + | ** [[Benutzer:Fries43|fries43]] 00:49, 26. Okt 2006 (CEST) |
| + | |
| + | ===Batman installieren=== |
| + | * der grundsaetzliche Vorgaeng um Batman zu installieren ist im SVN zu finden und schon in die weimarnetzfirmware integriert |
| + | ** [http://svn.sourceforge.net/viewvc/weimarnetz-fw/trunk/firmware/usr/sbin/cron.weimarnetz.halfhourly.2.batman_starten.sh?revision=27&view=markup batman_starten] |
| + | * der grobe vorgang beschreibt sich wie folgt: |
| + | ** Aliasinterface am dem WLAN anlegen mit |
| + | *** gleiche IP wie WLAN bisher nur erstes Oktett veraendern, dann blickt man besser durch |
| + | *** Beispiel: normale IP = 104.1.1.1 und BATMAN-IP dann 103.1.1.1, mit: |
| + | <pre> |
| + | WIFI=$(nvram get wifi_ifname) |
| + | IP=$(nvram get lan_ipaddr|awk '{gsub(/104./,"103.");print}') |
| + | ip addr add dev $WIFI $IP/8 brd 103.255.255.255 label $WIFI:2 |
| + | </pre> |
| + | ** BATMAN starten, wie folgt: |
| + | <pre> |
| + | batman $WIFI:2 & |
| + | </pre> |
| + | * nun kann man nach einer weile alle batman-knoten anpingen, oder mit traceroute die wege verfolgen |