Fritz!Load - (Oneclickhoster-) Down- und Uploads via FB

[Gabris]

Gleiches Problem wie oben.

 

[rolex0815]

Bei mir läuft F!L zwar brav weiter, mit dem gestrigen Update auf 2076 ist die GUI bei mir tot.
Zugriff mit 4 verschiedenen Browsern hat nicht geholfen.

 

[TelefonSparbuch]

FL 2076 beendet sich nicht mehr, sondern hält nach jedem Dateidownload einfach an

Solo0815 und euri haben an der download.sh Änderungen vorgenommen. Beschreibt doch bitte das Problem was genauer, steht es im Zusammenhang mit einem laufendem Upload oder wie ist die Konstellation auf der Box?

2076 ist die GUI bei mir tot.

Den beschriebenen Fehler kann ich derzeit nicht reproduzieren, von daher würde ich anraten ein vollständiges Update durchzuführen und nicht das Differenz-Update.

 

[rolex0815]

Den beschriebenen Fehler kann ich derzeit nicht reproduzieren, von daher würde ich anraten ein vollständiges Update durchzuführen und nicht das Differenz-Update.

Danke, werd ich machen.
Aber interessant zu wissen wäre schon, warum er da seine Funktionen nicht mehr findet, kommt mir ein wenig wie Voodoo vor.

EDIT: Mit dem Komplettupdate passt jetzt wieder alles, das Warum bleibt noch immer offen.

 

[roadman17]

Um die Ursache des Hängens nach einem Download zu ermitteln, wäre ein Debug-Log hilfreich.

 

[zupipo]

Gern, ich werde mal ein paar Links heraussuchen und Dir das debug per PN schicken. Auffällig ist noch eine hohe Prozessorauslastung der Box bei beendetem (gekilltem) FL von 96% und sehr langsame Dateitransfers zum PC von ca. 1,3 MB/s gegenüber vorher ca. 5 MB/s. Erst einmal mache ich ein Komplettupdate und einen Kaltstart der Box.

edit: Jetzt ist die Prozessorauslastung schon mal auf 70% runter gegangen!

 

[Solo0815]

Noch weitere Infos:
Freetz svn 8691(?) 54.05.21 - F!L svn2078
Dateitransfer über NFS, da SMB/CIFS mit der neuesten FW (noch) nicht geht.
was mir mit "top" noch aufgefallen ist:

7233  7228 root     R     1620   3%  28% /var/media/ftp/uStor01/fritzload/bin/busybox awk {print $4}
15550 15544 root     R     1620   3%  24% /var/media/ftp/uStor01/fritzload/bin/busybox awk {print $4}
16669 16664 root     R     1620   3%  24% /var/media/ftp/uStor01/fritzload/bin/busybox awk {print $4}

Ist da was mit der BusyBox nicht in Ordnung? "BusyBox v1.19.4 (2012-05-02 10:30:31 CEST) built-in shell (ash)"

Nachtrag #1:

+ /var/media/ftp/uStor01/fritzload/bin/busybox df -k /var/media/ftp/cifs
+ grep -A 1 ^/
+ /var/media/ftp/uStor01/fritzload/bin/busybox grep -A 1 ^/
+ sed -n :a;$!N;$!ba;s/\n  */ /g;p
+ /var/media/ftp/uStor01/fritzload/bin/busybox sed -n :a;$!N;$!ba;s/\n  */ /g;p
+ four
+ echo
+ DSIZE=
+ ls -l /var/fritzload/downloads/Datei.part05.rar
+ fifth -rwxrwxrwx    1 root     root     524288000 May  3 17:48 /var/fritzload/downloads/Datei.part05.rar
+ echo
+ FSIZE=
+ [  -gt  ]
ash: bad number
+ [  = 1 ]
+ cp /var/fritzload/downloads/Datei.part05.rar /var/media/ftp/cifs/

bad number? Das war vorher (vor Freetz) nicht so. Wirklich was mit der BBox?
ls -l Datei.part05.rar | awk '{print $5}'
liefert das richtige Ergebnis -> Die Dateigröße. Keine Ahnung, ob die beiden Fehler zusammenhängen.

 

[fbfuser]

Hallo,

mir ist ein kleiner Fehler in gui_monitor.cgi aufgefallen.

local linkcount=0 finishcount=0 failcount=0
[ -e $jobFile ] && linkcount=$(grep -c '[ft]tp:' $jobFile)
[ -e $finishedFile ] && finishcount=$(grep -c '[ft]tp:' $finishedFile)
[ -e $failedFile ] && failcount=$(grep -c '[ft]tp:' $failedFile)

Ich hatte Dateien mit https: beginnend in den Listen und diese wurden mit diesen Filtern nicht angezeigt.
Kann man den Code so anpassen?

