[Erledigt] SFTP server error [7590]

[mortimar]

Hallo Zusammen,

Problem
ich möchte gerne die fx_lcr Datei editieren und da der FBEditor für die 7590 nicht mehr zu funktionieren scheint,
habe ich für meine 7590 freetz mit Dropbear erstellt, inklusive SFTP Server.

Die Verbindung via WINSCP funktioniert.
Via WINSCP kann ich in die Verzeichnisse springen aber
- alle Dateien in /var/flash/ sind nur 0 Byte groß
- in putty werden die Dateien mit größer 0 Byte angezeigt
- auch kann ich die Dateien via cat problemlos anzeigen, wofür steht hier eigentlich das 'c' bei 'crw-r--r--'

Versuche ich dennoch eine Datei in WINSCP zu öffnen, sehe ich im syslog folgende Fehlermeldung:
"fritz auth.err sftp-server[9051]: error: process_read: seek failed"

Hat jemand eine Erklärung für das Verhalten?
Freetz Image wurde erstellt mit trunk 14604, sprich dropbear Version 2018.76


Workaround und Frage
Ich werde die Binärdatei erstmal via cat /var/flash/fx_lcr > /var/tmp transferieren.
Die kann ich mir dann in einem HEX Editor anpassen und wieder zurückspielen.
Muss nach dem Zurückspielen auch bei dieser Datei 'ar7cfgchanged' abgesetzt werden? Gefühlt nein, bin aber diesen Weg des editierens von Dateien unter /var/flash noch nie gegangen.

Vielen Dank schonmal im Voraus.

Bye morT

 

[meiser79]

c = character device.

Man kann die Dateien nicht direkt editieren, daher gibt es auch "nvi" bei freetz.

 

[mortimar]

Ich wollte einen Bogen um vi /nvi machen und hatte dazu 'nano' mit ins freetz gepackt.
Hatte aber nach 'nano /var/flash/ar7.cfg' nur ein leeres Fenster mit der Info [ "ar7.cfg" is not a normal file ] bekommen.

Ich denke ich bleibe dann bei meinem Workaround mit dem Kopieren, da ich dann auch einen HEX-Editor nutzen kann.

Vielen Dank für die Antwort.

 

[Joe_57]

Leg doch einfach eine Kopie der Datei an:
cat /var/flash/ar7.cfg > /var/tmp/ar7.cfg
Nun kannst du diese Kopie mit einem beliebigen Editor bearbeiten und mit
cat /var/tmp/ar7.cfg > /var/flash/ar7.cfg
wieder Zurückschreiben.
Genau so macht das auch der nvi.
Wichtig: zum Kopieren nicht cp verwenden, sondern nur cat, damit das c-device keinen Schaden nimmt.

 

[koyaanisqatsi]

Moin

Der "Editor" nvi ist nur ein Skript.
Lass dir nvi doch mal mit cat anzeigen.
...dann kannst du dir eventuell sowas auch für nano basteln.
...oder das Editieren mit cat und nano in Einzelschritte erledigen.

Für die "c" Dateien, besonders im Zusammenhang mit Fritz!Box find ich diesen Thread lesenswert...
https://www.ip-phone-forum.de/threads/vi-und-nvi-auf-der-fritzbox.68201/

 

[mortimar]

Leg doch einfach eine Kopie der Datei an:

Danke für die Rückmeldung. Habe dieses Vorgehen bereits als meinen 'Workaround' im Eröffnungspost geschildert.
Auch an @koyaanisqatsi vielen Dank.

Werde aber wie geschrieben bei meinem Workaround bleiben, da ich auf der Fritzbox keinen HEX-Editor habe. Der macht das Editieren der fx_lcr doch etwas einfacher.

Danke nochmal an alle. Ich hab den Thread bereits als für mich erledigt im Titel markiert.

bye morT

 

[PeterPawn]

