OpenVPN external startet nicht/Link in /usr/sbin fehlt/race condition in mksquashfs?

[DSLFritze]

Hallo,

ich habe OpenVPN als external kompiliert. Obwohl uStor01/external/openvpn vorhanden und ausführbar ist, erschien OpenVPN jedoch nicht unter den Diensten im Freetz GUI.

Nach Lektüre von http://www.ip-phone-forum.de/showthread.php?t=217937 gab ich

/etc # sh -x /etc/init.d/rc.openvpn load

ein, womit OpenVPN dann im GUI vorhanden war. Ich konnen den Dienst ohne Fehlermeldung starten, allerdings war danach kein OpenVPN Prozess vorhanden. Also suchte ich nach dem Binary:

/var/mod/root # which openvpn
/usr/sbin/openvpn
/var/mod/root # ls -l /usr/sbin/openvpn
-rwxrwxrwx    1 root     root             0 Aug 10 10:34 /usr/sbin/openvpn
/var/mod/root #

Eigentlich hatte ich einen Link wie bei früheren Installationen erwartet:

/var/mod/root # ls -l /usr/sbin/openvpn
lrwxrwxrwx    1 root     root           39 Aug  4 21:16 /usr/sbin/openvpn -> /var/media/ftp/uStor01/external/openvpn
/var/mod/root #

Manuell lies sich OpenVPN dann auch erfolgreich starten und betreiben:

/var/mod/root # /var/media/ftp/uStor01/external/openvpn /var/tmp/flash/openvpn.conf

Vermutlich wird wirklich nur der Link nicht angelegt. Soll ich ein Ticket hierfür aufmachen oder habe ich irgendeine Finesse des Startmechanismus übersehen?

Grüsse,
DSLFritze

 

[RalfFriedl]

Den Fehler gab es schon mal, allerdings sollte er mittlerweile behoben sein.

Schau Dir mal die Protokolle vom Packen der Firmware an, und natürlich das Dateisystem in build/modified.

 

[DSLFritze]

Im Dateisystem unter build/modified ist der Link vorhanden:

freetz@freetz-linux:~/freetz-trunk$ ls -l build/modified/filesystem/usr/sbin/openvpn*
lrwxrwxrwx 1 freetz freetz 39 2010-08-10 10:34 build/modified/filesystem/usr/sbin/openvpn -> /var/media/ftp/uStor01/external/openvpn
freetz@freetz-linux:~/freetz-trunk$

Im Protokoll build/modified/filesystem.log wird er mit einer Länge von 39 Bytes wohl erstmal auch korrekt erkannt:

...
mksquashfs: file build/modified/filesystem/usr/sbin/openvpn, uncompressed size 39 bytes
...

allerdings tritt dann später folgender Fehler auf:

...
mksquashfs: file build/modified/filesystem/usr/mww/cgi-bin/status.d/00-password.sh, uncompressed size 236 bytes
mksquashfs: file build/modified/filesystem/usr/mww/cgi-bin/Failed to read file build/modified/filesystem/usr/sbin/openvpn, creating empty file
status.d/10-box.sh, uncompressed size 1041 bytes
mksquashfs: file build/modified/filesystem/usr/mww/cgi-bin/status.d/20-memory.sh, uncompressed size 1301 bytes
...

 

[RalfFriedl]

Das hatten wir schon mal, ich weiß aber nicht mehr sicher, woran es lag. Entweder am mksquashfs, am Host-System oder an der Kombination aus beiden.

 

[DSLFritze]

Build-Umgebung war freetz-linux-1.1.1.2cpu1gb

Laut build/modified/filesystem.log lief mksquashfs auf 2 CPUs parallel:

rootdir=build/modified/filesystem
table='/home/freetz/freetz-trunk/./tools/device_table.txt'
TIOCGWINZ ioctl failed, defaulting to 80 columns
Parallel mksquashfs: Using 2 processors
Creating little endian 3.76 filesystem on /home/freetz/freetz-trunk/./build/modified/kernel/kernelsquashfs.raw, block size 65536.
mksquashfs: symbolic link addgroup inode 0x0
...

Die Fehlermeldung Failed to read file build/modified/filesystem/usr/sbin/openvpn, creating empty file ist im Logfile irgendwo zwischen ganz anderen Ausgaben gelandet, so dass der Gedanke naheliegt, dass dies vielleicht durch eine Build-Umgebung mit Parallel-Modus verursacht wurde. Natürlich hätte dieser Fehler zum Abbruch führen müssen, aber das Firmware-Image wurde ohne Fehlermeldung erzeugt, so dass ich erst beim Betrieb der Firmware auf den Defekt aufmerksam wurde.

Bei einem erneuten Build-Versuch mit identischer Umgebung und identischer .config wurde das Image mit korrektem Link /usr/sbin/openvpn erzeugt.

 

[olistudent]

Bei fwmod handelt es sich um ein Shell-Script, das eigentlich nicht parallel sondern sequenziell abgearbeitet wird. Kann da sowas wirklich vorkommen?

MfG Oliver

 

[DSLFritze]

race condition in mksquashfs?

Vielleicht ist es das hier beschriebene Problem:

http://old.nabble.com/race-condition-in-mksquashfs--td24504890.html

Mostly this works fine, but on a quad core I sometimes see what to me looks like a race condition.

