IN-9008FullHD überträgt keine Daten mehr auf FTP Server

Nach einem FW Update gibt es keine Übertragung mehr auf meinen FTP-Server.
Es gibt schon einen Post vom Anfang des Jahres, welcher als Lösung das Einspielen einer neuen FW angibt.
Das klappt bei mir aber nicht.

Dieses Update war durch das UI angeboten:
(1) WebUI Version 3.3(378)
(2) FW-Version: 4.1.2.48

Nach dem Update (das in seinem Änderungs-Log von Korrektur in FTP Bereich spricht) geht nun keine FTP-Übertragung mehr.
System-Log zeigt keinen Übertragungsversuch.

Den FTP Server habe ich schon vor Jahren auf meinem ASUS Router eingerichtet und ihn jetzt wieder mit FileZilla (FTP-Client) geprüft. Der FTP-Server arbeitet perfekt!

Zur Kamera:
Der FTP Server war bisher mit seinem DDNS Namen angegeben (von mir reservierter Web-Name und dieser Name hat auch eine erfolgreiche public IP-Auflösung).
Das führte bei einer Test-Übertragung zu „Server not found“.
Habe daher die lokalen IP Adresse eingetragen. Das führte zu keinem Fehler, aber auch nicht zu einer Übertragung.
Kein Eintrag im System-Log der Kamera.

Daher letzte verfügbare Firmware von Instar-Download-Bereich heruntergeladen („PoE FW 4.1.2.48 WebUI 3.3 (373)“) und manuell eingespielt per Web-UI (das ist also eine ältere Software).

Der DDNS-Eintrag Auflösung geht immer noch nicht. Also wieder lokale IP.

Ergebnis:
(1) Testen-Button und kein Fehler, aber auch kein Log-Eintrag.
(2) Alarm ausgelöst (in Bereich gelaufen) und System-Log: „Snapshot an FTP gesendet“ und „Video an FTP gesendet“.
(3) Aber nichts auf FTP Server übertragen.

FTP-Angaben in Kamera:

  • FTP-Server: 198.168.1.1 (da war mal der DDNS-Name gestanden)
  • FTP-Port: 21
  • Verschlüsselung: TLS
  • Modus: PASV
  • Speicherpfad: /FTP/Kameras (diesen Pfad gibt es auf dem FTP Server bereits)
  • Benutzername: …mein FTP User…
  • Kennwort: …mein FTP-PW…
    Der Benutzername und Kennwort habe ich exakt so in FileZilla erfolgreich verwendet für Test-Upload.

Weiter:
Per Test-Button passiert sowieso nix.
Daher mal absichtlich falschen User eingetragen, Alarm ausgelöst.
In System-Log wieder erfolgreich an FTP übertragen.
Aber auf FTP-Server: nix.
Nebenbei: Mail und Push geht.

Zum Router- / FTP-Server-Setup noch folgendes:
Warum habe ich PASV (passiv) Modus gewählt? Der FTP-Server teilt dem Client (Kamera) in diesem Modus mit auf welchem Port er Daten erwartet. Diesen Port verwendet der Client (Kamera) dann zur Übertragung an FTP-Server (der bleibt also passiv in diesem Fall). Dieser Modus funktioniert i.d.R. besser als der Modus PORT (hier würde der Server sich mit dem Client aktiv verbinden), denn mit NAT und Firewall im Einsatz kann es hier eher zu Problemen führen (heißt, er würde den Client nicht finden).

Wegen dem PASV Modus habe ich noch Portforwarding im Router einschalten müssen (riesige Port-Range 50000-58000 dafür freigeschaltet) und die lokale IP meines FTP-Servers (also meines Routers) angegeben als Mapping-Ziel.

Jetzt bin ich ratlos was ich noch machen kann.
Hat jemand noch eine Idee?

Hallo,

ich habe dazu momentan keine begründete Idee, vielleicht nur einen Versuch. Wenn der Router nicht aus irgendeinem Grund die Kamera gesperrt hat, kann es vielleicht auch an Pfaden liegen?
Vielleicht gibt es beim Ausprobieren weitere Hinweise.

Danke!
Habe Idee des verlinkten Posts benutzt, d.h. Verschlüsselung auf „SSL“ in FTP-Einstellung geändert, Test ok.
Anschließend auch wieder meinen usprünglichen DDNS Eintrag genutzt für FTP-Server, damit Test auch ok.

Aber leider werden nun nur leere Dateien (avi+jpg) zum FTP-Server übertragen (check per FileZilla Client und selben Anmeldungsdaten wie in FTP-Einstellung in Kamera).

Testweise einen neuen User und Ordner (mit r/w Rechte für den neuen User) auf dem FTP-Server angelegt, in Kamera unter FTP benutzt und Test: Die Dateien werden auch mit dem neuen User und Ordner leer übertragen.

Mit leeren Dateien kann man wenig anfangen.

Die SD-Karte erhält alle Dateien korrekt.

Vielleicht hat jemand noch eine Idee?
Danke.

