[Gelöst] Freetz-NG: Fritzbox stürzt bei Verbindung mit vsftpd ab

Fox.Mulder

Mitglied
Mitglied seit
21 Jan 2007
Beiträge
659
Punkte für Reaktionen
14
Punkte
18
Hallo,
ich verwende eine Fritzbox 7520 mit freetz-ng auf Basis 7530 7.21 als Alien Firmware (git: ng20120). Ich habe eine Mininalversion nur mit dem Paket vsftpd und ohne Addons ausprobiert. Ich verwende einen externen Datenträger mit ext4 Dateisystem, welcher über USB3.0 angeschlossen ist. Solange keine VDSL Verbindung besteht, funktioniert der ftp Zugriff einwandfrei. Sobald eine VDSL Verbindung aktiv ist, stürzt die Box nach der Eingabe des Passwortes im ftp Clienten ab. Ich habe den AVM ftp Daemon nicht entfernt. Dieser ist in der AVM Konfiguration deaktiviert. Ich würde mich über Unterstützung freuen.
 

Anhänge

  • .config.txt
    86 KB · Aufrufe: 5
Moin, bist Du verrutscht?
So kommt alles durcheinander.

Hier war ein Link zu den Developern von Freetz-NG, der ist jetzt zensiert, gelöscht worden.
Warum wurde der Link gelöscht?
 
Zuletzt bearbeitet:
Wusste nicht, dass es einen freetz-ng Bereich gibt. Im freetz-ng Github habe ich schon danach gefragt. Aufgrund einer sinnfreien Beurteilung des Entwicklers fda/cuma wurde meine Anfrage als Crap gekennzeichnet und geschlossen, so dass ich nichts mehr dazu schreiben kann. Dort wird nichts mehr passieren.
 
Der Absturz der Box beim Aufbau einer Verbindung mit vsftpd wurde inzwischen von @gismotro verifiziert.

Logs von vsftpd und Ausführen mit strace haben leider keinen Hinweis auf die Ursache des Fehlers gebracht.
 
Zuletzt bearbeitet:
EDIT: Und um noch mal auf das zurückzukommen, was für drittens oben fehlt ... auch der vsftdp schreibt Protokoll-Dateien, wenn man ihn mit den richtigen Einstellungen startet und wenn der tatsächlich "abstürzt" und sich nicht selbst wegen eines Fehlers beendet (das ist schon mal ein gewaltiger Unterschied, auch wenn das Ergebnis dasselbe sein mag), steht das auch wieder in irgendeinem System-Protokoll. Und DAS sind dann die Infos, die in so einem Falle dazugehören ... hier braucht es natürlich kein Protokoll des Builds, auch wenn die Konfigurationsdatei (die liegt im verlinkten Thread auch vor) trotzdem erforderlich ist, weil auch die "Zusammenstellung" von Paketen eine mögliche Ursache eines Problems sein kann.
@PeterPawn, folgende Punkte wurden im Freetz-NG Git besprochen, von cuma/fda jedoch als Spam gekennzeichnet und sind deshalb nur schwer auffindbar. Zu dieser Zeit (FW 7.21) war der Fehler nur dann aufgetreten, wenn die Box eine VDSL Verbindung aufgebaut hatte. Leider stürzt nicht nur vsftpd ab, sondern die ganze Box!
Ansonsten hatte ich bereits folgendes gemacht:
  1. Minimal Image - nur mit vsftpd
  2. Freetz Einstellungen gelöscht
  3. Vergleichstest auf 2. Box - bei dieser ging es zunächst, weil offline
  4. Boxen ausgetauscht
  5. Festplatten hin und her getauscht und Partitionsnamen geändert
  6. Ergebnis dieser Tests war die Schlussfolgerung, dass die Abstürze nur auftreten, wenn VDSL Verbindung aktiv ist!
  7. AVM Werkseinstellungen geladen
  8. AVM Recovery
  9. Wieder mit Minimal Image getestet
  10. Heute nochmal mit aktuellem Git Trunk Minimal Image neu gebaut -> Abstürze treten weiterhin auf
  11. Bftpd getestet -> funktioniert
Log von vsftpd
Sun Feb 7 22:27:48 2021 [pid 2] CONNECT: Client "192.168.1.39"
Sun Feb 7 22:27:48 2021 [pid 2] FTP response: Client "192.168.1.39", "220 (vsFTPd 3.0.3)"
Sun Feb 7 22:27:48 2021 [pid 2] FTP command: Client "192.168.1.39", "OPTS UTF8 ON"
Sun Feb 7 22:27:48 2021 [pid 2] FTP response: Client "192.168.1.39", "200 Always in UTF8 mode."
Nachdem der Absturz bei FW 7.25 nicht mehr von der VDSL Verbindung abhängig war, hatte ich einen neuen Issue geöffnet: Link
 
Zuletzt bearbeitet:
Ich habe/hatte das schon alles gelesen im Freetz-NG-Repo - nur teile ich die Ansicht, daß das "ausreichend" beschrieben wurde, auch dort nicht.

Denn auch mir fällt es schwer, da den Durchblick zu behalten - denn es geht darin eben nicht nur um das Problem mit dem vsftpd, sondern parallel ebenso um das Problem mit den Benutzer-Accounts, das wird dort fröhlich miteinander "vermischt" und eben nicht nur "darauf verwiesen".

Das MUSS man aber voneinander trennen ... und in der richtigen Reihenfolge abarbeiten. Wenn der Auslöser tatsächlich das Problem mit der /etc/passwd sein sollte (es wäre ja auch denkbar, daß der vsftpd die Datei öffnet und sie (und damit ihren alten Inhalt) offen hält - auch wenn es erst mal unwahrscheinlich ist), sucht man hier vollkommen sinnlos nach einem Problem.

Und man kann - wenn ich ehrlich bin - auch mit den Infos in #5 fast nichts anfangen. Denn auch wenn das ein Minimal-Image ist, in dem nur vsftpd vorhanden sein mag ... der muß aber auch erst mal aktiviert werden (VSFTPD_ENABLED ist standardmäßig no: https://github.com/Freetz-NG/freetz...d/files/root/etc/default.vsftpd/vsftpd.cfg#L2) und der wird wohl auch irgendeine Konfiguration verwenden und sei es nur die, die ansonsten auf den "Standardeinstellungen" aufbaut.

Und genau diese müßte man schon mal sehen ... denn auch darin gibt es noch genug Fallstricke. So wird z.B. vom FRITZ!OS seit 07.1x kein ftpuser-Account mehr angelegt - das muß also (wenn der verwendet werden soll) durch Freetz erfolgen (um nur mal ein Beispiel zu nennen) ... das würde dann wieder in die Richtung modusers deuten, wenn der fehlt. Also auch gehört auch der Inhalt von /etc/passwd, /etc/shadow und /etc/groups (weil auch da noch eine Gruppe users erzeugt wird beim Start des vsftpfd) noch zu den Info, die man hier sehen sollte - selbst wenn Du ein paar Infos (wobei auch das eher im Kontext "Benutzer werden nicht gespeichert" erfolgte) dazu schon im GitHub-Repo geliefert hattest.