Ich kann nur noch einmal eindringlich vor "nvi" warnen ... die Zeiten, in denen das noch einigermaßen funktionierte, sind vorbei und zwar nicht deshalb, weil das Kopieren oder Editieren oder Zurückschreiben nicht funktionieren würde, sondern weil einem (speziell bei den häufig genutzten Konfigurationsdateien) danach eigentlich nur der direkte Neustart (und zwar mittels "Power-Off" oder über "sysrq-trigger", also ohne Chance für die Box, die Daten noch einmal zu überschreiben) bleibt und dabei riskiert man dann wiederum, daß die Änderungen noch gar nicht wirklich im TFFS gelandet sind (weil AVM da im TFFS3 auch weiteres Caching eingebaut hat - vermutlich damit nicht jede einzelne Änderung umgehend wieder in den Flash schreibt).

Der einzige, zuverlässige Weg in neuer Firmware ist es, beim Zurückschreiben der geänderten Datei den "ctlmgr" zu stoppen - nur das kann ihn daran hindern, irgendwann seine internen (gecachten) Inhalte wieder in die TFFS-Nodes zu schreiben, wenn die nächste Änderung ansteht. Danach kann/muß man ihn wieder starten ... aber all die alten Tipps - z.B. das "ar7cfgchanged" - funktionieren so nicht mehr, weil eben dabei der "ctlmgr" gerade nicht gestoppt wird.

Ein weiterer Nachteil des "nvi" ist es, daß die Datei in jedem Falle wieder ins TFFS kopiert wird ... auch dann, wenn man gar nichts geändert hat und "nvi" nur zum Einblick in die Datei verwenden wollte (so ein Editor taugt ja auch gleichzeitig als Pager, was bei einer längeren Datei wie der "ar7.cfg" auch nicht unangenehm ist) - im schlechtesten Falle überschreibt man dabei andere zwischenzeitliche Änderungen durch die Firmware.

Wenn man das wirklich halbwegs sinnvoll (ohne überflüssiges Schreiben) und sicher (mit gestopptem "ctlmgr") machen will, kann man z.B. das "tvi"-Skript aus meinem GitHub-Repo verwenden - das dekodiert einem dann auch gleich noch die verschlüsselt gespeicherten Daten (wenn das Programm dazu installiert ist) und testet mit einer MD5-Prüfsumme, ob die Datei überhaupt geändert wurde im "vi". Ist das der Fall, muß man das Zurückschreiben explizit bestätigen und wenn die Datei auf ".cfg" endet (was praktisch alle vom "ctlmgr" gecachten Dateien betrifft), wird vor dem Speichern auf Wunsch noch der "ctlmgr" angehalten und im Anschluß neu gestartet.

Dann kann man immer noch sein "ar7cfgchanged" aufrufen, wenn die Änderungen irgendeine laufende Komponente betrafen. Allerdings bleibt auch da die "Lücke" zwischen dem Kopieren aus dem TFFS und dem Zurückschreiben bestehen, in der weitere Änderungen durch die Firmware stattgefunden haben könnten ... die Firmware schreibt inzwischen deutlich öfter irgendwelche persistenten Daten als früher, angefangen bei der Nutzungsstatistik für einzelne Geräte/Benutzer (wenn die Filterung verwendet wird) bis zu den Ergebnissen irgendwelcher Update-Prüfungen.

Wer also in der Lage ist, solche Änderungen zu automatisieren (und damit diese Lücke auf wenige Sekunden zu drücken), der sollte das auch tun ... den Aufruf des "vi" im Skript gegen ein "sed" o.ä. auszutauschen (und die ganze Fragerei zu streichen), ist ja keine wirkliche Kunst bzw. ein neues Skript ist vermutlich sogar wieder der schnellere Weg, das könnte dann den "ctlmgr" auch gleich vor dem Herauskopieren anhalten und erst nach dem Zurückschreiben (was ein "sed" gleich mit übernehmen kann - oder man setzt das zum Auslesen ein ... auf alle Fälle kann "sed" mit "char devices" umgehen) wieder starten.

 