It looks like there's a rare race condition here. The
queue_put()/queue_get() sequence ensures all queued blocks to the
writer thread have been sent to disk, but it doesn't prevent further
requests being sent to the writer thread afterwards.
...
I have attached a fixed mksquashfs.c, this should replace the
mksquashfs.c in the squashfs 4.0 tools release. Please test.

Ist die squashfs 4.0 tools release schon in der Toolchain enthalten? Im Logfile ist die Versionsnummer leider nicht zu erkennen.

 

[RalfFriedl]

Parallel läuft mksquashfs, nicht fwmod.

Wenn ich mich richtig erinnere, hatten wir genau dieses Problem schon, ich habe aber keinen Patch dafür im Trunk gefunden.

[POST=1545055]Hier[/POST] gibt es schon eine Diskussion zu dem Thema, und auch einen Patch, der aber anscheinend noch nicht in Freetz aufgenommen ist. Einige Beiträge später hatte ich auch gefragt, ob etwas dagegen spricht, die aktuellsten Versionen von mksquash zu nutzen. Irgendwie ist aber der Thread im Sande verlaufen.

 

[olistudent]

Der Patch ist noch nicht im trunk.

er13 hat doch die Antwort gegeben warum wir nicht so einfach auf ein neueres mksquashfs wechseln können. Die AVM Kernel haben Version 3.2 und unser squashfs sollte kompatibel dazu sein. Ob die tools aus squashfs4 das erzeugen können weiß ich nicht.

MfG Oliver

 

[DSLFritze]

OpenVPN external startet auch mit korrektem Link nicht (Rev. 5460)

In #5 hatte ich geschrieben, dass mksquashfs mir im zweiten Versuch ein korrektes Image geliefert hat.

Ich muss nun leider vermelden, dass der urspünglich beobachtete Fehler, dass OpenVPN als external nicht startet, auch damit auftritt. Meine Vermutung, dass es nur am vom mksquashfs verursachten fehlenden Link /usr/sbin/openvpn lag, war also falsch.

Erst nach manuellem Aufruf von

# sh -x /etc/init.d/rc.openvpn load

wird OpenVPN im Freetz GUI angezeigt und läuft dann auch erfolgreich los, wenn der Starttyp auf automatisch steht.

In welches Skript könnte ich obigen Aufruf provorisch eintragen, damit OpenVPN aktiviert wird, sobald uStor01 gemountet wurde?

 

[er13]

kleine Anmerkung von mir: die beiden Patches, die ich in dem von Ralf zitierten Thread angehängt habe, sind für die Version 3.2 von mksquashfs. Laut seiner Signatur hat DSLFritze ausschließlich 2.6.13-er Boxen (7170 und 7140), somit bewirken die Patches bei ihm nichts, da für 2.6.13 die Version 2.2 verwendet wird...

Edit:

OpenVPN external startet auch mit korrektem Link nicht

starte die Box mal neu, rufe während der ersten 5-6 Minuten keine fritz.box-Seite auf, i.e. lass die Box in Ruhe. Besteht der Fehler immer noch?

 

[RalfFriedl]

er13 hat doch die Antwort gegeben warum wir nicht so einfach auf ein neueres mksquashfs wechseln können...

Hatte ich wohl übersehen.

Erst nach manuellem Aufruf ...

Der USB-Speicher ist typischerweise nicht sofort beim Start verfügbar, bei großen Dateisystemen kann das auch schon mal in Richtung einer Minute dauern. Man kann eine Datei autorun.sh erstellen, die nach dem Mounten automatisch ausgeführt wird.

 

[olistudent]

Im aktuellen Trunk sollten die Meldungen von external auf der Logseite im Webinterface zu sehen sein.

Mfg Oliver

edit:

Parallel mksquashfs: Using 2 processors
Creating little endian 3.76 filesystem...

Liest sich nicht wie squashfs2. Wahrscheinlich "replace kernel".

 

[DSLFritze]

OpenVPN startet nun

Der Hinweis von Ralf auf die Verzögerung bei grossen Dateisystemen waren entscheidend: Der erste USB-Stick hatte wirklich sehr viele Dateien drauf! Ich habe nun einen anderen angeschlossen, der nur das Verzeichnis external enthält. OpenVPN wird nun sofort im GUI angezeigt und startet auch automatisch. Danke Ralf!

Im vorherigen Fehlerzustand kam ich allerdings über SSH auf /var/media/ftp/uStor01/external drauf. Der Stick war also gemountet, aber OpenVPN lief dennoch nicht an.

Ja, die Firmware ist mit "Replace Kernel" gebaut.

 

[RalfFriedl]

Im vorherigen Fehlerzustand kam ich allerdings über SSH auf /var/media/ftp/uStor01/external drauf. Der Stick war also gemountet, aber OpenVPN lief dennoch nicht an.

Der Stick ist noch nicht ansprechbar, wenn die Start-Skripte ausgeführt werden.
Die Anmeldung über SSH ist zu einem späteren Zeitpunkt, und da ist der Stick in Deinem Fall schon ansprechbar.

 

[olistudent]

Ich hab die 2 squashfs Patches mal eingebaut bevor sie wieder in Vergessenheit geraten...
http://trac.freetz.org/changeset/5542

MfG Oliver