[Wien] Tunnel wieder verfügbar

[Alexander Stadler]

Ich verwende ohnehin schon immer:

up-delay

und

keepalive 10 60

was das selbe ist wie:

if mode server:
  ping 10
  ping-restart 120
  push "ping 10"
  push "ping-restart 60"
else
  ping 10
  ping-restart 60

Wahrscheinlich hatte ich daher das Problem nicht.
Allerdings verwendete ich es in Kombination mit persist-tun, wodurch das 
Interface nicht down geht, und ich nicht weiß ob das Problem am Tunnel 
Server dann nicht weiterhin auftreten würde.
Jedenfalls muß ich daher nichts umkonfigurieren. Und ja, bitte füge 
meiner Config am Server

up-delay
keepalive 10 60

hinzu (da so die gleichen Werte auf beiden Enden ja ideal sein sollten).

lg

Alex


Markus Kittenberger schrieb:
> hmm erste versuche sehen gut aus, das so die olsr-tunnel stabil laufen,..
>
> ja alex keep-alive bringt was,..
>
> zumindest in verbindung mit delay-up, welches das interface erst up 
> nimmt wenns wirklich up ist,..
> denn sonst ist der olsr evt. schon taubstumm geworden bevor der tunnel 
> überhaupt je geht,..
>
> soll ich deinen tunnel tetweise auch umkonfigurieren?
> gibts weitere openvpn oder auch vtun testwillige?
>
> dein openvpn client sollt evt. pings machen, oder sich daruaf 
> verlassen das olsr eh genug traffic macht, (und das tut es (-;)
>
> (denn openvpn pings werden nicht beantwortet, d.h. der gegüber muss 
> sie machen,..)
>
> am server hab ich bei meinem tunnel das dazukonfiguriert,..
>
> delay-up
> ping-restart 20
> #ping 6
>
> sollte auch beim client nützlich sein, aber den kann tunnelowner im 
> problemfall eh leichter selber restarten, .. und unter openwrt ist mir 
> die olsr+openvpn probleme auch nie so aufgefallen wie am tunnelserver, 
> aber am tunnelserver gibts auch einfach mehr tunnel die ausfallen 
> können,..
>
> lg Markus
>
> On 7/14/08, *Markus Kittenberger* <(spam-protected) 
> <mailto:(spam-protected)>> wrote:
>
>     wenn es überhaupt auswirkungen hat dann negative,..
>
>     es ist für olsr besser wenn das interface ordentlich down geht,..
>     es kriegt dann mit wenn es weider up kommt, und alles ist gut,..
>
>     aber mit den interfaces vom openvpn die up sind, obwohl nicht
>     verbunden kann olsr nicht umgehen, bzw. das bringt einen olsr bug
>     regelmässig zum vorschein,..
>
>     ich hab aber keine lust diesbezgl. olsr zu debuggem , vorallem da
>     mit vtun das problem weg ist, und vtun auch sonst besser ist bzw
>     mir besser gefällt,..
>
>
>     lg Markus
>
>     On 7/14/08, *Alexander Stadler* <(spam-protected)
>     <mailto:(spam-protected)>> wrote:
>
>         Verstehe.
>         Keepalive, welches die Verbindung neu startet wenn länger
>         nichts los ist,
>         hilft dem Olsrd da auch nicht?
>         Habe das Problem zum dem Node der mit OpenVpn an mir
>         angebunden ist,
>         glaube ich nämlich noch nicht beobachtet. Aber vielleicht blos
>         weil da
>         dann nicht genug debugged sondern einfach neu gestartet wurde.
>
>         lg
>
>         Alex
>
>         ---
>         #on server, to don't start clocking timeouts until a remote
>         peer connects
>         #ping-timer-rem
>         keepalive 10 60
>         #=
>         #if mode server:
>         #  ping 10
>         #  ping-restart 120
>         #  push "ping 10"
>         #  push "ping-restart 60"
>         #else
>         #  ping 10
>         #  ping-restart 60
>         ---
>
>
>         > nunja openvpn und olsr vertragen sich am tunnelserver genauso
>         schlecht
>         > wie am roofnode (-;
>         >
>         > denn olsr wird irgendwann taubstumm wenn auf einem tap
>         interface schon
>         > lang nix los war,..
>         >
>         > die vtun tunnel sind da besser, weil vtun die taps down
>         nimmt, wenn der
>         > tunnel nicht verbunden ist,..
>         >
>         > insofern werd ich wohl mittelfristig openvpn eh abschaffen,..
>         >
>         > lg Markus
>         >
>         > On 7/14/08, Alexander Stadler <(spam-protected)
>         <mailto:(spam-protected)>> wrote:
>         >>
>         >> Danke, connection (tap-interface) ist nun da, aber es werden
>         noch
>         >> keine Daten auf ihm empfangen (gesendet jedoch schon).
>
>
>
>
>
> ------------------------------------------------------------------------
>
> --
> Wien mailing list
> (spam-protected)
> http://lists.funkfeuer.at/mailman/listinfo/wien