Fritz!Load…

Müsste wieder funktionieren, ob es für größere Dateien geht ist fraglich.

So ein kleine Datei (9 bytes) als Testlink bringt übrigens nichts, da Fritz!Load es als fehlerhaften Download klassifiziert.
Ein paar KB sollten es schon sein.

Es fällt nichts auf, was bei dir den Fehler auslöst; die set Ausgabe weist keine relevanten Unterschiede aus.

Zum weitere debuggen hab ich ein paar Ausgaben in die relevanten Dateien eingefügt.
https://mega.nz/file/lop3HaJC#_ue7KRHyl … Vg1cflY7Kk
Die beiden Dateien im obigen ZIP wären im Ordner /bin des F!L Verzeichnisses zu ersetzen, F!L vorher beenden.

Entweder nach Reboot der Box F!L starten - oder nach dem Stopp von F!L (./install.sh -u) folgendes aufrufen:

rm -rf /var/tmp/fritzload*

Dann F!L starten (./install.sh -g)

Man könnte meinen es sind 2 unterschiedliche 7590 im Umlauf - wahrscheinlich wird's aber an freetz (bei dir) bzw. Fritz!OS original (bei mir) liegen.

Um das zu debuggen, bitte die folgenden Befehle auf der Shell eingeben und Ausgabe liefern:

echo $HWRevision
echo $CONFIG_VERSION
echo $CONFIG_PRODUKT_NAME
cat /var/jason_boxinfo.xml
cat /var/tmp/fritzload.cache

Was kommt im Browser? Verfolge mal die Kommunikation mit aktivierten Developer Tools.
Evtl. blockt etwas anderes den Zugriff?

EDIT:

Was kommt als Ausgabe von

cat /var/tmp/fritzload.cache

bei dir?

Und was nachdem F!L gestartet ist:

ps ww | grep -v grep | grep httpd

Ich bin den Problemen von freetz in Zusammenhang mit einer 7590 und 7.21 ausgewichen, Stichwort Watchdog, etc.
Im IPPF berichtet jemand, dass es bei der busybox 1.32 zu Problemen kommt, bei 1.31 funktioniere es.

Die Meldung besagt, Fritz!Load erfolgreich gestartet werden konnte. Die untere Ausgabe bezieht sich darauf, dass im Menü von Fritz!OS der Menubutton nicht implementiert ist, ändert an der F!L Funktionalität nichts.

Was passiert, wenn du F!L per telnet/ssh mittels

./install.sh -g

startest?

Trotzdem, F!L sollte nach der Meldung erfolgreich gestartet und unter der angegeben IP Adresse auch erreichbar sein.

Bzgl. Ordner 7270, 7390 und nun eben 7590:

Grundsätzlich waren die für die binaries für verschiedene Architekturen gedacht. 7270 stellvertretend für die mipsel Boxen, 7390 analog für die mips Boxen.

Ab Fritz!OS 7.19 verwendet AVM nun musl statt uClibc, aber bis jetzt anscheinend nur für 7590. Eine 7490 hat also trotz Version 7.19 (und höher) weiterhin die uClibc, siehe hierzu: https://www.ip-phone-forum.de/threads/u … 19.305167/
Das bedeutet nun, dass die mips binaries nun plötzlich nicht mehr mit einer 7590 mit Version 7.19 (und höher) kompatibel sind. Fix Probleme hat bis jetzt die bei F!L mitgelieferte mips busybox gemacht, deshalb musste ich das jetzt ändern und für die 7590 eine eigene busybox erstellen, siehe r3172 und r3173.

Andere mips binaries können auch noch inkompatibel sein, aber bis jetzt noch nicht aufgefallen.

Ich habe meine 7590 gerade auf 7.21 gebracht.
Funktionieren tut so gut wie nichts, ich werde von den diversesten Fehlermeldungen erschlagen.
Was habt ihr für eine Box und habt ihr eine freetz Version installiert?

Ich habe in die aktuelle 7.21 nur telnet eingebaut und das CONFIG_RELEASE auf 0 gesetzt (das dürfte jetzt einer INHOUSE Version entsprechen), also keine freetz Modifikation. Die andere Partition mit 7.12 und freetz startet mit F!L problemlos.

Was kommt, wenn ihr F!L per telnet und ./install.sh -g startet?

EDIT:
Die Fehler kamen von der busybox, die ist zumindest auf der 7590 mit 07.21 nicht mehr mit der Version für mips im 7390 Verzeichnis kompatibel!
Die anderen binaries für mips scheinen noch zu funktionieren.

Ich hätte einen neuen Hoster hier, der verlangt auch Recaptcha v3.
Mich würde dein source schon sehr interessieren
Mit 9kw.eu komme ich auch nicht weiter, obwohl sie in ihrer Doku was von v3 schreiben.
https://www.9kw.eu/api.html#apisolve-tab

Wie löst man v3 in Verbindung mit 9kw.eu?

Eine erste Version ohne Recaptcha (kam nicht) und größere Fehlerbehandlung ist vorhanden.

Und ich kann wiederum keines der Probleme nachvollziehen, alle Dateien werden normal geladen. 

Nun wird die FL-eigene busybox forciert bei der neuen Funktion.
Wobei aus dem Output (der Einzeiler weiter oben) ersichtlich war, dass alle drei Outputs dasselbe liefern ...

Ein DEBUG Log geht immer, wenn man den Haken korrekt setzt. Er verschwindet jedoch manchmal, bei diversen Wechseln von Monitor Ansicht etc.
Es ist jedoch kein Problem, wenn man direkt VOR der Erstellung des DEBUG Log den Haken setzt und dann auf "Speichern" in der Linkliste drückt.
Dann wird der Haken immer übernommen und der Problemlink kann mittels DEBUG verfolgt werden.

Keines der Probleme kann ich nachvollziehen:

ddl.to - Datei wurde erfolgreich geladen
hitfile.net - Datei wurde erfolgreich geladen
filefactory.netcom - Server temporär überlastet

Bei Filefactory füge ich diesen Fehlermeldung hinzu, es passiert auch, wenn man im Browser den Link öffnet.

Und das normale Log hilft nicht, dazu braucht es das DEBUG Log.