<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi,<br>
<br>
Vergesst die E-Mail unten .. zu früh am morgen.<br>
<br>
Also: <br>
<ul>
<li>Wäre schön das mit olsr Hausmitteln in den Griff zu bekommen.
Also nicht den workaround zum Plugin bauen.<br>
</li>
<li>Wenn jemand gute Doku-Quellen zum Thema olsr/olsr2 hat ..
bitte posten.</li>
<li>Momentan sieht es so aus, als kann man an olsr2 nix
einstellen, keine Routingtables, keine plugins. Weiß da jemand
mehr? Muss (oder sollte) doch irgendwo eine Übersicht über die
Konfigurationsparameter geben. <br>
</li>
</ul>
Gruß <br>
Torben<br>
<br>
<div class="moz-cite-prefix">On 09.10.2015 06:38, Tom Green wrote:<br>
</div>
<blockquote cite="mid:561744AA.50506@gmx.de" type="cite">
<pre wrap="">Hi,
ja. zumindest haben wir jetzt eine Diagnose dafür, wieso die Standard
Route nie gelöscht wird, obwohl ausgefallen. Ich glaube auch nicht, dass
sie, wenn der Tunnel zurück käme, wieder aufgebaut wird, schließlich
wäre das ping ja dann über die Alternativroute erfolgreich.
Von der "dirty-by-majo" Lösung halte ich erst mal wenig. Schließlich ist
es Funktionalität, die wir ganz klar vom olsr erwarten und die es auch
liefern können sollte.
ich stimme leider zu, dass die Doku vom olsr sehr spartanisch gehalten
ist, da ist das conf-file schon das höchste der Gefühle. Auch das macht
es nicht einfacher.
Olsr2 ist noch dünner dokumentiert. Jedenfalls habe ich es gebaut, aber
bis dato keine Doku gefunden mit dem wir ansatzweise unsere
Konfiguration umsetzen könnten.
Vom 1er-olsr gibt es dann noch die Version 0.9, wir setzen 0.6 ein. Ich
versuch mal aus dem Change-Log schlau zu werden (wenn es eins gibt).
Vielleicht schaue bei der Doku auch nur an die falschen Stelle.
Jedenfalls macht es für mich keinen Sinn etwas einzusetzen, was vom
olsr-Maintainer im Stile einer Geheimwissenschaft betrieben wird. Da
kann es technisch so gut sein wie es will.
Gruß
Torben
On 09.10.2015 03:59, Christian Dresel wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hallo
Laut Gatewayanleitung (und auch die wenigen Dokus die ich im Netz so
gefunden habe) soll in der olsrd.conf der Abschnitt:
---
LoadPlugin "olsrd_dyn_gw.so.0.5"
{
# Here parameters are set to be sent to the
# plugin. Theese are on the form "key" "value".
# Parameters ofcause, differs from plugin to plugin.
# Consult the documentation of your plugin for details.
# Example: dyn_gw params
# how often to check for Internet connectivity
# defaults to 5 secs
PlParam "Interval" "5"
# if one or more IPv4 addresses are given, do a ping on these in
# descending order to validate that there is not only an entry in
# routing table, but also a real internet connection. If any of
# these addresses could be pinged successfully, the test was
# succesful, i.e. if the ping on the 1st address was successful,the
# 2nd won't be pinged
PlParam "Ping" "8.8.8.8"
PlParam "Ping" "82.165.230.17"
PlParam "pingcmd" "ping -c 1 -q -I tun0 %s"
}
---
dafür sorgen, dass der Announce 0.0.0.0/0 gelöscht wird, sobald kein Ping
mehr über tun0 raus geht (also wenn der if down ist oder einfach der
VPN nicht mehr erreichbar ist). Zumindest
verstehe ich das ganze so. Ich erinner mich aber irgendwo ein Gespräch
mitgehört zu haben, das dies nicht wirklich
funktioniert.
Nach vielen versuchen und anschalten des debugmodus vermute ich mal,
dass das ganze wirklich nicht funktioniert.
Es sieht so aus als würde er das komplette pingcmd ignorieren und
einfach direkt die erste IP pingen, da
dies dann über das normale eth0 läuft gelingt der Ping natürlich auch
bei geschlossenen tun0 was für meine Zwecke ziemlich
doof ist da dann 0.0.0.0/0 praktisch immer announced wird.
Hier mal teile der Debugausgabe (tun0 war zu dem Zeitpunkt aus):
Sending parameters...
"Ping"/"82.165.230.17"... Ping: OK
"Ping"/"8.8.8.8"... Ping: OK
"pingcmd"/"ping -c 1 -q -I tun0 %s"... Ignored parameter "pingcmd"
Running plugin_init function...
.....
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
--- 8.8.8.8 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.384/1.384/1.384/0.000 ms
...OK
dreckige Lösung ( (c) Mayosemmel) wäre nun, mit eigenen Script testen
ob ein Ping durch den Tunnel gelingt, wenn eine Änderung (von off nach
on oder von on nach off) dann die conf austauschen
(olsrd_dyn_gw.so.0.5 komplett deaktivieren, in einer conf wird
0.0.0.0/0 manuell announced die wird genommen wenn der Tunnel läuft,
die andere ohne 0.0.0.0/0 wird genommen wenn Tunnel offline) und olsr
neu starten. Jemand eine bessere Idee zur Hand oder am besten eine
Lösung damit olsrd_dyn_gw.so.0.5 so läuft wie wir/ich es brauchen
Zusatz: Ich grübel grad noch obs nicht möglich ist (irgend)eine IP nur
noch über tun0 erreichbar zu machen und diese zum pingen dann
verwenden? Das ist dann vielleicht nicht mehr ganz so dreckig ( (c)
mayo und sooo)...
mfg
Christian
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
</body>
</html>