• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[gelöst] Kein Start des iked (Shrew-VPN)

/dev/null

Moderator
Teammitglied
Hallo Freunde,

Nachdem ich seit vielen Jahren den Shrew-Client (ike) auf mehreren Clients und unter mehreren openSUSE-Versionen seit 12.x ohne Probleme nutze, tritt jetzt beim Start des iked auf meinem neuen TUXEDO-Notebook der folgende Fehler auf (auch bei normalem Aufruf von iked als root):

Code:
tuxedo:~ # /home/peter/bin/iked.init start
redirecting to systemctl start .service
Starting IKED iked: pthread_mutex_unlock.c:87: __pthread_mutex_unlock_usercnt: Assertion `type == PTHREAD_MUTEX_ERRORCHECK_NP' failed.
startproc:  signal catched /usr/sbin/iked: Aborted
                                                                                                                   failed
tuxedo:~ #

Auf allen drei Rechnern das gleiche Betriebssystem, "tagfertig" aktualisiert:
Code:
tuxedo:~ # uname -a
Linux tuxedo.antonius 3.11.10-21-desktop #1 SMP PREEMPT Mon Jul 21 15:28:46 UTC 2014 (9a9565d) x86_64 x86_64 x86_64 GNU/Linux
tuxedo:~ #
Auf allen drei Rechnern die gleiche aktuelle ike-Version (2.2.1) aus dem Security-Repo von openSUSE.
Meine eigenen Versuche des Compilierens nach der Anleitung von Shrew schlugen ebenfalls fehl. Gleiche Fehlermeldung.

Hat jemand eine Idee? Mich wundert vor allem, dass es auf dem Desktop-Rechner funktioniert.
Die Suchmaschine meines Vertrauens (wirklich?) kennt die Fehlermeldung auch, aber eine richtige und vor allem helfende Antwort habe ich dort auch nicht gefunden.

MfG Peter
 

spoensche

Moderator
Teammitglied
Wenn du ein Multithreaded Programm hast und die Threads alle Zugriff auf eine Variable, zwecks Wertänderung, haben muss die Variable für den Zeitraum gesperrt werden in dem ein Thread schreibend auf diese zugreift. Das wird über einen Mutex realisiert.

Auf deinem Notebook läuft beim unlock des Mutexes beim start des IKE irgendetwas aus dem Ruder. Genauer gesagt sieht es so aus als würde ein Thread in einen Deadlock laufen.

Ursache könnte eine fehlende Ausnahmebehandlung, ein Bug im Shrew Client oder aber ein Bug in der libpthread sein. Ich vermute das es am Schrew Client liegt.
 
OP
/dev/null

/dev/null

Moderator
Teammitglied
Vielen Dank für deine Antwort. Wieder was gelernt ... .
Der erste und der zweite Absatz sind mir nach deinen Erklärungen jetzt einigermaßen verständlich. Nur mit dem dritten, also den Ursachen, weiß ich noch nicht so recht umzugehen.
- auf beiden Rechnern (siehe unten) läuft das identische Betriebssystem (beide gerade geupdated, gleicher Kernel, gleiche Version der libpthread.
- auf beiden Rechnern wurde die identische Installationsdatei vom ike verwendet.

Ich habe auch intensiv in der Mailingliste des Herstellers gesucht, die Fehlermeldung taucht dort mehrfach auf, aber Lösungen habe ich leider keine gefunden.
Jetzt habe ich erst einmal die VPN-Serverkonfiguration (Fritz!Box 7490) so umgeschrieben, dass ich mit vpnc arbeiten kann. Schaun mer mal ... .


MfG Peter
 

spoensche

Moderator
Teammitglied
/dev/null schrieb:
- auf beiden Rechnern (siehe unten) läuft das identische Betriebssystem (beide gerade geupdated, gleicher Kernel, gleiche Version der libpthread.
- auf beiden Rechnern wurde die identische Installationsdatei vom ike verwendet.

Das "juckt" den fiesen Bug herzlich wenig, leider. Das ist ja gerade mitunter das Interessante an den "Mistviechern".
OS ist gleich, sollte also damit vorerst ausgeschlossen werden können. Ok, was bleibt dann noch? Andere Hardware. Ok aber was zum Henker hat die Hardware damit am Hut?? usw. usw. usw.

Allerdings kann es manchmal auch höchstgradig nervtötend sein. :)

/dev/null schrieb:
Ich habe auch intensiv in der Mailingliste des Herstellers gesucht, die Fehlermeldung taucht dort mehrfach auf, aber Lösungen habe ich leider keine gefunden.
Jetzt habe ich erst einmal die VPN-Serverkonfiguration (Fritz!Box 7490) so umgeschrieben, dass ich mit vpnc arbeiten kann. Schaun mer mal ... .

Hm, dann scheint dem Shrew da etwas quer zu hängen.
Du hast jetzt quasi zwei Möglichkeiten.
Entweder du rückst dem Bug mittels GDB direkt mit Vollgas auf die Pelle oder aber verwendest erst den Schongang in Form von strace. ;)
 
OP
/dev/null

/dev/null

Moderator
Teammitglied
Mittlerweile habe ich mich ganz zaghaft mit vpnc (Bestandteil des Plasmoid-Networkmanager) angefreundet.
Klar funktioniert dieses Teil auch, allerdings ist das mit viel Bastelei verbunden. Mit den für Shrew angepassten Konfigurationen kommt vpnc nicht zurecht. Ist eben auf Cisco ausgerichtet.
Ich habe seit mehreren Jahren sieben verschiedene VPN-Verbindungen in meinen diversen Fritz!Boxen fest implementiert. Für unsere drei (weit entfernt stationierten) Schlau-Fernsprechapparate, zum Telefonieren über VPN und auch, um unsere heimischen Rufnummer überall hin mitzunehmen. Zum Glück sind diese drei Konfigurationen nicht betroffen.

Und dann hatte ich noch zwei Konfigurationen, mit denen ich mein Notebook via UMTS nur ins heimische LAN bringen (Internet direkt über den UMTS-Router) bzw. den gesamten Traffic übers VPN routen konnte (Hotspot-Betrieb). Dazu kommen noch eine Test-Konfiguration mit Mini-Schlüssel und eine Verbindung ins LAN meines Sohnes (der hier auch mitliest ...).

Dass die im vpnc hinterlegte Konfiguration "nur" mit xauth arbeitet, finde ich ja sehr gut (noch ein Benutzername und ein eigenes PW). Aber ich habe es noch nicht geschafft, auf dem VPN-Server PFS einzuschalten. Bei Shrew war das selbstverständlich aktiviert.

Nun ja, wenn man keine (Hobby-)Arbeit hat, macht man sich welche. Und ich muss mich mal wieder so richtig mit IPsec befassen.


MfG Peter
 

spoensche

Moderator
Teammitglied
/dev/null schrieb:
Mittlerweile habe ich mich ganz zaghaft mit vpnc (Bestandteil des Plasmoid-Networkmanager) angefreundet.
Klar funktioniert dieses Teil auch, allerdings ist das mit viel Bastelei verbunden. Mit den für Shrew angepassten Konfigurationen kommt vpnc nicht zurecht. Ist eben auf Cisco ausgerichtet.
Ich habe seit mehreren Jahren sieben verschiedene VPN-Verbindungen in meinen diversen Fritz!Boxen fest implementiert. Für unsere drei (weit entfernt stationierten) Schlau-Fernsprechapparate, zum Telefonieren über VPN und auch, um unsere heimischen Rufnummer überall hin mitzunehmen. Zum Glück sind diese drei Konfigurationen nicht betroffen.

Und dann hatte ich noch zwei Konfigurationen, mit denen ich mein Notebook via UMTS nur ins heimische LAN bringen (Internet direkt über den UMTS-Router) bzw. den gesamten Traffic übers VPN routen konnte (Hotspot-Betrieb). Dazu kommen noch eine Test-Konfiguration mit Mini-Schlüssel und eine Verbindung ins LAN meines Sohnes (der hier auch mitliest ...).t

Ich taufe es auf den Namen HosentaschenLAN. ;) Nach dem lesen kann ich mir gut vorstellen, dass bei dem Wort Bastelei deine Augen am funkeln sind, :)
Der Administrationsaufwand ist allerdings nicht ohne und bringt einiges an Komplexität mit sich. Du könntest die komplexität möglicherweise durch VLAN's verringern und mittels Radius sicherstellen, dass nur bekannte Clients im Netz sind. Mit dem Radius käme auch der Bastelfaktor nicht zu kurz. ;)

Ich habe mir vor kurzem einen lüfterlosen voll managebaren 24 Port Switch für rund 125 € inkl. Versandkosten zugelegt.

/dev/null schrieb:
Dass die im vpnc hinterlegte Konfiguration "nur" mit xauth arbeitet, finde ich ja sehr gut (noch ein Benutzername und ein eigenes PW). Aber ich habe es noch nicht geschafft, auf dem VPN-Server PFS einzuschalten. Bei Shrew war das selbstverständlich aktiviert.

Ich bevorzuge eher die zertifikatsbasierte Authentifizierung. Einen naja quasi Benutzernamen hat man dabei auch.

/dev/null schrieb:
Nun ja, wenn man keine (Hobby-)Arbeit hat, macht man sich welche.
Das würde ich so nicht sagen. Berufung eben.
 
OP
/dev/null

/dev/null

Moderator
Teammitglied
Nun, es hat halt jeder so seine Hobbies ... . Um mehr geht es hier auch nicht.
Auf jeden Fall versuche ich alles zu unternehmen, dass die Daten zwischen meinen "Standorten" nicht unverschlüsselt übertragen werden. Hier färbt wohl auch ein klein wenig mein Job ab.

Ich bevorzuge eher die zertifikatsbasierte Authentifizierung. Einen naja quasi Benutzernamen hat man dabei auch.
Bei mir läuft sonst so gut wie nichts ohne Zertifikate. Ich befasse mich täglich ~ 8 Std. mit diesem Thema - und eben an manchen Tagen auch noch ein klein wenig privat nach Feierabend ... . Nur so viel dazu.
Nur leider ist das mit X.509 bei den Fritz!Boxen nicht möglich. Ich habe bei der händischen Erstellung meiner Serverkonfiguration (nein, nicht über die AVM-GUI!) alle Optionen ausprobiert, um dem Server Zertifikate schmackhaft zu machen. Nix ist, der Server will nur PSK. Entweder ist er wirklich eine AVM-Eigenentwicklung, oder sie haben das rausgepatcht. Zum gleichen Ergebnis kam übrigens auch der Entwickler der Android-App "VPNCilla", welche ich auf den Smartphones nutze.
Ja, Zertifikate hätte ich gerne genommen.

Jetzt läuft immerhin schon das VPN zwischen meinem neuen TUXEDO und der Fritte auf Knopfdruck Allerdings wird immer noch der gesamte Traffic (außer DNS) übers VPN geroutet, also LAN-only funktioniert noch nicht. Da muss ich noch ein wenig am Routing feilen. Es ist halt d**f, dass bei jedem Einspielen einer neuen cfg per VPN in die Box die Verbindung heruntergerissen wird, ich auf der Fritte angemeldet bleibe und eine halbe Stunde warten muss, bis sie mich wieder reinlässt. Ist halt nur eine Fritte und keine SINA-Box.

Wie sagte mein Sohn heute sinngemäß am Telefon: Wenn du alles hinbekommen hast, kommt openSUSE 13.2 (oder ein neuer Shrew), und alles funktioniert wieder wie gewohnt ;)


MfG Peter
verbunden mit lieben Grüßen nach Leipzig!
 
OP
/dev/null

/dev/null

Moderator
Teammitglied
Wenn du alles hinbekommen hast, kommt openSUSE 13.2 (oder ein neuer Shrew), und alles funktioniert wieder wie gewohnt ;)

Ja, schön wäre es gewesen.
Heute 13.2 installiert.
Wie immer eine komplette Neuinstallation (Kernel 3.17), alles neu, alles "besser" - nur der beschriebene Fehler hat auch das überlebt.
Auf zwei Rechnern funktioniert es, auf dem Tuxedo eben nicht.

Macht nix, bald kommt 13.3 oder ein neuer Schrew ... :D


MfG Peter
Wie immer mit lieben Grüßen nach Leipzig ...
 
OP
/dev/null

/dev/null

Moderator
Teammitglied
Hinweis:

Ich habe die gleiche Frage auch mal >> hier << gestellt.

Vor ein paar Tagen hat das hauseigene TUXEDO-Script auf den Kernel 3.18 aktualisiert. Es funktioniert alles - nur eben der iked nicht.
Nichts gegen den Plasmoid Networkmanager und die Möglichkeit dort mit VPNC eine Verbindung anzulegen. Klar funktioniert es auch damit - aber kein Vergleich mit dem Shrew-Client!

BTW: Eine hier nicht namentlich zu nennende Firma ... hat zwar bei Konfiguration und Bestellabwicklung usw. superschnell auf meine Mails reagiert. Aber alle meine Anfragen hinsichtlich dieses Problems bleiben wohl irgendwo im firmeneigenen Spamfilter hängen. Schade eigentlich!

MfG Peter

edit: Da hätte ich doch fast die lieben Grüße nach Leipzig vergessen ;-)
 
OP
/dev/null

/dev/null

Moderator
Teammitglied
Da auch bei Linuxforen.de meine Frage keinerlei Echo bekam, habe ich es jetzt auch noch mal bei Ubuntuusers.de versucht.
Als nächstes werde ich wohl mal nach den E-Mailadressen von Michael Kofler (im "Kofler 2014" steht "Mutex" als Schlagwort nicht drin) und vlt. auch Linus Torvalds fragen. ;-)

MfG Peter
Und wieder die lieben Grüße nach Leipzig!
 
OP
/dev/null

/dev/null

Moderator
Teammitglied
Vielleicht hat auch nur meine "Drohung", Michael K. oder gar Linus T. zu fragen, gewirkt ;-)

Gerade eben bekam mein TUXEDO ein Update angeboten:
Unter anderem:
Code:
tuxedo:~ # uname -a
Linux tuxedo 3.18.2-2.g88366a3-desktop #1 SMP PREEMPT Wed Jan 14 19:16:14 UTC 2015 (88366a3) x86_64 x86_64 x86_64 GNU/Linux
tuxedo:~ #

Und wie immer gleich getestet, und heute folgendes Ergebnis:
Code:
tuxedo:~ # iked
ii : created ike socket 0.0.0.0:500
ii : created natt socket 0.0.0.0:4500
## : IKE Daemon, ver 2.2.1
## : Copyright 2013 Shrew Soft Inc.
## : This product linked OpenSSL 1.0.1j-fips 15 Oct 2014
tuxedo:~ #

Alles wird gut ...


MfG Peter
 
Oben