Fritzbox 7270 v2 "Starting Tor Onion Router ... failed." - Woran kann es liegen?

[james.stewart]

Hallo liebe Community,

ich habe Freetz auf meiner "alten" Fritzbox 7270 v2 installiert (als zusätzliche Pakete habe ich nur Tor und Privoxy ausgewählt bei make menuconfig). Internetzugang in Freetz klappt.
Hab einen USB-Stick angeschlossen, der wurde im Fritzbox WebUI auch erkannt.

Privoxy lies sich problemlos über die Freetz-Weboberfläche starten.

Und nun das Problem: tor startet nicht.

Meine Frage: in welchem Pfad finde ich auf Freetz ein logfile, das ich zur Ursachenforschung nutzen kann? Woran kann es euer Meinung nach liegen?

Ich hoffe, ihr könnt mir hier helfen!

VG
James

Hier mal meine Configs:


Kurze Ergänzung: Wenn ich "Swap" starten will, dann erhalte ich auch "Starting swap ... failed." Vielleicht hängt das ja zusammen..? Ich habe bereits gemäß dieser Anleitung das swapfile auf dem USB-Stick angelegt, direkt von Freetz aus. Allerdings failed der Swap start immer noch :-(


P.S. Ich denke nicht, dass folgende Infos für das Problem relevant sind, aber ich füge sie trotzdem mal hinzu:
Ich habe meine alte FB 7270 v2 hinter meiner "neuen" Fritzbox 7490 (Glasfaserzugang) eingerichtet und ihr Internetzugang über LAN1 gegeben.
In der neuen Fritzbox habe ich eine Portweiterleitung drin (TCP 9001 an die alte Fritzbox).

 

[NDiIPP]

Bspw. "Freetz-Logs", zu sehen auf dem 3. Screenshot.

 

[james.stewart]

[Edit Novize: Überflüssiges Fullquote des Beitrags direkt darüber gelöscht - siehe Forumsregeln]

Das Freetz-Log ist m.E. nicht sehr auskunftsreich bzw. ich kann mit den Infos dort noch nicht die Fehlerursache identifzieren. Ich habe eben über das WebUI nochmal versucht swap und dann tor zu starten und mal einen Screeshot vom Freetz-Log in der Web-UI gemacht, siehe unten. Seltsam finde ich, dass z.B. Privoxy unter "Dienste" als "running" steht, aber im Freetz-Log als "disabled" aufgeführt wird.

Könnt ihr mir stattdessen bitte eine richtige Log-Datei (auf Dateisystem-Ebenen) nennen, wo die Ursachen für die beiden fehlgeschlagenen Starts drinstehen müssten?


[Edit Novize: Riesenbild gemäß der Forumsregeln auf Vorschau verkleinert]

 

[NDiIPP]

Es gibt noch den "Syslogd".

 

[james.stewart]

[Edit Novize: Überflüssiges Fullquote des Beitrags direkt darüber gelöscht - siehe Forumsregeln]

Hab syslogd gestartet. Dadurch hat sich in den Freetz-Logs aber auch keine neue Information ergeben, nachdem ich erneut versuchte tor und swap zu starten. Erneut failed.

Wo im Fileystem von Freetz liegen denn die richtigen Logfiles, in denen die Ursachen für den fehlerhaften tor und swap start enthalten sollten?

 

[PeterPawn]

Dann im Freetz-WebIF unter Einstellungen ⇒ Swap noch den Pfad eintragen, wo das System es finden kann

hast Du auch gelesen? Beziehungsweise natürlich nicht nur gelesen, sondern auch (korrekt) umgesetzt?

Ansonsten wird da nicht so übermäßig viel protokolliert (von den einzelnen Diensten) - man braucht ja nur mal in die entsprechenden Init-Files zu sehen: https://github.com/Freetz/freetz/blob/master/make/mod/files/root/etc/init.d/rc.swap#L19

Findest Du da irgendeinen Anhaltspunkt, daß es - neben den mit echo ausgegebenen Statusmeldungen - noch eine genauere "Fehlerbeschreibung" geben sollte? Ich ehrlich gesagt nicht - ich sehe sogar in Zeile 19, daß eine eventuell auf STDERR ausgegebene Fehlermeldung des swapon-Kommandos direkt ins Null-Device befördert wird. Wo sollte da also irgendeine nähere Beschreibung der "Ursache" entstehen, die Du hier offenbar suchst?

Und der Standardwert für den Namen des Swap-Files ist auch nicht vorgegeben: https://github.com/Freetz/freetz/blob/master/make/mod/files/root/etc/default.mod/mod.cfg#L9 - damit muß man den schon noch selbst setzen. Solltest Du das tatsächlich schon gemacht haben (aus den Einlassungen geht das für mich nicht hervor), weißt Du ja jetzt auch, wo das Kommando zum Aktivieren des Swap-Files steht und wie es aussieht ($MOD_SWAP_FILE ist natürlich durch den (vollständigen) Pfad zum angelegten Swap-File zu ersetzen) und wenn Du das dann "von Hand" ausführst und die Redirection von STDERR wegläßt, solltest Du auch die von Dir erwartete Fehlermeldung sehen, sofern das Kommando (bei korrekt angegebenem Namen der Swap-Datei) dann immer noch fehlschlagen sollte.

Dann käme aber eigentlich nur noch ein fehlendes mkswap, nachdem die Datei erstellt wurde, in Frage - das Mounten hat ja nach den Screenshots (die - nebenbei bemerkt - auch die "Präsentation" der .config (oder sogar besser der .config.compressed, weil die übersichtlicher ist - siehe Freetz-Doku) als Anhang hier nicht wirklich ersetzen können) geklappt.

 

[james.stewart]

[Edit Novize: Überflüssiges Fullquote des Beitrags direkt darüber gelöscht - siehe Forumsregeln]

Ja, das swapfile habe ich nach Anleitugn angelegt auch unter Nutzung von mkswap. Ebenso habe ich über die WebUI den Pfad zum Swapfile angegeben, siehe Screenshot.

root@fritz:/var/media/ftp/uStor01# ls -ahl swapfile
-rwxrwxrwx    1 root     root       62.5M Jan  1 01:37 swapfile

Nein, da ich kein Linux-Experte bin, wusste ich nicht, dass der swap-Daemon mit dem Skript rc.swap gestartet wird.
Wie du an meinem User erkennst, bin ich total neu bei Freetz dabei und hatte gehofft, dass auch Newbees hier willkommen sind

Ich habe wie von dir empfohlen den relevanten Teil vom rc.swap nun mal per Hand ausgeführt:

root@fritz:/etc/init.d# swapon /var/media/ftp/uStor01/swapfile
swapon: /var/media/ftp/uStor01/swapfile: Invalid argument

Anscheinend war beim Erstellend es Swapfiles was schief gegangen. Habe das Swapfile nochmal erstellt und nun läuft immerhin der swap-Damon, DANKE!

root@fritz:/etc/init.d# swapon /var/media/ftp/uStor01/swapfile
swapon: /var/media/ftp/uStor01/swapfile: Invalid argument
root@fritz:/etc/init.d# cd /var/media/ftp/uStor01/
root@fritz:/var/media/ftp/uStor01# rm swapfile
root@fritz:/var/media/ftp/uStor01# dd if=/dev/zero of=swapfile bs=1k count=64000
64000+0 records in
64000+0 records out
root@fritz:/var/media/ftp/uStor01# mkswap swapfile
Setting up swapspace version 1, size = 65531904 bytes
root@fritz:/var/media/ftp/uStor01# swapon swapfile
root@fritz:/var/media/ftp/uStor01# rc.swap status
running

Tor läuft aber immer noch nicht. Ich habe mir mal die /etc/init.d/rc.tor angesehen und es liegt an Zeile 43 bis Zeile 45, sprich die Variable exitval ist ungleich 0 wodurch dann echo "failed." ausgeführt wird.

[ -f $DAEMON_STORAGE/secret_id_key ] && savetimer=no
        $DAEMON --runasdaemon 1 --log "notice syslog" --pidfile $PID_FILE > /dev/null 2>&1
        exitval=$?

DAEMON_STORE hat den Wert /tmp/flash/tor und in dem Ordner ist leider keine Datei namens secret_id_key. Das scheint die Ursache des Fehlers zu sein.

In der Anleitung steht dazu "Der Secret ID-Key des Tor-Servers muss normalerweise nicht bearbeitet werden. Der Secret ID-Key wird beim ersten Start des Tor-Servers automatisch generiert und beim Beenden im Flash-Speicher der Box abgespeichert." Anscheinend fehlt er und ich kann ihn auch über das WebUI nicht bearbeiten:


Wie kann ich den Secret-Key erzeugen?

 

[PeterPawn]

Das scheint die Ursache des Fehlers zu sein.

Wie sicher ist das denn? Wenn es schon zuvor an anderen Problemen scheitert, kommt der Daemon ggf. gar nicht mehr dazu, automatisch den Key zu generieren, weil er schon vorher einen Fehler bemerkt.

Schließlich wird dieser Key erst beim Start des Daemons erzeugt und dann (wenn er nicht schon vorher existierte) wird 99 Sekunden lang versucht, den vom Daemon generierten Key zu kopieren: https://github.com/Freetz/freetz/blob/master/make/tor/files/root/etc/init.d/rc.tor#L47

Wie wäre es denn, wenn Du einfach mal die generierte Konfiguration "vorzeigst" (die steht ja dann in /mod/etc/tor/torrc, wie Du im rc-File gesehen hast) oder die Deinerseits noch einmal prüfst?

Die Option, das $TOR_DATADIRECTORY an eine andere Stelle zu legen, wirst Du ja sicherlich auch bemerkt haben ... das wäre zumindest anfangs hilfreich, weil das dann eben kein "volatiler Speicher" ist (wie /tmp/irgendwas) und sich viel besser untersuchen läßt. Und auch hier wäre sicherlich ein Start "von Hand" unter Auslassung der Redirections (man muß die Zeile ja nur aus dem rc-File abschreiben) hilfreich ... denn wenn alle potentiellen Ausgaben und Fehlermeldungen ins Nirwana gehen ( > /dev/null 2>&1 ), ist das für die Fehlersuche ja eher ungünstig ... und die Fehler sollte man eben richtig (unter-)suchen und nicht nur annehmen/vermuten. Wenn Du das von Hand schon probiert hast, dann war die eingangs von mir zitierte Bemerkung "ungünstig" formuliert.

Wie du an meinem User erkennst, bin ich total neu bei Freetz dabei und hatte gehofft, dass auch Newbees hier willkommen sind

Das mag für andere relevant sein ... bei mir macht das keinen Unterschied. Ich behandele alle gleich (schlecht, wie mancher meint) - es gibt also weder Welpenschutz noch Promi-Bonus bei mir und wenn jemand meine Hilfe möchte (mancher mag das auch gar nicht), dann hält er sich am besten an die Ratschläge aus den "üblichen Quellen": https://www.tty1.net/smart-questions_de.html und https://www.chiark.greenend.org.uk/~sgtatham/bugs-de.html

Das hast Du in #1 einigermaßen gemacht (die paar fehlenden Details seien Dir bis zur ersten Anmerkung, daß man sie brauchen würde, vergeben) und daher antworte ich Dir und versuche Dir (im Rahmen meiner Möglichkeiten) zu helfen. Aber wenn Du "Begrüßungs-Champagner" erwartest (oder irgendeine andere überschäumende Begrüßung), bin ich der Falsche - meine Erwartungen an die eigene Initiative (vom Lesen der Dokumentationen bis zum Überlegen, wo ein Problem liegen könnte und wie man ihm nachgehen kann) sind bei Newbies und bei "alten Hasen" genau die gleichen.

Diese Eigeninitiative sehe ich hier (in ausreichendem Umfang, auch wenn ich ihn für ausbaufähig halte) und so bin ich gerne bereit, auch weiter in diesem Thread zu lesen (und ggf. zu antworten, wenn ich der Ansicht bin, ich könnte Dir - oder auch späteren Lesern mit einem ähnlich gelagerten Problem - damit weiterhelfen).

Für das Feuerwerk zur Begrüßung eines neuen Freetz-Benutzers sind andere zuständig ...

EDIT: Beim Start von Hand könnte man das "runasdaemon" ggf. auch noch einmal (zumindest testweise) weglassen, falls mit dieser Option auch nichts nach STDOUT/STDERR protokolliert wird.