Habe nochmal getestet. Wenn ich die FTP-Verschlüsselung ausschalte („Verschlüsselung“: „Keine“), dann geht der FTP-Upload.
Keine gute Lösung da potenielles Sicherheitsproblem, aber aktuell erstmal ausreichend für mich.

Eine leere Datei weist oft darauf hin, daß mit der zweiten FTP-Verbindung etwas schief ging. Wie Du ganz oben beschreibst, unterscheidet FTP ja zwischen Control- und der Daten-Verbindung. Die neue Datei wird angelegt von der Control-Verbindung. Gefüllt wird die Datei aber erst durch die zweite, die Daten-Verbindung. Schlägt diese zweite Verbindung fehl, dann bleibt die leere Datei übrig.

Mir ist noch nicht klar, wie Dein Netzwerk aussieht: Das alles, Kamera und FTP-Server, befinden sich in Deinem lokalen Netz, richtig? Warum verwendest Du dann den DynDNS-Namen, um den FTP-Server zu adressieren?

Die IP ist dabei keine Hilfe, weil dann die Verschlüsselung nicht funktioniert: Nur mit IP kann die Kamera nicht beurteilen, ob das Zertifikat passt - dieses ist schließlich auf einen DNS-Namen ausgestellt, nicht auf eine IP. Aber wenn Du den Traffic zuerst nach extern schickst (indem Du den DynDNS-Namen verwendest) handelst Du Dir u.U. alle möglichen Komplikationen ein. Auch die Portfreigaben, die Du erwähnt hast, hängen damit zusammen und machen alles nur noch schwieriger.

Ich würde als erstes versuchen, im Router einen Namen für den FTP-Server zu vergeben. Ist das in Deinem Asus-Router nicht irgendwie möglich?

MfG

Die Sache mit der verschlüsselten FTP-Übermittlung habe ich (urlaubsbedingt etwas verspätet) wieder aufgenomen.

Vorab zum Netz: Die Kamera und der Router sind im gleichen Netz.

Mein Router kann nur ein Zertifikat haben (von CA „Let’s Encrypt“ signiert und passend zu meinem DDNS-Eintrag).
TLS funktioniert einwandfrei hier.

Die Kamera hat aktuell auch nur ein Zertifikat (von CA „Go Daddy“ signiert). Das wurde auch erneuert beim Letzten Update der Firmware+WebUI (so stehts auch im Changelog). Die Firmware+WebUI ist jetzt die neuste Version.

Nun, die Zertifikate-Liste von Kamera und Router passen offensichtlich nicht zusammen, damit kein TLS für FTP.

Nächster Schritt (Versuch):
Weiteres Zertifikat in Kamera laden (nämlich das exportierte vom Router). Das geht nicht.

Im Browser Trace steht zwar für den POST Request, dass dieser erfolgreich war (RC=200, Body: Upload succeed"), aber das installiert nicht das Zertifikat. Der Request Body enthält die Zertifikate-Chain korrekt (also die Info des exportierten Router Zertifikats). Die URL ist http:///cert.cgi?-filename=.
Habe in weiterem Versuch die Zertifikate Chain auf das (root) Zertifikat verkürzt, was das selbe Ergebnis hat.

Am WebUI steht dabei für immer „Bitte warten“. Das WebUI bleibt responsive, aber dieses animated, nicht-modale Overlay-Element steht dort und auf jeder Folgeseite der Kamera bis zu einem Logout. Es handelt sich hier offenbar um einen UI-Fehler, der nicht korrekt das Ergebnis des vorherigen Operation auswertet um das Overlay zu eliminieren.
Sicher ist, dass das Zertifikat nicht in der Zertifikate-Store der Kamera übertragen wird. Denn bei neuem Kamera-Login gibt es kein weiteres/custom Zertifikat.

Mit einem REST-Client und zusätzlich mit curl habe ich den Zertifikat-Upload versucht (per POST Request).
Dafür die Infos aus dem Browser Trace benutzt um den passenden Request zu bauen.
Diese Requests liefern keinen Fehler, kehren aber auch nicht zurück (nicht bei REST und nicht bei curl).

Zusatz: Im Kamera System-log steht seit geraumer Zeit folgendes (mehrfach, aber nicht wiederholend):
„warning: ini file(config/platform.ini) not found!!!“

Hier im Forum (sehr alte) Beiträge gefunden, die einen Werks-Reset empfehlen. Dieser soll fehlende Dateien auf dem Filesystem der Kamera neu aufbauen. Der Werk-Reset des WebUI behebt das Fehlen der ini-Datei nicht bei mir. Der Syslog-Eintrag bleibt unverändert.

Aber ein HW Reset, also direkt an der Kamera, soll dies angeblich beheben.

Ist dem tatsächlich so?

Letzteres würde bedeuten, dass ich die in 5m Höhe montierte Kamera besuchen müsse, was ich nur mache, wenn ich mir einigermassen sicher bin, dass das irgendwie Erfolg haben könnte.

Letzendlich bleibt es auch offen, ob ein HW-Reset das Problem mit der ini-Datei löst und ob das auch das Upload Problem behebt.

In jedem Fall ist die Kamera-Firmware/WebUI eine bug-Kiste.