Fritz!Load…

Teste mal mit dem anderen Link von hier: https://filer.net/get/oofl4bhzewzwyg8r

Darüberhinaus ist das kein Debug Log.

Ich will so wenig wie möglich an der bestehenden Captcha Implementierung (generell wie es in FL gehandhabt wird) ändern.

Das erfordert mMn nach (ich lasse mich gern eines besseren belehren) ein Erkennen im Captcha Handling ob Recaptcha v1 oder v2 vorliegt ODER eine Änderung der Hoster Plug-ins, wo dann an der entsprechenden Stelle z.B. gleich

set_solution_recaptchav2()

aufgerufen wird.

Bei filer.net ist es für mich zumindest so zu sehen. Der jetzige komfortable Aufruf beschränkt sich auf

	# captcha processing
	if is_captcha $f; then
		captcha_service_active || return
		captcha_solution $f || continue

den Rest übernehmen dann eben die Funktionen fürs Captcha Handling. Das heißt, man muss entweder dort erkennen ob v1 oder v2, oder den komfortablen Aufruf ändern. Tendiere klar zum Erkennen in den Captcha Routinen, nur mir ist eben kein sicher funktionierender Weg klar bis jetzt.

Aber hier im Forum kommen sicher Anregungen - sorry, wenn ich bereits etwas Über-sehen/lesen habe, wo die Lösung schon steht. 

Das Problem löst sich am 31.03.2018 eh von selbst - wie ich im anderen Thread gesehen habe.

Bei filer.net finde ich z.B. nichts, was auf api2 o.ä. hindeutet, nur den grundlegenden Link:
https://www.google.com/recaptcha/api.js

Das kann ich runterladen und mit grep nach api2 durchsuchen - dann gibt's in dem Fall eine Unterscheidung.
Das soll nur als Bsp. dienen - für's captcha Handling wie es jetzt in FL aktiv ist, braucht man eine immer funktionierende Methode und da kam ich eben noch nicht entscheidend weiter.

Wer kann Zeile 126 im Code erklären?
https://sourceforge.net/p/avmload/code/ … ine_biz.sh

Der zweite Parameter pageurl sollte doch dynamisch sein?
Der hardcodierte Link ist das Testfile lotto-spieleinsatz.pdf.

Wenn das mal offline ist, geht das Plugin nicht mehr ...

Unglaubliche Odyssee ... wahrscheinlich aber auch durch Spezialfall "7590 A-CH Version" und Ziel "Freetz-de".
Früher[tm] war alles leichter. 

Aber: FritzLoad läuft auf der 7590 wie eigentlich erwartet ohne Probleme, wenn man den SSH/telnet Zugang hinkriegt.

Wer's nachlesen will:
https://www.ip-phone-forum.de/threads/7 … en.298603/

Schau dir an, was reconnectEnabled() zurückgibt. Eine Funktion kann etwas zurückliefern, muss aber nicht immer nicht einen Rückgabewert haben.
In diesem Fall kommt von reconnectEnabled() entweder "0" oder "1" - je nach den Ergebnissen innerhalb der Funktion.

http://openbook.rheinwerk-verlag.de/she … ammierung/ kann ich als Einstieg sehr empfehlen.

Das ist unerheblich, da links vom '=' der Variablenname festgelegt wird und der ist ident.

Möglicherweise reicht bereits meine Änderung zu einem anderen Variablennamen.

Das eine ist eine Funktion, das andere ist ein File. Du kannst kein Scriptfile per se so aufrufen, wenn das File mehrere Funktionen erhält.
Das sind Programmier Grundlagen - das aber nur so beiseite.

EDIT: Das obige ist nicht falsch, aber man sollte sich doch den Code genau ansehen, bevor man was postet *hüstel* (auf mich bezogen).
Warum das so gelöst worden ist, erschließt sich mir jetzt auch nicht, es wird aber seine Gründe gehabt gehabt haben ... hoffentlich

Das entscheidende passiert im File "reconnect" (OHNE Endung) hier:

reconnect "Manuell" 1 1

Das ruft dann in der reconnect.sh die Funktion reconnect() auf:

reconnect() {
	local showMsg="${1:--}" forceReconnect=${2:-0} showMsg=${3:-0}
...
}

Und damit sollte als Message "Manuell" angezeigt werden und/oder ins Log gehen, forceReconnect erhält eine "1" und ebenso bekommt der dritte Parameter eine "1" - damit die Message eben angezeigt wird.

Und wenn ich das jetzt sehe, dass zweimal die gleiche Variable angelegt wird (showMsg) aber unterschiedliche Parameter erhält (einmal den ersten und einmal den dritten) dann dürfte hier schon ein Bug liegen. Unter der Voraussetzung, dass es nicht doch was zulässiges ist - ich bin kein Bash Script Experte.

EDIT_ENDE

Im gesamten Code sind sicher genug "Wanzen/nicht mehr lauffähige Teile/nicht angepasster Code" enthalten, manchmal kommt mir so vor, wenn eine Baustelle zugemacht wird, gehen zwei neue auf.

Auf den Switch "Erneut verbinden:" hab ich noch nie geklickt, ich sehe erst jetzt, dass da was dahinter steckt und nicht nur beim aktiv/inaktiv Switch daneben.

Zusammengefasst ist das Problem jetzt folgendes:
Beim Klick auf "Erneut verbinden" wird ein Reconnect eingeleitet und die Prüfungen wie beim automatischen Aufruf finden nicht statt

Falls ja, glaube ich, daß dass immer so war, denn der Code hier wurde mWn schon lange nicht mehr verändert.
Außerdem denke ich soll ja ein Reconnect erzwungen werden, deswegen wurde das so erst implementiert.

Es kann aber auch ganz anders sein, nur ob wir das je erfahren ...

Die Änderungen sind zwar im SVN aber nicht an der richtigen Stelle. Wollte weitere Rückmeldungen abwarten und dann blieb's liegen.
Wird demnächst dann eingecheckt.

Und diesen "Rat" gibt's nicht, nur Diskussions- bzw. Findungsphasen. 

Ich hab eine 7590 mittlerweile, aber nicht mit F!L im Moment.
Freetz deklariert den Support zur Zeit als "sehr experimentell" - drum noch nicht geflasht. Originale FW wollte ich gar nicht angreifen für telnet etc.