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

@echoplex
fullpath= /var/media/ftp/USB-Stick/Download/

genauer gesagt
fullpath= /var/media/ftp/USB-Stick/Fritzload/downloads/
und die Listen sind unter ".../Fritzload/config" zu finden

Big11 schrieb:
ausserdem Fehlermeldungen in DMESG über fehlerhaftes FAT Dateisystem (?) Stick ist 8GB und auf FAT32 formatiert....
USB-Stick wird nur ro gemounted

Ich kann mich errinern das hier schon mal jemand dieses Fehler hatte. Wenn ich jetzt richtig liege, lag es daran dass das file systen wirklich beschädigt war und nach neuformatieren des sticks gings wieder.
 
Wireshark Protokoll

Hallo,

ich bins mal wieder :) und habe folgendes Problem mit dem Wireshark Protokoll:
Jdownloader gestartet, Protokollaufzeichnung gestartet, Onlinecheck durchgeführt und bekomme dann folgende Fehlermeldung:

Protokollformatierung...
tcpdump Meldung: reading from file /var/fritzload/downloads/wireshark.eth, link-type 14 tcpdump: unknown data link type 14

Link Auswertung:
Keine passenden Daten gefunden.
-----
Keine Links der bekannten Hoster gefunden

Was läuft hier falsch?
 
Anscheinend hat die 7170 einen anderen Typ des Wireshark Protokolls, den das tcpdump nicht kennt. Da kann ich leider nichts machen...
 
@Big

Dein Stick ist doch als Read-Only gemounted?
Evtl. mal deinen Stick mit ext2 formatieren.
Schon mal chmod 777 probiert?
 
also eben ist mit meine box etwas eigenartigen passiert was ich mir überhaupt nicht erklären kann (trunk 977)..vll weis einer von euch was..

Da die Led´s nicht an wollten hatte ich mal im Quellcode reingeguckt um zu sehen wie das realisiert wird. Kenne mich leider nur ein wenig mit visual basic aus. Die Quellcodes sehen für mich dann entsprechen kryptisch aus. Nun dann hatte ich mit den Led´s uber telnet ein wenig gespielt mit >/dev/new_led und >/var/led was auch funktionierte. Zwischen durch hatte ich /dev/new_led durch /var/led in /lib/led.sh ersetzt. Nach paar versuche habe ich /dev/new_led belassen wie es schon vorher war.

Kurze zeit später als ein Download in Fritzload gestartet wurde ging die info led an :noidea: und jetzt funktionieren die Led´s (nur mit info ausprobiert). Selbst nach einen reboot geht die info led so wie das gedacht was. Keine Ahnung wie dass zustande gekommen ist aber jetzt geht es...Vielleicht wurde dadurch irgendwas in der box angestoßen oder zurückgesetzt oder so..Haupsache es läuft wieder:)
Mal schauen ob es so bleibt.
 
Das ist ja schade! Mit der 7270 oder 3270 funktioniert das aber?
Probier mal die Seite aus: http://fritz.box/cgi-bin/capture_notimeout
Nach dem Einloggen sollte ein Seite erscheinen zum Protokoll aufzeichnen. Diese Datei kannst Du mit der kommenden Version dann analysieren lassen. Dort gibt es dann einen neue Option "Vorhandenes Protokoll:" unter dem Fritz!Load-Menüpunkt Decrypt.

Die Funktion die Fritz!Load nutzt ist bei der 7270 auf der oben angebenen Seite unter folgender Bezeichnung zu finden:

Paketmitschnitt auf Interface:
Packet trace of interface:
interface name: (lan, eth0, eth1, usbrndis, tiwlan0)
mit Länge/with length: bytes
 
Hallo ich habe eine Trunkversion 965 da geht die Protokollaufzeichnung.

Da ich ein Kabelanschluss habe nutze ich eth0. Habe es mehrfach mit JD getestet und funktioniert prima mit FB 7170.

@Louis versuch mal andere Anschlüsse in der config auszuwählen

mfg
 
folgende Fehlermeldung:
Protokollformatierung...
tcpdump Meldung: reading from file /var/fritzload/downloads/wireshark.eth, link-type 14 tcpdump: unknown data link type 14

Link Auswertung:
Keine passenden Daten gefunden.
-----
Keine Links der bekannten Hoster gefunden
Konnte den Fehler reproduzieren. Wenn die fritzload.default benutzt wird, erhalte ich auf der 7270 auch die Fehlermeldung "tcpdump: unknown data link type 14".
Sobald ich auf eine andere Paketschnittstelle wechsel ist die Fehlermeldung weg.

Die Frage ist nun, was mag tcpdump nicht an der Standardeinstellung bzw. was sonst sollte man als Standardeinstellung definieren?
 
Zur tcpdump-Sache: nutze die 7170 über wlan, bei mir geht "tiwlan0 - Paketmitschnitt Interface" einwandfrei. Also einfach mal testen. (ca. trunk 960 und neuester trunk)
 
