# olsr.org OLSR Daemon Konfigurationsdatei
# Diese Datei ist eine typische Konfiguration
# für ein Mesh-Netzwerk aus überwiegend stationären
# Knoten wie sie von Freifunk verwendet wird.

# Debug level(0-9)
# Dieser Wert gibt an welche Informationen der Daemon
# auf das Terminal ausgibt. Bei Null gibt er keine Informationen
# aus und geht sofort in den Hintergrund. In einem großen Netzwerk
# werden bei Werten größer Null so viele Informationen ausgegeben, dass
# die Ausgabe einfach durchrauscht. Man sollte sie dann über eine
# Pipe in eine Datei umleiten damit sie in Ruhe betrachtet werden kann.
# Noch besser ist es, das Olsr-Plugin ?Httpinfo? zu laden und sich die
# Ausgaben von Olsrd bequem in einem Webbrowser anzeigen zu lassen.
# Debugging braucht eine beträchtliche Menge Rechenleistung
# wenn das Netz einigermassen groß ist. Für kleine Embedded-Systeme
# sollte der Wert auf 0 gesetzt werden.
DebugLevel 1

# Soll der Fischaugenmechanismus verwendet werden?
# 0 = aus, 1 = an
LinkQualityFishEye 1

# Die folgende Einstellung verhindert, dass jede eintreffende neue
# Topologie-Nachricht ein erneutes Durchrechnen der gesamten
# Netzwerkdatenbank auslöst. Das ist nicht nötig wenn eine Veränderung
# in einiger Entfernung (einige Sprünge) auftritt. Allerdings sollten
# Veränderungen in der Topologie bei benachbarten Knoten unmittelbar
# berücksichtigt werden.
# Hier müssen zwei Werte eingegeben werden. Der erste Wert - eine Ganzzahl -
# gibt die Anzahl der Sprünge an. Ein Wert von 2 bedeutet, dass nur
# neue Topologie-Informationen die von direkten Nachbarn (Single-Hop) oder
# Nachbarn zweiter Ordnung (Two-Hop) stammen ein Durchrechnen der
# Routingtabelle auslösen. Wird der Wert auf Null gesetzt löst keine
# eintreffende Topologie-Nachricht eine Neuberechnung aus.
# Der zweite Wert, eine Zahl mit einer Kommastelle, gibt an in welchem
# Intervall die Routingtabelle neu berechnet wird wenn der
# erste Wert für den Hopcount auf Null gesetzt ist.

LinkQualityDijkstraLimit 3 6.0

# Version des Internetprotokolls
# IPv4 = 4
# IPv6 = 6
IpVersion 4

# Soll die Anzeige im Terminal jedesmal neu aufgebaut werden wenn
# eine Zustandsänderung eintritt? yes/no
ClearScreen yes

# HNA IPv4 Routen (HNA = Host Network Announcement):
# über eine HNA-Nachricht kann ein Olsr-Knoten mitteilen, dass er ein Gateway
# zu anderen Subnetzwerken oder Hosts ist. Auf diese Weise kann man z.B.
# Geräte ohne OLSR (VOIP-Telefone, PDAs) in das Meshnetz einbinden ohne
# IP-Masquerading zu verwenden. In den Geräten ohne Olsrd wird dann dieser
# Olsr-Router, der den HNA ankündigt als Gateway angegeben (entweder von
# Hand oder über DHCP). Dabei sollten die Administratoren der Mesh-Knoten
# sich unbedingt darüber verständigen wer welche Subnetzwerkadressen benutzt
# beziehungsweise ankündigt. Das Olsr-Plugin ?Httpinfo? listet alle
# HNA-Ankündigungen im Mesh unter der URL http://localhost:8080/nodes
# auf. Ein prüfender Blick in die bereits existierenden HNAs kann nicht
# schaden um Kollisionen zu vermeiden, bevor ein neues HNA eingerichtet
# wird. Ein beliebtes Problem ist, dass ein Meshrouter das gleiche
# Subnetzwerk per HNA ankündigt, das auch von einem anderen Olsr-Router
# im Mesh auf seinem Ethernetport verwendet wird. Vor allem die bekannten
# Klasse C Netzwerke 192.168.0.0 und 192.168.1.0 sollte man unbedingt
# vermeiden. Das kann nicht gutgehen!
#
# Stattdessen unbedingt Subnetzadressen lokal verwenden beziehungsweise
# ankündigen, die nicht von den Olsr-Routern von Liesschen Müller und
# Otto Normalverbraucher benutzt werden. Verwenden Liesschen und Otto am
# Ethernetport ihrer Olsr-Router die Subnetzadresse 192.168.1.0/24 kann
# Liesschen von ihrem PC nicht mehr auf ihren Router zugreifen wenn Otto
# eine HNA zu ?seinem? Subnetz 192.168.1.0/24 ankündigt - obwohl sie direkt
# per Kabel mit ihrem Router verbunden ist. Liesschens Olsr-Router trägt wegen
# der HNA von Otto einen benachbarten Olsr-Router als Gateway zu Otto?s
# kollidierendem Subnetz ein. Jetzt kann Liesschen von ihrem PC über LAN
# nicht mehr ihren Router erreichen, da dieser seine IP-Pakete für
# Liesschens PC über das Mesh an Ottos Router schickt.
# Für das Ankündigen eines Internetgateways (0.0.0.0/0) sollte immer
# das dynamische Gateway-Plugin verwendet werden. Sonst hat das Mesh
# bei einem Ausfall des Internetanschlusses immer wieder schwarze Löcher
# in dem Pakete zum Internet verschwinden, ein sehr häufiges Problem.
# Schlägt man diese Warnung in den Wind stehen bald viele ärgerliche
# Netzteilnehmer vor der Tür und beschweren sich...
#
# Mehrere Einträge sind möglich. Syntax: Netzadresse Netzmaske

