olsrd_dyn_gw.so.0.5 funktioniert glaub ich nicht wirklich

[Tom Green]

Hi,

Vergesst die E-Mail unten .. zu früh am morgen.

Also:

  * Wäre schön das mit olsr Hausmitteln in den Griff zu bekommen. Also
    nicht den workaround zum Plugin bauen.
  * Wenn jemand gute Doku-Quellen zum Thema olsr/olsr2 hat .. bitte posten.
  * 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.

Gruß
Torben

On 09.10.2015 06:38, Tom Green wrote:
> 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:
>> 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

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20151009/e2d9ea24/attachment-0002.html>