[mortimar]

Ich kann nur noch einmal eindringlich vor "nvi" warnen ...

Danke dür den Hintergrundbeitrag.
Ich versuche mal kurz und knapp wiederzugeben, was ich daraus für mich mitgenommen habe,
bezogen auf den o.g. Workaround gegenüber direktem editieren auf der FritzBox.

Und da ich es nicht so mit dem Skripteschreiben habe sondern mehr Fensteranwendungen mag, hier mal mein Vorgehen Schritt für Schritt mit einem Windows7:

1. mit 'putty' auf die Box und zu bearbeitende Konfigdatei mit cat kopieren (putty bleibt offen)
   z.Bsp.: cat /var/flash/ar7.cfg > /var/tmp/ar7.cfg
2. ab jetzt nichts mehr via WebIF ändern
   

   zwischenzeitliche Änderungen durch die Firmware

   die würde ich vernachlässigen oder wenn Du da zur Vorsicht rätst, optional einfach die Internetverbindung (Kabel) kappen, um solche Änderungen zu minimieren?!
3. mit WinSCP auf die Box und '/var/tmp/ar7.cfg' mit WinSCP eigenem Editor editieren und am Ende speichern
   
4. zurück in putty dann 'ctlmgr -s' ausführen, um ctlmgr zu stoppen
5. Konfigdatei wieder zurückspielen via 'cat /var/tmp/ar7.cfg > /var/flash/ar7.cfg'
   
6. reboot

Voraussetzung für obiges Vorgehen: laufendes Freetz Image auf der Box mit SFTP support im Dropbear für den Dateitransfer (damit das editieren klappt)


Das ist nicht automatisiert aber hat für mich schon funktioniert.
@PeterPawn, wäre das auch ein "zuverlässiger Weg"?

Vielen Dank

 

[PeterPawn]

Entscheidend ist, daß der "ctlmgr" beim Zurückschreiben nicht läuft ... das muß man irgendwie sicherstellen und weil es bei "nvi" nicht geschieht (es sei denn, man macht es vor dem Aufruf von "nvi"), ist von dessen Einsatz auch abzuraten.

Solange Du das machst (nach #8 ist das so), sollte es auch funktionieren ... ansonsten gibt es hier auch genug Erfahrungsberichte, wo solche Aktionen bei laufendem "ctlmgr" eben nicht funktioniert haben und wenn man ihn erst im Anschluß stoppt, schreibt er (fast regelmäßig) noch die letzten, intern gecachten Änderungen in die Datei - womit dann die eigenen Änderungen auch wieder weg wären. Der Weg über "Strom aus" ist auch unzuverlässig (weil man den richtigen Zeitpunkt erwischen muß und auch nicht weiß, ob nicht nach dem eigenen Speichern das System noch einmal geänderte Daten schreiben wollte/will) und der von mir beschriebene Weg bringt reproduzierbare und damit vorhersagbare Ergebnisse.

Das richtete sich jetzt auch gar nicht in erster Linie an Dich (ich finde das Bearbeiten mit "winscp" schon sehr merkwürdig und würde diesen Weg nie wählen) ... es ging mir eher darum zu zeigen bzw. zu erklären, daß/warum "nvi" nur mit zusätzlichen Vorkehrungen genutzt werden kann. Das war ja auch nicht immer so, aber AVM hat eben an der Firmware auch in dieser Hinsicht einiges geändert und es gibt schon Gründe, warum es in der AVM-Firmware gar keinen Aufruf von "ar7cfgchanged" mehr gibt (auch wenn das Skript noch in der Firmware enthalten ist, aber das liegt wohl eher daran, daß AVM da nur selten aufräumt, denn ein "rc.net reload" macht es ja genauso und ist letztlich auch das Einzige, was von "ar7cfgchanged" aufgerufen wurde).