Hna4
{
# Beispiel für ein Klasse C Netz:
# 10.193.198.0 255.255.255.0
10.134.133.56 255.255.255.255
10.134.133.57 255.255.255.255

#
# Beispiel für eine Host-Route zu einem einzelnen Node:
# 10.140.140.254 255.255.255.255
}
# HNA IPv6 Routen
# Syntax: Netzwerkadresse Prefix
# Beispiel für einen Internet Gateway:

Hna6
{
# Internet Gateway:
# :: 0
# Weitere Einträge:
# fec0:2200:106:: 48
}

# Soll der olsrd auch dann weiterlaufen wenn keine
# Netzwerkkarte zur Verfügung steht?
# Das kann für PCMCIA/USB-Geräte oder andere
# Hotplug-fähige Geräte hilfreich sein.
# "yes" oder "no"
AllowNoInt yes

# TOS (Servicetyp) für den IP-Header
# der Protokollpakete. Der Standardwert
# ist 16 wenn er nicht gesetzt wird.
# TosValue 16

# Die fest eingestellte Bereitschaft für
# andere Knoten Pakete weiterzurouten (0-7)
# Falls nicht angegeben wird der Wert bei
# Geräten mit Stromsparmechanismen (ACPI, APM)
# dynamisch dem Ladezustand / Stromsparmodus
# angepasst, wenn diese Informationen verfügbar sind.
Willingness 7

# IpcConnect: Diese Option erlaubt es einem Olsr-Frontend 
# auf den Daemon zurückzugreifen. Es existiert ein (schlechtes)
# GTK-basiertes Frontend für Linux das mittlerweile in Vergessenheit
# geraten ist.
IpcConnect
{
MaxConnections 1
}

# Soll die Hystesefunktion verwendet werden?
# Die Antwort heisst: Nein. Vorsicht:
# Hysterese wird grundsätzlich verwendet wenn
# dieser Eintrag auskommentiert ist!
UseHysteresis no

# Link Quality Extension (LQ-ETX)
# 0 = wird nicht verwendet
# 1 = wird verwendet um Multipointrelais zu bestimmen
# 2 = wird verwendet um Multipointrelais und Routen
# zu bestimmen. Ist diese Einstellung nicht gesetzt
# wird LQ-ETX nicht verwendet. Das ist keine gute Idee.
# Hier muss 2 stehen.
LinkQualityLevel 2

# Link-Qualität Fenstergröße zur Berechnung von ETX.
# Anzahl der Hello-Pakete für die ETX/LQ-Statistik.
# Nicht zu klein wählen, solange nicht hohe Mobilität
# der Netzwerkknoten berücksichtigt werden muss.
# Je größer die Fenstergröße desto ruhiger und stabiler -
# aber auch träger - reagiert das Netz auf Veränderungen.
LinkQualityWinSize 100