local linkcount=0 finishcount=0 failcount=0
[ -e $jobFile ] && linkcount=$(grep -c '[ft]tp:' $jobFile)
[ -e $finishedFile ] && finishcount=$(grep -c '[ft]tp:' $finishedFile)
[ -e $failedFile ] && failcount=$(grep -c '[ft]tp:' $failedFile)

Ich habe aus den Listen einfach das s von https entfernt um die korrekten Zahlen zu erhalten

 

[roadman17]

@Solo0815
Laut deiner Ausgabe von top, hängt Fritzload bei dir, wenn du mit der folgenden Zeile

local spacefree_in_mb=$( ${BBox} df -m "$targetdir" | grep -A 1 '/' | sed -n ':a;$!N;$!ba;s/\n  */ /g;p' | ${BBox} awk '{print $4}' )

den freien Speicher in MB bestimmst.

Bestimme es doch einfach etwas anders. Dabei kannst du ja nebenbei auf ein paar Pipes verzichten.

Die Größe einer Datei in Bytes würde ich eher mit

$BBox stat -c %s $file

bestimmen, da die Ausgabe von ls nicht unbedingt auf allen System gleich ist.

 

[redxenja]

Mal ne Frage, könnte jemand der Experten ein Script für Youtube2Mp3 basteln. So z.B. über diese Seite.. http://convert2mp3.net/
Könnte ja mal ne gute Sache sein?

 

[scuba]

Noch weitere Infos:
Freetz svn 8691(?) 54.05.21 - F!L svn2078
Dateitransfer über NFS, da SMB/CIFS mit der neuesten FW (noch) nicht geht.
was mir mit "top" noch aufgefallen ist:

7233  7228 root     R     1620   3%  28% /var/media/ftp/uStor01/fritzload/bin/busybox awk {print $4}
15550 15544 root     R     1620   3%  24% /var/media/ftp/uStor01/fritzload/bin/busybox awk {print $4}
16669 16664 root     R     1620   3%  24% /var/media/ftp/uStor01/fritzload/bin/busybox awk {print $4}

Ist da was mit der BusyBox nicht in Ordnung? "BusyBox v1.19.4 (2012-05-02 10:30:31 CEST) built-in shell (ash)"

Hi,

ich stoße auf das selbe Problem wie Solo0815. Die BBox awk Prozesse laufen Amok, wenn ein Download beendet ist. Der Download wird nicht fortgesetzt.
Wenn ich die Prozesse per telnet-Konsole und kill terminiere, erhalte ich im Log der jeweiligen Instanz ebenfalls die 'ash: bad number' Fehlermeldung.
Ich setze derzeit eine 7270 mit Fritz!OS 5.21 und OHNE freetz ein. Fritz!Load hat die aktuelle trunk-Revision 2082.

Gruß

scuba

 

[Solo0815]

scheint wirklich an awk '{print $4}' zu hängen. Auf der Commandozeile der FB funktioniert es aber ohne Probleme. Gibt es irgendeine andere Möglichkeit die 4. Spalte abzufragen bzw. auszugeben? Mit "stat" hab ich es für ein Dateisystem nicht hingebracht, die Dateigröße funktioniert gut damit.
Mit svn2084 sollte F!L wieder normal laufen - Hab die Zeile, die Probleme macht, auskommentiert.

@ telefonsparbuch:
ich hätte in den Ausgaben der "downloadTransfer.sh" auch so schöne "OK"-Buttons. Wie stelle ich das an? <p class=msg> hab ich schon drin. Zur Zeit sieht mein Code so aus:

echo "<p class=msg>NAS-Downloadverzeichnis in der Config nicht eingetragen. Bitte überprüfen Sie die Einstellungen</p>"

 

[TelefonSparbuch]

Der Bereich, wo die msg Ausgaben ausgegeben werden, muss ein msgBlock Feld haben ( echo -n "<div id=msgBlock>" ...... echo "</div>" )

 

[roadman17]

@Solo0815
Um an das vierte Element zu kommen gibt es durchaus Alternativen, wovon ich eine eingecheckt habe.

