openvpn: "Assertion failed at multi.c:1561 -> Exitin

[tapferesschneiderlein]

Hallo, Forum,

schon zum dritten mal innerhalb weniger Tage hat sich eine
OpenVPN-Server-Instanz mit der Meldung "Assertion failed at multi.c:1561 ->
Exiting" beendet.

Die entspechende Stelle in der Funktion multi_process_incoming_link() im
Debian-Quellcode unterscheidet sich von der (aktuellen) von OpenVPN:

Code: Alles auswählen

--- multi.c.orig       2005-11-05 08:04:22.000000000 +0100
+++ multi.c.debian        2007-02-19 10:22:07.000000000 +0100
#[...]
@@ -1584,8 +1558,7 @@ multi_process_incoming_link (struct mult
   struct multi_instance *mi;
   bool ret = true;

-  if (m->pending)
-    return true;
+  ASSERT (!m->pending);

   if (!instance)
     {

Eine ähnliche Änderung gibt es auch kurz danach in
multi_process_incoming_tun():

Code: Alles auswählen

@@ -1739,8 +1712,7 @@ multi_process_incoming_tun (struct multi
       printf ("TUN -> TCP/UDP [%d]\n", BLEN (&m->top.c2.buf));
 #endif

-      if (m->pending)
- return true;
+      ASSERT (!m->pending);

       /*
        * Route an incoming tun/tap packet to

Kann damit jemand was anfangen

Daniel

[gms]

wurde in der upstream version geändert:
http://openvpn.net/archive/openvpn-deve ... 00063.html

Gruß
gms

[tapferesschneiderlein]

wurde in der upstream version geändert:

Aah, danke. Warum wurde das nicht als Sicherheitsupdate in Debian integriert? Wer entscheidet sowas?

[gms]

Warum wurde das nicht als Sicherheitsupdate in Debian integriert? Wer entscheidet sowas?

in die Debianversion von Sarge wurden einige Sicherheitspatches eingespielt und damit 3 Sicherheitsupdates erzeugt.
Dieser Patch ist nicht dabei, weil dieser Bug kein Sicherheitsproblem darstellt

[tapferesschneiderlein]

Dieser Patch ist nicht dabei, weil dieser Bug kein Sicherheitsproblem darstellt

Mmh, aber dieser Showstopper-Bug rüttelt aber schon ziemlich am Image eines *stabilen* OS, oder?

Wie sähe denn eine Interimslösung aus, mit dem man die Ausfallzeit auf minimal reduzieren kann? Irgendwas, was den ovpn-Prozess überwacht und ggf. neustartet. Wie geht sowas elegant?

[gms]

Mmh, aber dieser Showstopper-Bug rüttelt aber schon ziemlich am Image eines *stabilen* OS, oder?

subjektiv gesehen ja
objektiv gesehen, wurde dieser Bug für Debian noch nicht eingemeldet
( habe die Bugs jetzt nur überflogen, zumindest auf den ersten Blick ist er nicht dabei )

Wie sähe denn eine Interimslösung aus, mit dem man die Ausfallzeit auf minimal reduzieren kann? Irgendwas, was den ovpn-Prozess überwacht und ggf. neustartet. Wie geht sowas elegant?

vielleicht kannst die aktuelle OpenVPN Version selber kompilieren, oder auf Etch upgraden ?
möglicherweise gibts auch einen Backport von OpenVPN
nachdem der Bug ziemlich selten aufteten dürfte, liegt es wahrscheinlich an irgendeiner Konstellation. Vielleicht läßt sich dieser herausfinden.
Ansonsten, wenn du mit deinem Lösungsvorschlag bis zur Etch Release (oder bis zu einer endgültigen Lösung) leben könntest, wäre ein Cron-Prozeß schnell geschrieben, der regelmäßig den Openvpn Prozeß restartet, wenn diese abgeschossen wurde.


Gruß
gms