# Pollrate in Sekunden (Fliesskommawert).
# Dieser Wert gibt an wie oft olsrd den Empfangspuffer des
# Betriebssystems nach eingetroffenen Olsr-Nachrichten abfragt.
# Ein häufigeres überprüfen erzeugt eine höhere CPU-Last.
# Allerdings sollte der Wert nicht zu gross eingestellt
# werden, da es sonst bei einem grossen Aufkommen von
# Olsr-Paketen zu Pufferüberläufen im Empfangspuffer des
# Linux-Kernels kommen kann. Der Kernel speichert nur eine
# bestimmte Datenmenge von eingehenden UDP-Paketen.
#
# Werden diese UDP-Pakete nicht rechtzeitig von olsrd abgeholt
# verwirft sie der Kernel bei einem Pufferüberlauf.
# Die Puffergrösse ist im Linuxkernel einstellbar, so dass man
# mit langen Pollintervallen experimentieren kann um die CPU-Last
# zu reduzieren. Es gibt eine Grundeinstellung für die Puffergrösse
# und einen Maximalwert (rmem_default und rmem_max). Der folgende
# - ausserhalb dieser Konfigurationsdatei - auszuführende Befehl
# setzt die Puffergrösse auf 128 Kilobyte, dieses Kommando kann von
# Hand auf der Kommandozeile (in einem Terminal) mit Administrator-
# rechten gesetzt werden:
#
# echo 131072 > /proc/sys/net/core/rmem_default
#
# Gelesen werden kann die Puffergrösse mit dem Befehl:
# cat /proc/sys/net/core/rmem_default
#
# Hat man eine Einstellung gefunden die bei jedem Neustart des
# Betriebssystems gesetzt werden soll, kann man ein Skript anlegen
# welches beim Start des Betriebssystems oder beim Starten von
# Olsrd automatisch ausgeführt wird.
Pollrate 0.05

# Informationen die mit Topologie-Nachrichten versandt werden.
# Hier an der Redundanz zu sparen wirkt sich negativ auf die
# Stabilität aus. Der Maximalwert ist 2 - alle Nachbarn mitteilen.
# Dieser Eintrag muss unbedingt gesetzt werden, sonst wird
# bei fehlendem Eintrag Null verwendet und es gibt keine
# Redundanz.
TcRedundancy 2

# Abdeckung mit Multi-Point-Relais.
# Gibt an wieviele Nachbarn ein Knoten zu Multi-Point-Relais
# bestimmt. Hier wird ein hoher Wert gesetzt, so dass die
# Funktion praktisch alle Nachbarn verwendet. Durch einen Fehler
# im Code kommt es zu Abstürzen wenn ein Wert > 7 gesetzt wird.
# Auch dieser Wert muss unbedingt angegeben sein, sonst wird 1
# verwendet.
MprCoverage 7

# Olsrd-Plugins die geladen werden sollen. Hier muss ein absoluter
# Pfad angegeben werden wenn die Plugins nicht in /lib/ oder
# /usr/lib oder in einem Verzeichnis gespeichert wurden auf das
# die Variable LD_LIBRARY_PATH oder /etc/ld.so.cache verweisen.
# Dokumentationen zu den Plugins finden sich im Sourcecode-Verzeichnis
# des olsrd unter lib/Plugin-name
#
# Ein Beispiel für die Verwendung des dynamischen Gateway-Plugins.
LoadPlugin "olsrd_dyn_gw.so.0.4"
{
# Den Plugins können/müssen mitunter Parameter mitgegeben
# werden.
# Das dynamische Gateway-Plugin prüft durch das Versenden von
# ICMP-Daten (?ping?) Richtung Internet in einem bestimmten
# Intervall ob der Zugang funktioniert.
# Hier wird der Prüf-Intervall angegeben. Wird der Intervall
# nicht definiert geschieht die überprüfung alle 5 Sekunden.
 PlParam "Interval" "40"

# Wenn mehrere IPv4-Adressen angegeben werden werden diese
# in absteigender Reihenfolge per ?ping? getestet. Ist der erste
# Test erfolgreich wird die zweite Adresse nicht geprüft.
# Hier sollte man mehrere Einträge vornehmen, damit nicht
# wegen eines Ausfalls der Gegenstelle der Gateway seine
# Funktion fälschlicherweise einstellt.
 PlParam "Ping" "141.1.1.1"
 PlParam "Ping" "194.25.2.129"
}