Ich habe dir auch smbclient zum Experimentieren angehängt, das ich meinem OpenWRT-Chroot entnommen habe (siehe auch http://www.ip-phone-forum.de/showthread.php?t=245505)

Eine alternative zum cifsmount wäre noch smbnetfs, aber smbclient ist vermutlich einfacher zu verwenden, da es vor allem keinen mount und unmount benötigt.
Mit deinem neuen Freetz-Sytem kannst du dann vermutlich mit

./smbclient //fritz.box/uStor01 -c 'ls'

die Dateien auf deinem USB-Stick auflisten.

 

[Solo0815]

Danke für den schnellen Fix. Wollte mich gerade selbst drüber machen. Ich hätte awk nicht benutzt, wenn es nicht auf der Kommandozeile der FB funktioniert hätte

den smbclient probier ich morgen mal aus. Danke

@ Telefonsparbuch:
Habs jetzt mal so eingebaut:

echo -en "<div id=msgBlock><p class=msg>$1</p></div>"

Passt das so, oder ist das doppelt gemoppelt? Kann das <p class= auch weg?

Noch was:
Wie müsste ein Output in eine Datei aussehen, mit dem man beim Dateitransfer eine Fortschrittsanzeige darstellen kann? Ich hätte da gerne einen Balken dafür
Ist eine Prozentausgabe OK oder müsste das in kB o.ä. sein?

 

[TelefonSparbuch]

<p class=msg>$1</p>

Sollte natürlich nur innerhalb des Divs auftauchen, wenn es eine Meldung gibt. Auch sollte der Div-Block nur einmalig im HTML Code auftauchen - auch wenn es mehrere Message-Ausgaben geben sollte!

Schau Dir die Speedbar Dateien an, ist schwierig das jetzt alles zu erklären...

 

[makaveli187]

Hi!

Ich habe eine 7270v3 mit FRITZ!OS 05.21 und verwende derzeit die V0.42/Rev.: 2093

Kann es sein, dass das mitgelieferte busybox-binary korrupt ist?
Der Befehl

./busybox awk

bleibt mit einer leeren Zeile einfach stehen. Keine Versionsinfo, keine Usage-Ausgabe, nichts.
Mit Ctrl+C kommt wieder das gewohnte '#'.
Ich habe testweise auch eine ältere FL-Version installiert (1835, April 2012), ohne Erfolg...

Ich habe eine zwei ältere binaries aus der ssh-Installation mit "awk" aufgerufen, da kommen die erwarteten Ausgaben:

# ./busybox1.9.0 awk
BusyBox v1.9.0 (2008-01-16 01:35:36 CET) multi-call binary

Usage: awk [OPTION]... [program-text] [FILE...]

Options:
        -v var=val      Set variable
        -F sep          Use sep as field separator
        -f file         Read program from file

bzw.

# ./busybox26 awk
BusyBox v1.16.0 (2010-04-30 16:54:08 CEST) multi-call binary.

Usage: awk [OPTIONS] [AWK_PROGRAM] [FILE]...

Options:
        -v VAR=VAL      Set variable
        -F SEP          Use SEP as field separator
        -f FILE         Read program from FILE

In der Fritzload ist derzeit diese Version

BusyBox v1.18.4 (2011-04-04 19:55:06 CDT)

daher dachte ich auch nicht wirklich, dass eine FL-Version von April 2012 eine Änderung bringt...

EDIT:
Ich habe die 1.18.4 frisch von busybox.net runtergeladen, der filecompare ergab keine Unterschiede.
Daraufhin habe ich die 1.19.0 runtergeladen. Die hat aber das gleiche Fehlerbild.
Habe dann alle verfügbaren Versionen (1.16.0, 1.16.1, 1.17.2 und 1.18.0) runtergeladen. Alle haben das gleiche Fehlerbild.

Komischerweise, funktioniert ja das awk mit der 1.60.0 aus meiner ssh-Umgebung.
Ich weiss nur nicht, woher ich die habe und welche switches bei dieser gesetzt sind...


EDIT2:
Ich habe die busybox durch die v1.16.0 aus meiner ssh-Umgebung ersetzt. Der wireshark-decrypter findet zwar immer noch nichts, aber er bleibt zumindest nicht hängen.
Kann jemand sagen, ob die 1.18 zwingend notwendig ist, oder ob die 1.16 auch tut?
Wollte die Datei anhängen, aber irgendwie funktioniert der Upload nicht. Ich ermittle gleich mal die unterschiedlichen Befehle.


EDIT3:
Habe die Versionen verglichen:

Diese Befehle fehlen in BusyBox v1.16.0

acpid, add-shell, adjtimex, arp, base64, beep, blkid, blockdev, bootchartd, brctl, bzip2, cal, chat, chpasswd, chpst, comm, cryptpw, cttyhack, depmod, dhcprelay, dumpleases, ed, envdir, envuidgid, expand, fakeidentd, fbset, fbsplash, fdisk, fgconsole, findfs, flock, fsck.minix, fsync, ftpd, ftpget, ftpput, hd, httpd, hush, ifenslave, ifplugd, ionice, iostat, ipcalc, kbd_mode, logread, lpd, lpq, lpr, lzcat, lzma, lzop, lzopcat, makemime, man, microcom, mkdosfs, mke2fs, mkfs.ext2, mkfs.minix, mkfs.vfat, mkpasswd, modinfo, mpstat, nbd-client, nc, nmeter, ntpd, pgrep, ping6, pkill, pmap, popmaildir, powertop, pscan, raidautorun, rdev, readahead, reformime, remove-shell, rev, rpm, rpm2cpio, rtcwake, runsv, runsvdir, rx, script, scriptreplay, sendmail, setfont, setuidgid, showkey, slattach, smemcap, softlimit, split, stat, sum, sv, svlogd, tac, tcpsvd, telnetd, tftpd, timeout, traceroute6, ttysize, tunctl, udhcpd, udpsvd, unexpand, unlzop, unxz, volname, wall, xz, xzcat, zcip

Sieht jemand auf Anhieb, ob ein verwendeter Befehl darunter ist?


Der Vollständigkeithalber, diese Befehle fehlen in BusyBox v1.18.4

ar, flash_eraseall, flash_lock, flash_unlock, flashcp, lzmacat

Werde im Anschluss mal suchen, woran der decrypter scheitert...


EDIT4:
So, der wireshark-decrypter funktioniert jetzt auch.

Ich hatte "Paketmitschnitt ohne DSL-Rahmen (Standard)" eingestellt gehabt. Da scheint die FritzBox ein anderes Protokollformat auszuspucken.
Es kommt die Meldung (wie schon mal hier von jemandem berichtet):

tcpdump Meldung:
reading from file /var/media/ftp/JetFlash-Transcend16GB-01/downloads/wireshark.eth, link-type 14
tcpdump: unknown data link type 14

Wireshark (Windows) kann diese Datei jedenfalls öffnen und ich sehe auch die Links. Wireshark sagt aber das Format der Protokolle als "Modified tcpdump - libpcap" an.
Speichere ich die geöffnete Datei im Format "Wireshark/tcpdump - libpcap", so kann FL plötzlich alles entschlüsseln.

Die Lösung ist aber noch einfacher. Ich habe in FritzLoad das Protokoll auf "lan - Paketmitschnitt Interface" eingestellt".
Wireshark gibt das Format zwar immernoch als "Modified tcpdump - libpcap" an, aber der decrypter meldet keine fehler mehr und entschlüsselt die Links, Heureka!

An dieser Stelle nochmals: HAMMERS ARBEIT LEUTE!!! Das Tool gefällt immer mehr ;-)


