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.