Was ich jetzt gar nicht mehr verstehe ... wie kommst Du an ein Protokoll des vsftpd, wenn doch beim Verbindungsversuch die Box abstürzt und diese Protokolle ja nicht persistent gespeichert werden?

Stürzt am Ende gar nicht wirklich die Box ab (das steht aber so in #1), sondern nur der Daemon?

Was passiert denn, wenn der Client einfach auf das OPTS UTF8 ON verzichtet? Da kann zwar eigentlich auch nichts schiefgehen (https://github.com/InfrastructureSe...cffc855b05c9e7c8db4e5be2fc7510831b/opts.c#L20), aber man braucht das Kommando ja auch nicht, weil der vsFTPd immer mit UTF-8 arbeitet. Das Kommando schaltet eigentlich nur für die folgenden Kommandos "vorsichtshalber" noch einmal auf UTF-8 um ... es besteht also eine gewisse Wahrscheinlichkeit, daß das Protokoll gar nicht vollständig ist.

Was ist denn in einem Wireshark-Mitschnitt der Kommunikation zwischen FTP-Client und FTP-Server zu sehen? Geht das dort tatsächlich auch nur bis zu der 200-Antwort des Servers oder kommen da noch mehr Daten, die der Server nur nicht mehr ins Protokoll schreiben kann, bevor der Absturz auftritt (unter der Annahme, daß das Logfile da "buffered" ist)?

So, wie das jetzt oben steht, weiß man ja nicht einmal genau, was der Client da wohl als nächstes senden will ... damit kann man auch kaum "erraten", ob ein Absturz nun in Erwartung eines neuen Kommandos oder in seiner Ausführung auftritt.

Ich kann auch (in Grenzen) verstehen, wenn man solche Probleme durch "Kreuztests" eingrenzen will (und das ist es ja, was Du in #5 beschreibst) ... nur muß man dann irgendwann auch mal nach den Ursachen suchen und nicht immer nur konstatieren, in welcher Kombination von Einflüssen das Problem auftritt und in welcher nicht. Das KANN zwar auch hilfreich sein, ist aber als permanente Strategie eher untauglich, wie man spätestens bei einem Reifenschaden bemerkt, wenn man da einfach mal "über Kreuz" die Reifen wechselt, um zu erkunden, ob das Problem auch mit wandert.

Und warum ist bei Dir in einem Minimal-Image (so steht das für mich jedenfalls in #1) eigentlich auch noch das dropbear-Paket aktiviert? Meintest Du am Ende mit Minimal-Image gar nicht eines, was so wenige Zusätze wie möglich enthält (das verstehe ich halt unter "minimal"), sondern eines, das so wenige Standardeinstellungen (von Freetz-NG) wie möglich verändert? DAS ist schon ein gewaltiger Unterschied ... ich weiß auch nicht, was sich @cuma bei y als Standard gedacht hat (https://github.com/Freetz-NG/freetz...3efec014433b6e6f1f/make/dropbear/Config.in#L8), aber das gehört nun mal auch zu den "Unterschieden" zu Freetz (https://github.com/Freetz/freetz/bl...509f2a5d917b6d24cd/make/dropbear/Config.in#L8), die sich ja nicht nur auf die unterstützten AVM-Versionen beschränken, sondern noch andere (mal hilfreiche, mal halbgare) Änderungen betreffen.

Das klingt zwar vielleicht wie ein "Fragenkatalog" meinerseits, soll aber eigentlich nur verdeutlichen, was an Infos vorhanden ist, wo darin Widersprüche auftreten, die der Erklärung bedürfen und was man sich (beim Versuch zu verstehen, wo das Problem letztlich liegen könnte) automatisch für Fragen stellt. Diese gilt es nun zu beantworten ... wenn das Problem persistent und reproduzierbar ist, ist das ja schon mal gut - jetzt sollte man vielleicht erst mal klären, ob denn nun der Daemon oder doch die ganze Box abstürzt. Danach muß man dann nur noch die "Nebenbedingungen" eliminieren (da hilft beim "Benutzerkonten"-Problem schon die Kenntnis, wie die o.a. Dateien beim Absturz aussehen) und wenn das dann immer noch reproduzierbar ist, sollte der Netzwerk-Mitschnitt (nicht der auf der Box, sondern auf dem Client) auch zeigen können, ob die oben zu sehende Server-Antwort tatsächlich das letzte ist, was da "über den Draht" geht. Das glaube ich zwar fast nicht (weil es einfach logischer ist, wenn ein Absturz in der Verarbeitung eines Kommandos auftritt und nicht nach dessen "Erledigung"), aber auch hier ist "wissen" wieder sinnvoller als "raten" und erspart einem viel Zeit, falls man doch in die falsche Richtung denkt.

Der Ball liegt also im Feld derer, die mit diesem "Problem" zu kämpfen haben. Wobei es auch nicht schaden kann, sich mal die Patches/Commits in anderen Repos anzusehen, die in den letzten 5 Jahren (die 3.0.3 ist aus 2015 und es gibt vom originalen Autoren keine neuere) von Dritten hinzugefügt wurden, um diverse Probleme zu eliminieren. Vielleicht kommt einem ja eine der dortigen Fehlerbeschreibungen (https://github.com/InfrastructureServices/vsftpd/commits/master) dann auch bekannt vor und das Problem ist dort ggf. schon gelöst.

Die von Freetz/Freetz-NG verwendeten Quellen sind jedenfalls die "originalen" und die Patches (https://github.com/Freetz-NG/freetz-ng/tree/master/make/vsftpd/patches) unterscheiden sich auch nur um einen zwischen Freetz und Freetz-NG. Dieser eine sollte eigentlich nur auf MIPS-Boxen angewandt werden (zumindest sollte der ein Problem bei MIPS-Architektur fixen) und dürfte auf der 7520/7530 gar nicht verwendet werden, aber da hat jemand beim Implementieren des Patches geschlafen ... und damals lag das Hauptaugenmerk auch noch auf der MIPS-Architektur.

Aber der vsFTPd hat eben schon einmal Probleme gemacht (https://www.ip-phone-forum.de/threa...-nicht-mehr-mehr-verbose.302127/#post-2312750) und das war auch bei einem Wechsel der Kernel-Version ... angesichts der Tatsache, daß die ARM-Boxen einen neueren/anderen Kernel verwenden, als die MIPS-Modelle (VR9, GRX5), kann das also tatsächlich sein, daß sich das Problem ausschließlich auf der 7520/7530 (bzw. anderen IPQ-Boxen) zeigt. Das ist auch einer der "Kreuztests", die wohl noch nicht gemacht wurden ... oder habe ich da etwas übersehen? Tritt das auf 7590 (noch neuerer Kernel seit 07.19 und andere C-Library, aber weiterhin MIPS-Architektur) ebenso auf? In #1 steht zwar was von einer 7520 (als 7530 verwendet), aber aus dem Thread-Titel geht nicht hervor, daß sich das Problem ausschließlich auf dieses Modell beschränkt.

Ich glaube zwar auch nicht wirklich, daß das Memory-Mapping auf ARM so viel anders arbeitet, als auf MIPS (es ist mir aber auch zu anstrengend, da jetzt durch den ganzen mm-Zweig der Kernel-Quellen zu krauchen) ... aber wenn man es testen WILL, kann man auch mal den 901-irgendwas-Patch in Freetz-NG wieder rausnehmen, wenn man ohnehin für ARM-Boxen übersetzen will. Gebraucht werden sollte er dort jedenfalls nicht ... weil er die Sicherheit des "secure buffers" herabsetzt und dieser FTP-Server soll ja gerade "very secure" sein. Denn mit diesem Patch wird eben "erlaubt", daß auch außerhalb der Grenzen der Page, in der dieser "buffer" verwaltet wird, Lesezugriffe auftreten dürfen ... was aber bei "sauberer Programmierung" (und ohne bösartigen Benutzer) auch nie der Fall sein sollte.

Und eigentlich sollte sich auch in den Kernel-Messages (in der Ausgabe von dmesg) etwas finden lassen, wenn das System doch weiter laufen sollte und nicht wirklich die gesamte Box abstürzt - wenn das wirklich ein (Programm-)Absturz ist, sollte es zumindest einen Stacktrace geben, wo man dann sehen kann, welche Funktion da von welcher aufgerufen wurde ... auch das gehört dann zu den Informationen, die man für eine solche Fehlersuche benötigt.

So, das sollte jetzt auch erst mal reichen ... ich höre schon wieder die ersten Tränen, daß das ja alles viel zu lang wäre, auf die Tastaturen trommeln.
 
Vielen Dank für Deine umfangreiche Antwort. Ich werde den vorgeschlagenen Punkten Schritt für Schritt nachgehen.

Als Alternative zu vsftpd habe ich bftpd ausprobiert. Dieser greift auch auf die Dateien passwd, usw. zu. Dieses Programm funktioniert ohne Probleme.

Bei meiner 7520 stürzt die Box ab und nicht nur vsftpd. Ich kann leider die Funktion von vsftpd auf der 7590 nicht testen, da ich diese Box nicht mehr habe.

Den ftpuser Account habe ich als Fritzbox Benutzer angelegt. Allerdings wird dass passwort in diesem Fall in einem box- oder app-user gespeichert. Das Passwort kann in /etc/passwd gespeichert werden, wenn ich passwd ftpuser ausführe und die Freetz Benutzerverwaltung wieder funktioniert.

Vsftpd ist folgendermaßen konfiguriert:
Code:
root@fritz:~$ cat /mod/etc/conf/vsftpd.conf
export VSFTPD_ADD_SETTINGS=''
export VSFTPD_ALLOW_FTPUSER='yes'
export VSFTPD_ALLOW_ROOT='yes'
export VSFTPD_ANONYMOUS='yes'
export VSFTPD_ANON_ROOT='/mod/home/ftp'
export VSFTPD_CHROOT='no'
export VSFTPD_CHROOT_JAIL_LIST=''
export VSFTPD_DELAY_FAILED_LOGIN='15'
export VSFTPD_ENABLED='no'
export VSFTPD_ENABLE_RELOAD_SCRIPT='no'
export VSFTPD_ENABLE_SSL='no'
export VSFTPD_ENABLE_SSLV2='no'
export VSFTPD_ENABLE_SSLV3='no'
export VSFTPD_ENABLE_TLSV1='no'
export VSFTPD_FORCE_DATA_SSL='no'
export VSFTPD_FORCE_LOGIN_SSL='no'
export VSFTPD_LOG_ENABLE='yes'
export VSFTPD_LOG_FILE='/var/media/ftp/vsftpd.log'
export VSFTPD_LOG_PROTOC='yes'
export VSFTPD_LOG_SYSLOG='no'
export VSFTPD_MAX_CLIENTS='25'
export VSFTPD_MAX_PER_IP='5'
export VSFTPD_PASV_ADDRESS='no'
export VSFTPD_PASV_MAX='0'
export VSFTPD_PASV_MIN='0'
export VSFTPD_PORT='21'
export VSFTPD_PROMISCUOUS='no'
export VSFTPD_SHOW_BANNER='no'
export VSFTPD_USERS_ENABLED='yes'
Zuerst habe ich mir die Zugriffe auf die Datein in /tmp und die Einträge in vsftpd.log bis zum Absturz der Box angesehen:
Code:
Win10
D:\tmp>ftp -d 192.168.10.1
Verbindung mit 192.168.10.1 wurde hergestellt.
220 (vsFTPd 3.0.3)
---> OPTS UTF8 ON
200 Always in UTF8 mode.
Benutzer (192.168.10.1:(none)): root
---> USER root
331 Please specify the password.
Kennwort:
---> PASS ************
Verbindung beendet durch Remotehost.
vsftpd.log wird in einem persitenten Bereich geschrieben. Alternativ kann man einen angeschlossener USB Stick bzw. Festplatte verwenden.
Code:
root@fritz:/var/mod/root# cat /var/media/ftp/vsftpd.log
Thu Jan  1 01:06:07 1970 [pid 2] CONNECT: Client "192.168.10.20"
Thu Jan  1 01:06:07 1970 [pid 2] FTP response: Client "192.168.10.20", "220 (vsFTPd 3.0.3)"
Thu Jan  1 01:06:07 1970 [pid 2] FTP command: Client "192.168.10.20", "OPTS UTF8 ON"
Thu Jan  1 01:06:07 1970 [pid 2] FTP response: Client "192.168.10.20", "200 Always in UTF8 mode."
Thu Jan  1 01:06:11 1970 [pid 2] FTP command: Client "192.168.10.20", "USER root"
Thu Jan  1 01:06:11 1970 [pid 2] [root] FTP response: Client "192.168.10.20", "331 Please specify the password."
Thu Jan  1 01:06:12 1970 [pid 2] [root] FTP command: Client "192.168.10.20", "PASS <password>"
Thu Jan  1 01:06:12 1970 [pid 1] [root] OK LOGIN: Client "192.168.10.20"
# Könnte der Wechsel von pid 2 auf pid 1 ein Hinweis sein?
Zugriffe auf /tmp bis zur Trennung der ssh Verbindung
Code:
root@fritz:/var/mod/root# inotifyd - /tmp
r       /tmp    passwd
a       /tmp    passwd
0       /tmp    passwd
r       /tmp    passwd
a       /tmp    passwd
0       /tmp    passwd
c       /tmp    avm-resolv.conf
r       /tmp    avm-resolv.conf
c       /tmp    avm-resolv.conf
w       /tmp    avm-resolv.conf
c       /tmp    dnsd_servers
r       /tmp    dnsd_servers
w       /tmp    dnsd_servers
r       /tmp    avm-resolv.conf
a       /tmp    avm-resolv.conf
0       /tmp    avm-resolv.conf
r       /tmp    avm-resolv.conf
a       /tmp    avm-resolv.conf
0       /tmp    avm-resolv.conf
r       /tmp    passwd
a       /tmp    passwd
0       /tmp    passwd
r       /tmp    shadow
a       /tmp    shadow
0       /tmp    shadow
Wireshark Protokoll
Code:
14    23.181268    192.168.10.20    192.168.10.1    TCP    66    65001 → 21 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=1 SACK_PERM=1
15    23.181684    192.168.10.1    192.168.10.20    TCP    66    21 → 65001 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1460 SACK_PERM=1 WS=32
16    23.181732    192.168.10.20    192.168.10.1    TCP    54    65001 → 21 [ACK] Seq=1 Ack=1 Win=8192 Len=0
17    23.194300    192.168.10.1    192.168.10.20    FTP    74    Response: 220 (vsFTPd 3.0.3)
18    23.197633    192.168.10.20    192.168.10.1    FTP    68    Request: OPTS UTF8 ON
19    23.197988    192.168.10.1    192.168.10.20    TCP    60    21 → 65001 [ACK] Seq=21 Ack=15 Win=29216 Len=0
20    23.201005    192.168.10.1    192.168.10.20    FTP    80    Response: 200 Always in UTF8 mode.
21    23.249199    192.168.10.20    192.168.10.1    TCP    54    65001 → 21 [ACK] Seq=15 Ack=47 Win=8146 Len=0
22    32.562780    192.168.10.20    192.168.10.1    FTP    65    Request: USER root
23    32.566120    192.168.10.1    192.168.10.20    FTP    88    Response: 331 Please specify the password.
24    32.620348    192.168.10.20    192.168.10.1    TCP    54    65001 → 21 [ACK] Seq=26 Ack=81 Win=8112 Len=0
25    33.060415    192.168.10.20    224.0.0.22    IGMPv3    54    Membership Report / Leave group 224.168.100.1
26    33.108930    192.168.10.20    224.0.0.22    IGMPv3    54    Membership Report / Leave group 224.168.100.1
27    34.070817    192.168.10.20    224.0.0.22    IGMPv3    54    Membership Report / Join group 224.168.100.1 for any sources
28    34.101685    192.168.10.20    224.0.0.22    IGMPv3    54    Membership Report / Join group 224.168.100.1 for any sources
29    37.755375    192.168.10.20    192.168.10.1    FTP    65    Request: PASS ***********
30    37.794460    192.168.10.1    192.168.10.20    TCP    60    21 → 65001 [ACK] Seq=81 Ack=37 Win=29216 Len=0
Wenn ich die ftp Verbindung mit dem Total Commander herstelle, wird der UTF8 Modus nicht verwendet. vsftpd.log sieht in diesem Fall folgendermaßen aus:
Code:
Thu Jan  1 01:17:37 1970 [pid 2] CONNECT: Client "192.168.10.20"
Thu Jan  1 01:17:37 1970 [pid 2] FTP response: Client "192.168.10.20", "220 (vsFTPd 3.0.3)"
Thu Jan  1 01:17:41 1970 [pid 2] FTP command: Client "192.168.10.20", "USER root"
Thu Jan  1 01:17:41 1970 [pid 2] [root] FTP response: Client "192.168.10.20", "331 Please specify the password."
Thu Jan  1 01:17:42 1970 [pid 2] [root] FTP command: Client "192.168.10.20", "PASS <password>"
Thu Jan  1 01:17:42 1970 [pid 1] [root] OK LOGIN: Client "192.168.10.20"
 
Zuletzt bearbeitet:
Wenn tatsächlich die gesamte Box abstürzt, sollte sich beim nächsten Start aus den Support-Daten oder aus /proc/avm/log_cr/crash ein entsprechender Crash-Report auslesen lassen. Besser aus den Support-Daten, denn dieser Report kann nur ein einziges Mal ausgelesen werden, danach werden diese Daten wieder gelöscht.

Zumindest kommt die FTP-Session jetzt ja offenbar weiter, als zuvor in #5 - gibt es dafür eine Erklärung? Ist das nun eine feste Stelle, wo der Absturz auftritt (hier ja offenbar mehrfach nach einem erfolgreichen(!) Login mit verschiedenen Clients) oder wechselt die auch?

Die Frage zielt darauf ab, was die Box (bzw. der Daemon) an dieser Stelle wohl machen könnte ... die letzte Nachricht in den beiden letzten Log-Files stammt jedenfalls von hier: https://github.com/InfrastructureSe...3ebf1028075d493cb9bae086dda4c3/privops.c#L270 und signalisiert eigentlich ein erfolgreiches Login. (Die "originalen" Quellen sind leider nicht per HTTP im Internet erreichbar, aber der Stand aus dem verlinkten GitHub-Repo sollte der sein, der mit dem in Freetz verwendeten übereinstimmt - mit Ausnahme der Freetz-Patches, die aber nichts an diesen Stellen ändern, soweit ich das gesehen habe.)

Das Überprüfen des Users und des Passwords sollte da eigentlich schon passiert sein - was dann m.E. die Dateien in /etc aus dem Spiel nimmt, solange der verwendete Benutzer root da auch wenigstens ein existierendes(!) Home-Verzeichnis eingetragen hat. In #6 hast Du die "Bitte" um diese Dateien vermutlich überlesen.

Was passiert denn, wenn das Login mit einem nicht vorhandenen Benutzernamen oder einem ungültigen Konto versucht wird? Dann sollte der Prozess ja gar nicht bis an diese Stelle kommen, sondern hier: https://github.com/InfrastructureSe...3ebf1028075d493cb9bae086dda4c3/privops.c#L262 den Fehler protokollieren und auf den nächsten Versuch warten.

Nach dem erfolgreichen Authentifizieren mit einem lokalen Konto und dem passenden Kennwort geht es dann hier weiter: https://github.com/InfrastructureSe...f1028075d493cb9bae086dda4c3/twoprocess.c#L342 und da zwar "chroot_list_enable" eingeschaltet ist, aber die Datei wohl nur eine leere Zeile beinhaltet, sollte es (wenn der Code zum Ermitteln, ob der User in dieser Datei steht, so auch funktioniert) dann hier: https://github.com/InfrastructureSe...f1028075d493cb9bae086dda4c3/twoprocess.c#L382 weitergehen und irgendwann hier: https://github.com/InfrastructureSe...f1028075d493cb9bae086dda4c3/twoprocess.c#L460 ankommen, wo dann das Verzeichnis für die Session gewechselt werden sollte.

Da es einigermaßen anstrengend ist, die tatsächlich verwendete Konfigurationsdatei für den vsFTPd aus den oben gezeigten Freetz-Settings und dem Inhalt der vsftpd_conf (das ist das Skript, was die "echte" Konfigurationsdatei für den Daemon erzeugt) zusammenzusuchen, braucht es auch noch die Dateien (und natürlich ihren Inhalt), die auf das Muster /mod/etc/vsftpd* passen.

Jedenfalls wäre eine der nächsten Aktionen dann der Wechsel des Verzeichnisses - wie oben verlinkt. Da sollte man dann schon wissen (oder ermitteln können), wohin das eigentlich gehen sollte und ob dieses Verzeichnis auch tatsächlich existiert. Daher die "Wünsche" nach den ganzen zusätzlichen Informationen oben ... erst danach kann man einigermaßen sicher annehmen, daß der Abbruch nicht schon dort erfolgt und kann/muß dem Control-Flow weiter folgen - wenn der Stacktrace des Absturzes nicht weitere Hinweise liefert.



Was die "pid n"-Ausgabe tatsächlich bedeutet, muß man erst mal in der logging.c erkunden - "echte" PIDs (Process ID) des laufenden Systems können das eigentlich nicht sein, denn die werden üblicherweise anders vergeben und PID 1 wäre eigentlich der "init"-Prozess selbst ... das ist so etwas wie die "Wurzel" des Process-Trees.

Zwei Punkte sind auch noch unklar ... wenn der Netzwerk-Verkehr tatsächlich kein FIN-Paket für die Verbindung zeigt und der Windows-Client trotzdem ein "Verbindung beendet durch Remotehost." behauptet, dann war hoffentlich vor dieser letzten Nachricht eine längere Pause, bis Windows dann festgestellt hat, daß der Server nicht mehr antwortet? Aus den protokollierten Paketen geht eigentlich nichts hervor, was ein solches (aktives) Beenden erklären könnte ... gleichzeitig paßt der Text nicht zu einem Timeout nach längerer Wartezeit (auch wenn ich nicht genau weiß, wie der Windows-Client da arbeitet). Fehlt da vielleicht doch noch irgendwo etwas?

Und das VSFTPD_ENABLED='no' in der Konfiguration irritert mich auch ... bisher war ich der Ansicht, daß ein Daemon mit dieser Einstellung gar nicht gestartet würde. Woher kommt da dann eine laufende Instanz des FTP-Servers? Wie wird diese gestartet (automatisch, manuell, über inetd)?

EDIT: Mittlerweile gibt es ja die Änderung bei der Benutzer-Verwaltung von Freetz-NG ... die sollte beim nächsten Versuch dann entweder schon mit drin sein oder bis zum Beheben des Problems dann weiterhin fehlen - aber bitte nicht mitten im Rennen die Pferde wechseln. Das hier interpretieren wir mal einfach noch als "vor dem Start", weil die Änderung erst jetzt zur Verfügung steht - da ist dieser Wechsel noch nachvollziehbar.
 
Zuletzt bearbeitet:
Ich habe mal auf Debian 6 nachgesehen, welche Prozesse von vsftpd laufen.
Vor dem Aufbau der ftpverbindung läuft:
Code:
root@plug1:~# ps aux|grep vsftpd
root      1288  0.0  0.7   4032   984 ?        S    16:07   0:00 /usr/sbin/vsftpd
root      1563  1.0  0.6   3376   804 pts/2    S+   16:26   0:00 grep vsftpd
Nach dem Aufbau der ftp Verbindung laufen:
Code:
root@plug1:~# ps aux|grep vsftpd
root      1288  0.0  0.7   4032   984 ?        S    16:07   0:00 /usr/sbin/vsftpd
nobody    1572  4.0  0.8   4240  1128 ?        Ss   16:27   0:00 /usr/sbin/vsftpd
root      1574  0.0  0.6   4264   832 ?        S    16:27   0:00 /usr/sbin/vsftpd
root      1576  0.0  0.6   3376   804 pts/2    S+   16:28   0:00 grep vsftpd
Auf der 7520 werden beim Aufbau der ftp Verbindung mit Total Commander ebenfalls 2 zusätzliche Prozesse geöffnet. Ich habe mal alle 3 Prozesse bis zum Absturz der Box getracet.
Code:
root@fritz:/var/mod/root# ps |grep vsftpd
2281 root      3476 S    vsftpd
2940 root      1624 S    grep vsftpd
root@fritz:/var/mod/root# strace -p 3476
strace: attach: ptrace(PTRACE_SEIZE, 3476): No such process
root@fritz:/var/mod/root# strace -p 2281
strace: Process 2281 attached
accept(4, {sa_family=AF_INET, sin_port=htons(58459), sin_addr=inet_addr("192.168.10.20")}, [28->16]) = 5
clone(child_stack=NULL, flags=CLONE_NEWIPC|CLONE_NEWPID|SIGCHLD) = 3077
close(5)                                = 0
accept(4,

root@fritz:/var/mod/root# ps |grep vsftpd
2281 root      3476 S    vsftpd
3077 root      3480 S    vsftpd
3079 root      3492 S    vsftpd
3156 root      1624 S    grep vsftpd
root@fritz:/var/mod/root# strace -p 3077
strace: Process 3077 attached
read(5, "\1", 1)                        = 1
read(5, "\4\0\0\0", 4)                  = 4
read(5, "root", 4)                      = 4
read(5, "\4\0\0\0", 4)                  = 4
read(5, "root", 4)                      = 4
read(5, "\0\0\0\0", 4)                  = 4
read(5, "\0\0\0\0", 4)                  = 4
open("/etc/passwd", O_RDONLY)           = 6
ioctl(6, TCGETS, 0xbee55a10)            = -1 ENOTTY (Inappropriate ioctl for device)
read(6, "asec::101:101::/nonexistent:/nos"..., 4096) = 2469
close(6)                                = 0
open("/etc/shadow", O_RDONLY)           = 6
ioctl(6, TCGETS, 0xbee55a10)            = -1 ENOTTY (Inappropriate ioctl for device)
read(6, "bittorrent:!:0:0:99999:7:::\nftp:"..., 4096) = 111
close(6)                                = 0
gettimeofday({tv_sec=213, tv_usec=691363}, NULL) = 0
gettimeofday({tv_sec=213, tv_usec=693587}, NULL) = 0
gettimeofday({tv_sec=213, tv_usec=693905}, NULL) = 0
fcntl64(4, F_SETLKW64, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0, l_len=0}) = 0
write(4, "Thu Jan  1 01:03:33 1970 [pid 1]"..., 73) = 73
fcntl64(4, F_SETLK64, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=0, l_len=0}) = 0
open("/mod/etc/vsftpd.chroot_list", O_RDONLY|O_NONBLOCK|O_LARGEFILE) = 6
fstat64(6, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6f37000
mprotect(0xb6f38000, 4096, PROT_NONE)   = 0
mprotect(0xb6f37000, 4096, PROT_READ)   = 0
read(6, "", 0)                          = 0
mprotect(0xb6f37000, 4096, PROT_READ)   = 0
munmap(0xb6f37000, 8192)                = 0
close(6)                                = 0
rt_sigaction(SIGCHLD, {sa_handler=0x25358, sa_mask=~[RTMIN RT_1], sa_flags=SA_RESTORER, sa_restorer=0xb6c22f28}, NULL, 8) = 0
write(5, "\1", 1)                       = 1
wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 2
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=2, si_uid=0, si_status=0, si_utime=0, si_stime=2} ---
sigreturn({mask=[]})                    = 2
close(5)                                = 0
socketpair(AF_UNIX, SOCK_STREAM, 0, [5, 6]) = 0
rt_sigaction(SIGCHLD, {sa_handler=0x25358, sa_mask=~[RTMIN RT_1], sa_flags=SA_RESTORER, sa_restorer=0xb6c22f28}, NULL, 8) = 0
rt_sigaction(SIGALRM, {sa_handler=0x25350, sa_mask=~[RTMIN RT_1], sa_flags=SA_RESTORER, sa_restorer=0xb6c22f28}, NULL, 8) = 0
clone(

root@fritz:/var/mod/root# strace -p 3079
strace: Process 3079 attached
recv(0, "USER root\r\n", 4096, MSG_PEEK) = 11
read(0, "USER root\r\n", 11)            = 11
gettimeofday({tv_sec=206, tv_usec=445716}, NULL) = 0
gettimeofday({tv_sec=206, tv_usec=446199}, NULL) = 0
fcntl64(4, F_SETLKW64, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0, l_len=0}) = 0
write(4, "Thu Jan  1 01:03:26 1970 [pid 2]"..., 82) = 82
fcntl64(4, F_SETLK64, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=0, l_len=0}) = 0
gettimeofday({tv_sec=206, tv_usec=450031}, NULL) = 0
gettimeofday({tv_sec=206, tv_usec=450504}, NULL) = 0
fcntl64(4, F_SETLKW64, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0, l_len=0}) = 0
write(4, "Thu Jan  1 01:03:26 1970 [pid 2]"..., 113) = 113
fcntl64(4, F_SETLK64, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=0, l_len=0}) = 0
write(0, "331 Please specify the password."..., 34) = 34
rt_sigaction(SIGALRM, {sa_handler=0x25358, sa_mask=~[RTMIN RT_1], sa_flags=SA_RESTORER, sa_restorer=0xb6c22f28}, NULL, 8) = 0
setitimer(ITIMER_REAL, {it_interval={tv_sec=0, tv_usec=0}, it_value={tv_sec=300, tv_usec=0}}, {it_interval={tv_sec=0, tv_usec=0}, it_value={tv_sec=249, tv_usec=459144}}) = 0
recv(0, "PASS root\r\n", 4096, MSG_PEEK) = 11
read(0, "PASS root\r\n", 11)            = 11
gettimeofday({tv_sec=213, tv_usec=677370}, NULL) = 0
gettimeofday({tv_sec=213, tv_usec=677867}, NULL) = 0
fcntl64(4, F_SETLKW64, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0, l_len=0}) = 0
write(4, "Thu Jan  1 01:03:33 1970 [pid 2]"..., 95) = 95
fcntl64(4, F_SETLK64, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=0, l_len=0}) = 0
write(6, "\1", 1)                       = 1
write(6, "\4\0\0\0", 4)                 = 4
write(6, "root", 4)                     = 4
write(6, "\4\0\0\0", 4)                 = 4
write(6, "root", 4)                     = 4
write(6, "\0\0\0\0", 4)                 = 4
write(6, "\0\0\0\0", 4)                 = 4
read(6, "\1", 1)                        = 1
exit_group(0)                           = ?
+++ exited with 0 +++
Die Datei vsftpd.chroot_list ist leer.
Code:
root@fritz:/var/mod/root# ls -al /mod/etc
drwxr-xr-x    8 root     root           500 Jan  1 01:00 .
drwxr-xr-x   11 root     root           220 Jan  1 01:00 ..
...
-rw-r--r--    1 root     root             0 Jan  1 01:00 vsftpd.chroot_list
-rw-r--r--    1 root     root           616 Jan  1 01:00 vsftpd.conf
-rw-r--r--    1 root     root             0 Jan  1 01:00 vsftpd.user_list
-rw-r--r--    1 root     root            35 Jan  1 01:00 webcfg.conf
vsftpd.conf hat folgenden Inhalt:
Code:
root@fritz:/var/mod/etc# cat vsftpd.conf
background=yes
check_shell=no
listen=yes
anonymous_enable=yes
local_enable=yes
local_umask=022
chroot_local_user=no
passwd_chroot_enable=no
write_enable=yes
nopriv_user=root
secure_chroot_dir=/var/run/vsftpd
listen_port=21
userlist_enable=yes
anon_root=/mod/home/ftp
xferlog_std_format=no
xferlog_enable=yes
vsftpd_log_file=/var/media/ftp/vsftpd.log
log_ftp_protocol=yes
syslog_enable=no
max_clients=25
max_per_ip=5
pasv_min_port=0
pasv_max_port=0
pasv_promiscuous=no
delay_failed_login=15
chroot_list_enable=yes
ssl_enable=no
ssl_sslv2=no
ssl_sslv3=no
ssl_tlsv1=no
force_local_data_ssl=no
force_local_logins_ssl=no
Nach der Aktualisierung der lokalen Sourcen auf Freetz: ng-18219-97dee21bb funktioniert das Anlegen des Benutzers test immer noch nicht.
Die Support Datei habe ich angehangen.
Zumindest kommt die FTP-Session jetzt ja offenbar weiter, als zuvor in #5 - gibt es dafür eine Erklärung? Ist das nun eine feste Stelle, wo der Absturz auftritt (hier ja offenbar mehrfach nach einem erfolgreichen(!) Login mit verschiedenen Clients) oder wechselt die auch?
Den Inhalt von vsftpd.log habe ich aus meinem Report im Freetz-NG Git zur 7.21er Version eines älteren Git-Standes übernommen. Die neuen Logs sind mit dem aktuellen Git-Stand und 7.25er FW. Als Clienten verwende ich entweder Windows10 ftp oder Total Commander.
Das Überprüfen des Users und des Passwords sollte da eigentlich schon passiert sein - was dann m.E. die Dateien in /etc aus dem Spiel nimmt, solange der verwendete Benutzer root da auch wenigstens ein existierendes(!) Home-Verzeichnis eingetragen hat. In #6 hast Du die "Bitte" um diese Dateien vermutlich überlesen.
Den Inhalt der Dateien passwd, group, shadow findest Du in meinem Beitrag zur Benutzerverwaltung.
Code:
root:x:0:0:root:/mod/root:/bin/sh
Das Verzeichnis existiert.
Was passiert denn, wenn das Login mit einem nicht vorhandenen Benutzernamen oder einem ungültigen Konto versucht wird? Dann sollte der Prozess ja gar nicht bis an diese Stelle kommen, sondern hier: https://github.com/InfrastructureSe...3ebf1028075d493cb9bae086dda4c3/privops.c#L262 den Fehler protokollieren und auf den nächsten Versuch warten.
Wenn ich ftp als Benutzer verwende und irgend etwas als Passwort angebe, stürzt die Box trotzdem ab. Wenn ich einen ungültigen Benutzernamen angebe und irgendein Passwort verwende, erhalte ich im Total Commander die Meldung 530 Login incorrect und die Box stürtzt nicht sofort ab. Nach etwas längeren Wartens ist die Box doch noch abgestürtzt.
Und das VSFTPD_ENABLED='no' in der Konfiguration irritert mich auch ... bisher war ich der Ansicht, daß ein Daemon mit dieser Einstellung gar nicht gestartet würde. Woher kommt da dann eine laufende Instanz des FTP-Servers? Wie wird diese gestartet (automatisch, manuell, über inetd)?
Vsftpd wird automatisch gestartet.
 

Anhänge

  • support FRITZ.Box 7520 175.07.25_01.01.70_0102.txt
    978.6 KB · Aufrufe: 5
Zuletzt bearbeitet:
Es gibt einen Parameter, mit dem man zwischen diesen "Thread-Modellen" wählen kann (https://github.com/InfrastructureSe...ebf1028075d493cb9bae086dda4c3/prelogin.c#L274) - offenbar kommuniziert bei dem "two process model" der Prozess, der für die Bedienung der Control-Connection zuständig ist, über Unix-Sockets mit einem weiteren, der dann die eigentlichen Aktionen ausführt. Das macht es komplizierter beim Verfolgen, wobei man das beim strace-Aufruf mit einer Angabe von -ff auch automatisch "verfolgen" lassen kann (inkl. Ausgabe in separate Files mit der PID als Namen), wenn da ein fork() (oder clone()) erfolgt.

Vielleicht wird es etwas übersichtlicher, wenn Du mal mit one_process_model=yes (https://github.com/InfrastructureSe...ebf1028075d493cb9bae086dda4c3/parseconf.c#L47) in der Konfiguration arbeitest.

Ich blicke nämlich durch das Ergebnis vom strace nicht durch ... da wird in irgendeinen FD 6 geschrieben (von PID 3079), wo man nicht sehen kann, was das eigentlich ist - vermutlich auch wieder ein Unix-Socket, der von privsock.c verwaltet wird (https://github.com/InfrastructureSe...02fd3ebf1028075d493cb9bae086dda4c3/privsock.c) und letztlich wohl die Verbindung zum "Hauptprozess" darstellt. Aber das ist auch nur geraten und diese write()-Calls sind ja offensichtlich das letzte (vor dem allerletzten read()), was da noch passiert(e). FD 4 ist offensichtlich das Log-File ... aber da fehlt - wenn das "two process model" aktiv ist - eben einiges, was dann bei -ff dabei sein sollte.

Das Crash-Log ist herzlich wenig hilfreich auf den ersten Blick. Ist das tatsächlich auch von diesem Absturz und nicht von einem früheren? Durch die fehlende Uhrzeit ist das kaum erkennbar. Da das Crash-Log auch so lange gespeichert wird, bis es jemand ausliest (was Du mit der Support-Datei jetzt gemacht hast), kann das auch durchaus längere Zeit überdauern, solange es nicht im Hintergrund an AVM gesendet wird.

Da ist jedenfalls nur eine "NULL pointer reference" im Kernel zu sehen und mir fehlt etwas die Phantasie, wie diese von einem Userland-Programm wie dem vsFTPd verursacht werden sollte - das Einzige, was mir da spontan wieder einfällt, ist der Patch für die "memory protection" in dieser ominösen 901-irgendwas.patch in Freetz-NG (für vsftpd). In den ganzen Stacktraces fehlt aber JEDER Hinweis auf einen vsftpd-Prozess (der beim Crash eine Rolle spielte) - ja, wenn man in der gesamten Datei nach ftp sucht, gibt es ab Zeile 20098 (da starten die Crash-Logs überhaupt erst) nicht ein Vorkommen dieser Zeichenkette.

Schon um sicherzugehen, daß da das Crash-Log tatsächlich auch zum Absturz gehört, wäre direkt nach dem nächsten Neustart, der auf einen weiteren Absturz folgt, die Support-Datei noch einmal zu laden ... wobei wirklich nur der Abschnitt mit den Crash-Logs interessant ist, der Rest kann gelöscht werden.

Wie sich das mit der Benutzerverwaltung noch "entwickelt", muß man dann eben erst mal abwarten ... aber bitte vergiß auf keinen Fall dann SEHR DEUTLICH zu schreiben, wenn Du die Änderungen hinsichtlich der Benutzerverwaltung in das zum Testen in diesem Thread verwendete Image übernommen hast. Ich habe jedenfalls jetzt schon keine Lust, daraus resultierende zusätzliche "Verwirrungen" erst auseinander dröseln zu müssen.
 
Ich hab für meine 6590 ein Image mit vsftpd und fw 7.25 gebaut.
Mehrfach drauf verbunden, winscp und Totalcommander und kann nur sagen
Sie macht KEINE Neustarts.
 
  • Like
Reaktionen: PeterPawn
@Cataclysm_177: Vielen Dank fürs Testen. Damit wissen wir, dass der Absturz nicht bei allen Modellen auftritt.
 
Also kein freetz-ng Problem ist.
Diese Schlussfolgerung ist aus meiner Sicht nicht zulässig. Softwareintegration bedeutet, eine Komponente (vsftpd) auf einer Basis lauffähig zu machen (AVM FW + Freetz-NG). Der Integrations- bzw. Verifikationstest kommt zum Ergebnis, dass die Integration von vsftpd im Moment Abstürze bei der 7520/7530 verursacht. Da die AVM FW nicht geändert werden kann, muss eine Lösung entweder in Freetz-NG oder vsftpd gefunden werden. Dafür ist es erforderlich zunächst die Ursache zu finden.
 
Diese Schlussfolgerung ist aus meiner Sicht nicht zulässig.
Ganz einfach, wäre es ein generelles freetz-ng Problem wäre es bei ALLEN box, das habe ich wieder legt, es ist also ein Problem wo 2 User mit einer bestimmten Box haben, das nenne ich ein Box spezifisches Problem.
 
Ganz einfach, wäre es ein generelles freetz-ng Problem wäre es bei ALLEN box, das habe ich wieder legt, es ist also ein Problem wo 2 User mit einer bestimmten Box haben, das nenne ich ein Box spezifisches Problem.
Bisher hast Du nur gezeigt, dass es bei der 6590 nicht auftritt. Bitte bedenke, dass es unterschiedliche Architekturen mit unterschiedlichen Prozessoren, Kernelversionen usw. gibt und Freetz-NG den Anspruch hat, unterschiedliche Boxen zu unterstützen. Ansonsten würde es bedeuten, dass Freetz-NG nur einen Boxtyp unterstüzt, nämlich die Fritzbox 7590, welche Cuma zum Testen nutzt. Stell Dir bitte vor, dass Deine Box mit Freetz-NG ständig Resets produziert. Würdest Du dann sagen, dass es ein Problem von einem Benutzer mit einer bestimmten Box ist, weil es auf der 7590 läuft? Was würdest Du sagen, wenn Du bisher Freetz-NG nutzen konntest und Deine Box erst mit einer neuen Freetz-NG Version abstürzt?

In https://www.ip-phone-forum.de/threads/freetz-ng-fehler-und-probleme.309949/post-2422484 habe ich versucht zu beschreiben, welche Vorteile die Benutzer von Freetz-NG haben können, wenn wir uns hier austauschen. Es geht also nicht darum, Probleme zu finden, die auf allen Boxen auftreten, sondern Ursachen von Problemen zu finden und mögliche Lösungen oder Workarounds, auch wenn sie nur auf bestimmten Boxen auftreten. Wenn Du möchtest, kannst Du gerne #5 im verlinkten Beitrag nachtesten. Dieses Problem tritt zumindest bei 7520/7530/7590 und vielleicht auch bei Deiner Box auf. Vielleicht funktioniert es zufällig bei Deiner Box ist das dann auch unerheblich, weil dies kein Problem bei allen Boxen ist?
 
Zuletzt bearbeitet:
Bisher hast Du nur gezeigt, dass es bei der 6590 nicht auftritt.
Generelles Problem = alle Boxen
Stell Dir bitte vor, dass Deine Box mit Freetz-NG ständig Resets produziert. Würdest Du dann sagen, dass es ein Problem von einem Benutzer mit einer bestimmten Box ist, weil es auf der 7590 läuft?
Ja, weil es seine Box eben NICHT macht.
Was würdest Du sagen, wenn Du bisher Freetz-NG nutzen konntest und Deine Box erst mit einer neuen Freetz-NG Version abstürzt?
Fehler Melden. "Leute ich brauch mal eure Hilfe, meine Box, vorher freetz.ng bla habe ich heute auf freetz.ng geupdatet, ich hab schon probiert, ein Image ohne meine Änderungen, aka minimal Image, hat leider nichts gebracht."
Oder " "Leute ich brauch mal eure Hilfe, meine Box, vorher freetz.nb bla habe ich heute auf freetz.ng geupdatet, ich hab schon probiert, ein Image ohne meine Änderungen, aka minimal Image, da geht es, ich hab folgende Änderungen gemacht, hat jemand das selbe oder ähnliches Problem?"
Und wenn es keine Lösung gibt, Downgrade auf die letzte laufende Version!

Als ich meine 6591 bekommen hatte, hab ich meine 6590 zum Repeater gemacht, da stand ich zwischen der Wahl, freetz nutzten und auf WLAN MESH verzichten (keine Verbindung zur 6591 als Repeater möglich) oder vorerst auf freetz verzichten und dafür sie als Repeater einsetzten.
Lösung, auf freetz verzichtet bis es ging.
 
Das ist Deine Entscheidung. Ich investiere meine Zeit gerne, um um das Projekt voranzubringen. Sicher findest Du auch meine Pull Requests im Freetz-NG Git. Welchen Beitrag hast Du bisher geleistet [...]?

Edit DM41: Persönliche Bemerkung entfernt.
 
Zuletzt bearbeitet von einem Moderator:
Vielleicht wird es etwas übersichtlicher, wenn Du mal mit one_process_model=yes (https://github.com/InfrastructureSe...ebf1028075d493cb9bae086dda4c3/parseconf.c#L47) in der Konfiguration arbeitest.
Mit one_process_model=yes wird nur anonymous ftp unterstützt. Dazu darf nur die Freetz Option "Anonymes FTP" aktiviert sein, sonst werden keine Benutzer akzeptiert. Wenn ich die Einstellung entsprechend gesetzt habe kann ich mich mit dem Benutzer anonymouse oder ftp und beliebigem Passwort einloggen. Dabei stürzt die Box nicht ab. Auf Inhalte von /home/ftp kann ich lesend zugreifen, allerdings nicht schreiben.
Code:
root@fritz:/var/mod/home/ftp# cat /var/mod/etc/vsftpd.conf
background=yes
check_shell=no
listen=yes
anonymous_enable=yes
local_enable=no
local_umask=022
chroot_local_user=no
passwd_chroot_enable=no
write_enable=yes
nopriv_user=root
secure_chroot_dir=/var/run/vsftpd
listen_port=21
userlist_enable=yes
anon_root=/mod/home/ftp
xferlog_std_format=no
xferlog_enable=yes
vsftpd_log_file=/var/media/ftp/vsftpd.log
log_ftp_protocol=yes
syslog_enable=no
max_clients=25
max_per_ip=5
pasv_min_port=0
pasv_max_port=0
pasv_promiscuous=no
delay_failed_login=15
chroot_list_enable=yes
ssl_enable=no
ssl_sslv2=no
ssl_sslv3=no
ssl_tlsv1=no
force_local_data_ssl=no
force_local_logins_ssl=no
one_process_model=yes
Ein trace mit diesem Process Model mit anderen Benutzern, z.B. root, kann ich deshalb leider nicht erstellen. Wenn ich mich im Multi Process Modell mit anonymous oder ftp anmelde stürzt die Box ebenfalls ab. Ein sauberer Crashlog liegt bei. Ich hatte unmittelbar vor dem Crash die support-Daten zum Löschen gespeichert.

Das Entfernen von 901-ignore_munmap_error.patch ändert sich das Verhalten nicht.

Die Multiprocess Traces, welche mit -ff in Datein abgelegt werden, sehen genauso aus, wie ich bereits gepostet habe.
 

Anhänge

  • support FRITZ.Box 7520 175.07.25_01.01.70_0101.txt
    127.9 KB · Aufrufe: 3
Zuletzt bearbeitet:
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.