OLSR-Konfiguration: Unterschied zwischen den Versionen

Version vom 25. März 2009, 20:20 Uhr

Gedacht ist diese Konfiguration für OLSR Version 0.5.6-r4 oder neuer.

http://gredler.at/hg/olsrd-0.5.6

HTTP - Statusseite

Falls dein Router schon eine bestehende Webseite hat, dann beim Httpinfo-Plugin den Port ändern (Empfehlung: Port 8000).

Jedoch dann bitte unbedingt von der Startseite der bestehenden Website (auf Port 80) das httpinfo verlinken!!, denn sonst findet es ja niemand.

Ideal ist auch generell ein redirect von /cgi-bin-status.html aufs Httpinfo einzurichten!

Ein Router ohne Statusseite ist zwar technsich machbar, jedoch sehr unfreundlich den anderen FunkFeuer Usern gegenüber, da diese dann nur sehr eingeschränkte Möglichkeiten haben, noch irgendwie herauszufinden, warum es denn eben nicht geht, wenn ihre Daten über deinen Router geroutet werden,..

Neben des OLSR-Infos, sind natürlich auch Kontaktinfos, etc. nützlich , so wie es ja auch auf der Freifunk-Firmware angeboten wird,..

olsrd.conf

Falls du die Freifunk-Firmware nicht verwenden kannst, hier die Standard-olsr-Konfiguration des Netzes:

DebugLevel              0
IpVersion               4
AllowNoInt              yes
FIBMetric               "flat"
TcRedundancy            2
MprCoverage             5
LinkQualityFishEye      1
LinkQualityAlgorithm    "etx_ff"  
LinkQualityLevel 2
UseHysteresis no

LoadPlugin "olsrd_httpinfo.so.0.1"
{
       PlParam     "port"   "80"
       PlParam     "Net"    "0.0.0.0 0.0.0.0"
}
#trag hier deine olsr interfaces (funk, lan, tunnel, etc,..) ein
Interface "eth0" "ath0"
{
       Ip4Broadcast 255.255.255.255
       HelloInterval           3.0
       HelloValidityTime       125.0
       TcInterval              2.0
       TcValidityTime          500.0
       MidInterval             25.0
       MidValidityTime         500.0
       HnaInterval             10.0
       HnaValidityTime         125.0 
}

weitere OLSR-Plugins

grundsätzlich ist es sehr empfehlenswert keine Plugins zu verwenden die man nicht braucht, denn in der Vergangenheit haben diverse Plugins zu oft Probleme bereitet als das man sie just-for-fun installieren/konfigurieren sollte,..

TXTINFO

Dieses wird von der Freifunkfirmware verwendet um ihre eigene Http-Statuseiten mit OLSR-Status-Daten zu versorgen, selbiges kann man nun selber klarerweise auch machen (wer sich das nicht antun will verwendet eben das httpinfo für die olsr-statusseiten)

Weiters ist das txtinfo aber auch nützlich um es per ssh zu verwenden,... oder mit verschiednen tools die Daten weiter auszuwerten,..

wenn man es verwenden will einfach folgende Konfig an obige anhängen (Tip: Der Accept Paramter kann auch mehrfach verwendet werden)

LoadPlugin "olsrd_txtinfo.so.0.1"
{
       PlParam "Accept" "127.0.0.1"
}

DYN_GW und DYN_GW_PLAIN

erkennen automatisch ob dein router eine eigene Internetanbindung hätten, und announcen diese im olsr-Netz.

dies macht in Wien aber keinen Sinn, weil wir eben public IPs auf den Routern konfiguriert haben, und darum eben auch zentrale border-router brauchen (mit BGP), über private Internetanschlüsse Funkfuer traffic rauzurouten würde zu einm NATING führen, und das wäre BÖSE *g

Allerdings kann man trotzdem mit privaten Internet zur Stabiliät des Funkfeuer Netzes beitragen in dem man einen Tunnel anlegt,..

ARPREFRESH

Trägt automatisch die Mac-adressen der oslr nachbarn in den arptable des Routers ein.

Dadurch wird das forwarding theoretisch etwas schneller, und ein klitzekleinweing an arp traffic wird auch gespart.

Allerdings hat dieses plugin in Zusammenhang mit verrücktspielenden Software-bridges (deren source-macadressen defekt waren, während normale arp-requests funktionert haben) schon tagelang router offline gebracht obwohl sie es ja 'eigentlich' nicht waren,..

weitere Parameter

zu den oben angeführen Parametern gibt es noch viele weitere, detailierte infos darüber gibt es u.a. in der olsrd.conf.sample (welche beim olsrd dabei sein sollte)

oder z.b: hier: http://gredler.at/hg/olsrd-0.5.6/file/54e88033741d/src/cfgparser/olsrd.conf.example

NatThreshold

hat den zweck das routing der defaultroute etwas statischer zu gestalten,..

dies macht nur sinn wenn man mehrere gateways hat die einem zu anderen public ips naten würden,..

und dann eben ein wechsel der default route eben auch potentiell einen wechsel des gateways in internet zu folge haben kann.

und eben dieser wechsel zu einer Änderung der 'eigenen' öffentlichen IPadresse führt mit allen daraus resultierenden problemen (verbindungsabbrüche (von downloads), überall neu einloggen, etc.)

bei uns in Wien haben wir allerdings public IPs auf den Routern, und keinerlei nating auf den gateways.

dyngw macht damit bei uns absolut keinen Sinn,

(und ist aufgrund der speziellen /1 routen die unsere gateways announcen auch völlig wirkungslos)