LoadPlugin "olsrd_httpinfo.so.0.1"
{
	# Die Portnummer auf der der Webserver arbeitet
    	PlParam     "port"   "8080"

	# In der Grundeinstellung ist nur 127.0.0.1 
     	# (lokale Maschine auf der Olsrd läuft) 
	# der Zugriff auf den Webserver erlaubt. 
	PlParam      "Host"   "127.0.0.1"

        # Weitere Knoten können hinzugefügt werden.
        # PlParam    "Host"    "10.0.0.5"

        # Der Zugriff kann auch für ganze Adressbereiche 
        # gestattet werden. Mehrere Einträge sind erlaubt.

        # PlParam     "Net"     "192.168.1.0 255.255.255.0"

}

LoadPlugin "olsrd_dot_draw.so.0.3"
{
	PlParam "accept" "192.168.100.1"
}

LoadPlugin "olsrd_nameservice.so.0.2"
{
	# Der Name dieses Olsr-Knotens, der dem Mesh mitgeteilt wird:
	PlParam "name" "Name-dieser-Maschine"
	# Lokale Knoten, die über HNA announciert werden:
	PlParam "10.134.133.56" "Sonne"
	PlParam "10.134.133.57" "Mond"
	# DNS-Einträge werden zu dieser Datei hinzugefügt.
	#PlParam "hosts-file" "/etc/hosts"
	# Zusätzliche Datei für DNS-Einträge statt /etc/hosts
	# verwenden. Dadurch wird verhindert, dass die originale
	# Hosts-Datei überschrieben wird und bereits selbst angelegte
	# Einträge verlorengehen.
	#PlParam "add-hosts" "Datei mit Pfadangabe"
	# In diese Datei werden die drei nächstgelegenen DNS-Server	
	# eingetragen, welche den besten ETX-Wert haben.
	PlParam "resolv-file" "/etc/resolv.conf"
	# Jedem DNS-Eintrag von Olsr kann ein Suffix angeh?angt werden.
	# In der Grundeinstellung wird das nicht gemacht.
	# PlParam "suffix" ".olsr"
	# Über diesen Eintrag wird ein ?echter? DNS-Server announciert.
	# Wird der Eintrag leer gelassen ("") wird die IP-Adresse dieses
	# Olsr-Knotens verwendet.
	# PlParam "dns-server" "IP-Adresse des DNS-Servers"
	# Das Intervall in dem DNS-Informationen an andere Olsr-Knoten
	# verschickt werden (in Sekunden). In der Grundeinstellung werden
	# 120 Sekunden verwendet.
	# PlParam "interval" "Anzahl Sekunden"
	# Wie lange sind über das Plugin empfangene DNS-Informationen
	# gültig (in Sekunden). Grundeinstellung 3600 Sekunden (1 Stunde)
	# PlParam "timeout" "3600"
	}


# Interface-Sektion
# Hier werden die Interfaces angegeben auf denen der
# Daemon aktiv wird. Werden Optionen ausgelassen werden
# die Default-Einstellungen verwendet. Mehrere Interfaces
# können zu einem Konfigurationsblock zugeordnet werden. Die
# Konfigurationsparameter sind dann bei jedem Interface
# die gleichen. Sollen Interfaces mit unterschiedlichen
# Parametern arbeiten kann ein neuer Block angegeben werden.
# Als erstes werden die Interfaces angegeben die diesem
# Konfigurationsblock zugeordnet werden.

Interface "eth0" "ath0" "wlan0" "eth2"