Zuletzt bearbeitet:
Ich habe jetzt alle Paketmitschnitte ausprobiert, und den Tip von SagHalt von der Seite aus:
Ich bekomme immer die Fehlermeldung Keine passenden Daten gefunden oder bad dump file format.
Dann werd ich wohl die Links weiter über Wireshark auslesen und mit Textpad auswerten müssen. Geht auch.

Trotzdem nochmal an dieser Stelle: SUPER ARBEIT die ihr da leistet.
 
Mach doch einen Wireshark Protokollmitschnitt vom PC aus auf USB-SPEICHER/fritzload/downloads/wireshark.eth
Im Anschluss kannst Du die Links ja wieder über das Webfrontend auslesen lassen.
 
Hab ich auch schon versucht:

Protokollformatierung...
tcpdump Meldung: reading from file /var/fritzload/downloads/wireshark.eth, link-type EN10MB (Ethernet)

Link Auswertung:
-----
Keine Links der bekannten Hoster gefunden
 
Hallo billygeen,
der Vorschlag wurde bereits gemacht.
Hier nachzulesen und Daumen zu drücken, dass er dran kommt! :D
http://sourceforge.net/apps/trac/avmload/ticket/1

Werde es auch noch im sourceforge melden aber wenn ich hier
schon drin bin:
Im trunk 985 wird in der GUI nicht mehr die Internet IP angezeigt,
sondern die der Box selber. War das Absicht???
EDIT: Das darf keine Absicht gewesen sein, weil dadurch eine Reconnect-Schleife
angefangen wird! Über eine schnelle Lösung wäre ich dankbar!

@Loius & zum Protokoll:
Bei mir funktioniert das auch nicht mit der 985.
Es sind zwar Links im dump usw. aber nicht ganz sauber ausgewertet.
Bei Bedarf kann ich die Dateien zukommen lassen.
Ich hänge ja mit meinem Rechner hinter dem WDS Repeater und dumpe über die lan Schnittstelle.
Vielleicht ist das auch wieder ein Sonderfall von wireshark-format?

Gruß
Fireball
 
Zuletzt bearbeitet:
Bei mir wird auch nicht mehr die externe ip angezeigt. Ich fände es persönlich besser als die interne. Die muss man ja wissen wenn man auf box zugreifen will :P

Edit: @Fireball3

Ich habe bis jetzt immer ohne reconnect geladen. Werde es dann heute mal machen.
 
Zuletzt bearbeitet:
Habs oben nochmal hinterhergeschoben aber das Problem ist jetzt mit der
Dringlichkeit HOCH einzustufen weil eine Reconnect-Schleife ausgelöst wird,
wenn "neue IP" = "alte IP" :(

Leider kann ich die Dringlichkeit im Sourceforge nicht nachträglich auf HOCH
einstufen - ist es aber!

Wie sieht das bei Dir aus computeruser?
Funktioniert der reconnect bei Dir?
(kannst ja den Post von oben editieren und dazuschreiben - sparen wir ein bisschen Platz)

EDIT:
Habe die reconnect.sh aus dem trunk 946 geladen und mit der scheint es zu funktionieren.
gendy muss wohl seine Änderungen im aktuellen trunk 985 nochmal optimieren!

Gruß
Fireball
 
Zuletzt bearbeitet:
@Fireball3

zu wenig Information. hast du Dateien aus dem FritzLoad/html auch aktualisiert?
da kamen dazu ein paar kleine Dateien z.B. ip.html

wenn ja , kannst du im Telnet den Befehl

/usr/www/cgi-bin/webcm getpage=/var/tmp/flwww/fritzload/ip.html

ausführen und Ergebnis posten ?
 
Hallo gbel,
Code:
usr/www/cgi-bin/webcm getpage=/var/tmp/flwww/fritzload/ip.html
192.168.178.22#
Das ist die feste IP des WDS Repeaters auf dem Fritzload läuft.

Die Installation ist frisch mit einem kompletten trunk.
Mit neustart der box usw.

Gruß
Fireball
 
Das Problem der geänderten Routinen ist, dass Sie nur noch die lokale Box abfragen und nicht mehr die angegebene Box, die in der Config mit IP-Adresse definiert wurde.

Die Funktionen wlan_status, ip_address, voip-check, mac-Änderung müssten korrigiert werden, oder man unterscheidet, ob die lokale Box in der Config definiert wurde oder eine externe, dann könnte man die Optimierten Routinen belassen und nur bei einer externen Box die umfangreicheren HTML-Seiten auswerten...
 
install.sh aus 988 trunk funkt bei mir nicht

Hallo,

habe USB-Installation. Aber bekomme beim Befehl ./install.sh -d ständig Fehlermeldung, ich sei nicht im FritzLoad-Pfad.
mit der Version aus 985 klappt alles....
 
Kostenlos!

Statistik des Forums

Themen
248,977
Beiträge
2,307,656
Mitglieder
378,753
Neuestes Mitglied
mr.panasonic