Grüße

 

[Solo0815]

Aha! Daher also die Probleme mit der BBox!
Wers ausprobieren möchte:

/var/fritzload/bin/busybox awk

bleibt hängen -> Ctrl + C

/var/fritzload/bin/busybox26_SVN_unter1542 awk

funktioniert!

Sollten wir doch wieder auf die alte BBox zurück oder ein alias/Funktion für awk (alte Version) schreiben?

 

[makaveli187]

Hi!

Woher stammt denn die verwendete busybox?
Hat die jemand von Euch compiliert?
Ich habe versucht eine VM zur FritzBox-Entwicklung aufzusetzen, aber die Anleitungen, sind entweder veraltet oder greifen nicht.

Es ist ja auch komisch, dass keine der Versionen von der besagten Seite mit dem awk-Befehl klar kommen.
Ich frage mich, ob da evtl. noch mehr/andere Bugs drin sind...

EDIT:
Ich habe das mal als Bug weitergeleitet:
https://bugs.busybox.net/show_bug.cgi?id=5192



Grüße


PS: Falls Ihr das selber compiliert, kann mir jemand eine "Starthilfe" geben?
Würde auch gerne eine lauffähige Umgebung haben für eine neuere tcpdump-Version.
Evtl. Liegt das "unknown data link type 14" nur daran...

 

[Solo0815]

Die busybox ist von der offiziellen Seite, siehe auch hier: http://sourceforge.net/apps/trac/avmload/browser/trunk/FritzLoad/bin/busybox26?rev=1542

Hat vorher tadellos funktioniert. Ich vermute, dass es an der neuen FB-Firmware 54.05.21 liegt. Vielleicht können ein paar Leute die oberen Befehle testen, damit wir der Sache auf den Grund gehen können. Wenn es so wäre, sollten wir AVM den Bug melden.

Vielleicht kann auch einer mal die aktuellen Sourcen der BBox für die 7270 kompilieren, da sind lt. Homepage einige Segvault-Fixes drin. K.A. obs was bringt.

@makaveli:
Du solltest beim Bug-Report noch die Prozessor-Architektur (mips?) und den Kernel (2.6.32.41) hinzufügen, da das Problem _anscheinend_ nur auf der FB mit diesem Kernel auftritt. (<- was noch zu testen ist)