{
# Die verwendete IPv4-Broadcast-Adresse. Ein
# sinnvolles Beispiel wäre 255.255.255.255 -
# diese schliesst alle möglichen Netzadressen ein.
# Wird 255.255.255.255 benutzt koennen sich alle Nodes
# auch über Subnetzgrenzen hinweg sehen. Das heisst:
# Verwendet ein Mesh die Netzwerkadresse 10.0.0.0/8
# werden auch Nodes mit einer IP-Adresse ausserhalb
# des Subnetzes (beispielsweise 172.29.200.0/24) über
# Hostrouten geroutet. Das funktioniert jedoch nur
# unter Linux und alle Knoten im Mesh müssen die
# Broadcastadresse 255.255.255.255 verwenden.
# Falls nicht angegeben wird die Broadcast-
# Adresse der Interfaces verwendet.
# Im Normalfall auskommentiert lassen.
# Ip4Broadcast 255.255.255.255

# Verwendeter IPv6-Adressbereich.
# Muss ?site-local? oder ?global? sein
# Ip6AddrType site-local

# IPv6 Multicast Adresse wenn der Adressbereich
# ?site-local? ist. Falls nicht definiert wird
# ff05::15 verwendet
# Ip6MulticastSite ff05::11

# IPv6 Multicast Adresse wenn der Adressbereich
# ?global? ist. Falls nicht definiert wird
# ff0e::1 verwendet
# Ip6MulticastGlobal ff0e::1

# Emissionsintervall für Olsr-Nachrichten
# Falls nicht definiert werden RFC-Werte
# verwendet. Das sollte man sich nicht antun.
# Hello Intervall in Sekunden (Fliesskommawert)
HelloInterval 2.0

# Gültigkeitsdauer der Hello-Nachrichten in Sekunden
HelloValidityTime 200.0

# Topologie-Nachrichten Intervall in Sekunden (Fliesskommawert)
# Falls das Mesh mehr als 100 Knoten hat sollte der Intervall für
# TC-Messages vergrößert werden. Ein TCInterval-Wert von
# 0.5 Sekunden kann nur verwendet werden wenn das Netz sehr
# klein ist oder der Fischaugen-Mechanismus (LinkQualityFishEye)
# aktiviert ist. Andernfalls erstickt das Netz in einer Schwemme
# von Topologie-Nachrichten
TcInterval 0.5

# Gültigkeitsdauer der Topologie-Nachrichten in Sekunden (Fliesskommawert)
TcValidityTime 200.0

# MID-Nachrichten Intervall in Sekunden (Fliesskommawert)
# MID-Nachrichten geben bekannt ob ein Knoten mehrere Interfaces hat
# auf denen Olsrd routet.
MidInterval 5.0

# Gültigkeitsdauer von MID-Nachrichten in Sekunden (Fliesskommawert)
# Es schadet in keiner Weise hier einen sehr hohen Wert anzugeben.
MidValidityTime 200.0

# HNA-Nachrichten-Intervall in Sekunden (Fliesskommawert)
HnaInterval 5.0

# Gültigkeitsdauer von HNA-Nachrichten in Sekunden (Fliesskommawert)
# Darf ruhig sehr lange sein damit ein Gateway nicht wegen Paketloss
# aus der Routingtabelle fällt.
HnaValidityTime 200.0

# Soll eine bestimmte Route manuell bevorzugt oder ignoriert werden können
# hier ETX-Link-Quality-Werte über einen Multiplikator beeinflusst
# werden. In diesem Beispiel würde die Route über 192.168.0.1 schlechter
# erscheinen als sie ist. Durch das Multiplizieren mit dem Faktor 0.5 wird
# der LinkQuality-Wert klein (schlecht) und der ETX-Wert entsprechend hoch.
# LinkQualityMult 192.168.0.1 0.5

# Auch der umgekehrte Weg ist möglich. Hier werden alle Linkstrecken um den
# Faktor 0.7 schlechter gerechnet. Dafür werden zwei bestimmte Routen besser
# gestellt.
# LinkQualityMult default 0.7
# LinkQualityMult 10.143.143.143 1.0
# LinkQualityMult 10.143.143.144 1.0
}

# An dieser Stelle ist nun eine gültige Konfigurationsdatei abgeschlossen.
# Falls weitere Interfaces mit abweichenden Parametern konfiguriert werden
# sollen können weitere Interface-Blöcke hinzugefügt werden.
# Beliebt ist die Kopplung von isolierten kleineren Olsr-Netzen über einen
# Internet-Tunnel, aber auch als Backbone innerhalb eines stadtweiten Netzes
# ist ein Tunnel interessant. Auf dem Tunnel-Interface kann Olsrd sehr langsam
# und bandbreitenschonend konfiguriert werden.

Interface "tun0"
{
HelloInterval 50.0
HelloValidityTime 2000.0
TcInterval 50.0
TcValidityTime 2000.0
MidInterval 50.0
MidValidityTime 1000.0
HnaInterval 50.0
HnaValidityTime 1000.0
}