Du bist nicht angemeldet.
7270v3 ist sicher schonmal eine gute Entscheidung, läuft ganz passabel.
FW 6.05 ist die neueste, hat aber keine debug.cfg mehr. Daher ist die Installation etwas komplizierter. Entweder FW modifizieren, um debug.cfg wiederzubekommen, oder immer von Hand über telnet starten.
Ich würde dir empfehlen, die FW 5.54 zu installieren. Die hat die Sicherheitslücken aus 2014 schon geschlossen, aber die debug.cfg noch drin.
Telnet scheint noch drin zu sein, nur der Symlink wurde entfernt (wie bei der Debug.cfg)
http://freetz.org/ticket/2748
Also bei meiner 7270V3 (mipsel) und Trunk 2639 läuft dein Testlink auch nicht:
Fritz!Load Revision 2639 wurde gestartet 07.01.2015 22:47:24: ./fritzload.sh i1 -l /var/media/ftp/SanDisk-CruzerBlade-01/FritzLoad/config/dl_jobs1.txt (PID:30171)
22:47:25 Leerzeile
22:47:26 Die Download-Liste wird von der Instanz 1 geblockt.
22:47:26 Die Download-Liste wird nicht mehr geblockt.
22:47:26 Keine UnRAR-Einstellungen (/var/media/ftp/SanDisk-CruzerBlade-01/FritzLoad/config/unrar.ini) sind vorhanden!
22:47:26 ### mega_co_nz-free: https://mega.co.nz/#!Ktt0yBoI!o6k7sOBwsAIEEwavDXHPaUpvA0ieY9J-KEuieNu6Unc
FileId: Ktt0yBoI
Key: e9c638f87e13627c2c58a4d7d6cb9d1e
Nonce: 4a6f03489e63d27e0000000000000000
Apiresponse: [{"s":291,"at":"W6mzdLlxU8nmZhtkS_jxhChk0jl1kMAZfhmQcPC7NMXXBfd4qPOk9c9C3aJdnfZlh6XcZ4sHOY1XFrYdTLvZNA","g":"http://gfs270n068.userstorage.mega.co.nz/dl/-OlcdygsFXcf9QIFYMipy8pUqV9delD-Xa222OxaX3JVOF-C6yAf8k1zo6Q-5RLQL3kt1t39toOlLve1NqinQs7fLYwhgBAJ0KtDP7Ke4qWDvqPhnA"}]
Filesize: 291
Finalurl: http://gfs270n068.userstorage.mega.co.nz/dl/-OlcdygsFXcf9QIFYMipy8pUqV9delD-Xa222OxaX3JVOF-C6yAf8k1zo6Q-5RLQL3kt1t39toOlLve1NqinQs7fLYwhgBAJ0KtDP7Ke4qWDvqPhnA
22:47:28 Download-SchlÃŒssel ungÃŒltig.
22:47:28 Der Download ist fehlgeschlagen!
... versuchs mal mit dem richtigen Shebang:
#!/bin/ash
... aufgrund der beiden genannten FWs 5.54 & 6.05 gehe ich eher davon aus, das er eine 7270V2/V3 hat, da gibts nur die beiden Versionen
Die debug.cfg kann man wohl wieder zurückholen, indem man mit Freetz das Image direkt bearbeitet, und die entsprechenden Zeilen in /etc/init.d/rc.tail.sh wieder einbaut.
siehe:
http://www.ip-phone-forum.de/showthread … ost2013275
http://www.ip-phone-forum.de/showthread … ost2002789
http://freetz.org/wiki/help/howtos/deve … /repack_fw
Ist aber etwas umständlich, zumal Freetz mW nur unter Linux läuft. VM ist natürlich eine Option, schöner wäre es, wenn man ein unter Win laufendes Standalone-Programm kreieren könnte, was die notwendigen Schritte selbständig durchführt...
Scheinbar gibt es noch einen anderen Weg über das Calllog:
http://www.ip-phone-forum.de/showthread.php?t=270948
Damit würde die debug.cfg aber NUR/IMMER bei einem Anruf ausgeführt. IMO eine schlechte Lösung.
Ja, kann passieren...
Danke fürs einchecken! Vielleicht nehme ich mir als nächstes das LED-Problem vor ;-)
Nachdem hier in den letzten paar Tagen ja mal wieder etwas Leben in das Projekt gekommen ist:
Mag einer der Entwickler (rolex0815 ?) meinen Patch auch mal einchecken, oder wird der für untauglich befunden?
... noch keinerlei Feedback?!?
Ist die Änderung für unwürdig befunden worden, oder hat nur noch keiner Zeit gehabt?
Bei einzelnen Dateien ging das recht gut, mit kompletten Verzeichnissen scheint er allerdings ein Problem zu haben.
Nun ist die Datengröße (1,6 TB) die ich kopieren will natürlich auch nicht die geringste, vielleicht liegt es ja daran.
Zumindest sieht das ganze bei mir so aus:
ftp://Benutzername:Passwort@URL/Volume_1/USB_Backup/1111-06-16_08-47-45/USBDisk1_1/Media/Videos/Filme/Kinofilme/ (Tiefe: 1)
Leider macht er da nix, da stehen keine Verbindungsgeschwindigkeiten, keine Dateigröße oder sonstige Informationen.
Wenn ich das richtig verstehe, hast Du F!L den FTP-Link als DL vom lokalen NAS eingetragen.
Auf dem Wege kann man einzelne Files laden, das funktioniert auch.
Der DL ganzer Verzeichnisse ist zwar vorgesehen, aber noch nicht implementiert => kann also nicht funktionieren.
Hallo,
mich hat schon länger gestört, daß lange Dateinamen (ohne Leerzeichen /Bindestrich) nicht umgebrochen werden und die GUI an diversen Stellen im UL & DL zerhauen:
Von daher habe ich mal die Stylesheets angepasst, indem ich die Property "word-break: break-all;" eingefügt habe:
http://ryblog.eu/fritzload/store/183/1373232994_css.7z
Könnte das mal jemand der Entwickler einchecken?
Besten Dank für den schnellen Fix.
Nach ausgiebigem Test des FTP- UL & DL scheint der Fehler nun beseitigt.
Ich habe schon seit geraumer Zeit Probleme mit der FTP-Funktion, sowohl beim UL als auch beim DL.
Dachte, das liegt an einer verwursteten Installation von F!L.
Da ich gerade (wg. Sourceforge-Update) F!L neu aufgesetzt habe (R2451), das Problem aber nach wie vor da ist, hab ich mich entschlossen, mich auch hier mal anzumelden ;-)
Ich beschreib hier mal den DL (UL hat aber ein ähnliches Problem):
Ich versuche, folgende Files zu laden:
ftp://ftp.uni-kl.de/pub/linux/ubuntu-dv … c.template (~50,6MB)
ftp://ftp.uni-kl.de/pub/linux/ubuntu-dv … owerpc.iso (~697MB)
Das kleine File klappt der DL bisher immer auf Anhieb.
Beim großen File gehts nur manchmal. Häufig läuft der DL durch, aber der DL startet dann wieder neu (retry). Das geht so lange, bis der MaxRetry erreicht ist. Das verbliebene .part-File ist aber komplett. Irgendwo scheint beim DL-Abschluß was schiefzugehen.
Debug-Log läßt (für mich ) auch nicht viel erkennen:
(...)
####################################################
16:34:08 | TITEL: DOWNLOAD-MAIN | URL-ADRESSE: ftp://ftp.uni-kl.de/pub/linux/ubuntu-dvd/releases/12.10/release/ubuntu-12.10-server-powerpc.iso | OPTIONEN: --retry 5 -C -
| KOMMANDOZEILE: [/var/media/ftp/SanDisk-CruzerBlade-01/FritzLoad/bin/7270/curl -A 1 --location --speed-limit 500 --speed-time 400 --limit-rate 1000000k --retry 5 -C - --user-agent Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0; chromeframe/26.0.1410.43) --dump-header /var/tmp/fritzload1/dl.head --output /var/media/ftp/SanDisk-CruzerBlade-01/UL_DL/tmp/ubuntu-12.10-server-powerpc.iso.part ftp://ftp.uni-kl.de/pub/linux/ubuntu-dvd/releases/12.10/release/ubuntu-12.10-server-powerpc.iso 1>/var/tmp/fritzload1/dl.code 2>/var/tmp/fritzload1/dl.progress]
HEAD:
+ local file_start_size=0
+ [ -f /var/media/ftp/SanDisk-CruzerBlade-01/UL_DL/tmp/ubuntu-12.10-server-powerpc.iso.part ]
+ filesize /var/media/ftp/SanDisk-CruzerBlade-01/UL_DL/tmp/ubuntu-12.10-server-powerpc.iso.part
+ /var/media/ftp/SanDisk-CruzerBlade-01/FritzLoad/bin/7270/busybox stat -c %s /var/media/ftp/SanDisk-CruzerBlade-01/UL_DL/tmp/ubuntu-12.10-server-powerpc.iso.part
+ file_start_size=13365888
+ /var/media/ftp/SanDisk-CruzerBlade-01/FritzLoad/bin/7270/curl -A 1 -C - --retry 3 --retry-max-time 0 --location --speed-limit 500 --speed-time 400 --limit-rate 1000000k --user-agent Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0; chromeframe/26.0.1410.43) --insecure --dump-header /var/tmp/fritzload1/dl.head --output /var/media/ftp/SanDisk-CruzerBlade-01/UL_DL/tmp/ubuntu-12.10-server-powerpc.iso.part ftp://ftp.uni-kl.de/pub/linux/ubuntu-dvd/releases/12.10/release/ubuntu-12.10-server-powerpc.iso --globoff --write-out %{http_code} --retry 5 -C -
17:34:32 [Abbruch]-Knopf wurde gedrückt.
Kompletten DL-Log kann ich bei Bedarf uppen.
Nachtrag:
Wie ich gerade noch festgestellt habe, kommt beim retry irgendwann die Anzeige "Der Fritz!Load-Prozess wurde beendet.",, und in DL/Monitor wird auch nix mehr angezeigt. Der Retry-Prozeß ist aber noch aktiv. Vielleicht kommen daher auch keine weiteren Debug-Einträge...