Umstellung des VoIP-Checks von webcm-Schnittstelle nach foncalls.lua

rolex0815 · am 08. Feb. 2018 um 23:25 Uhr

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. cool

Chefi · am 11. Feb. 2018 um 10:23 Uhr

@Fireball3:
Es ist soweit ich sehe jetzt alles eingecheckt, du solltest jetzt bedenkenlos updaten und Reconnect aktivieren können.

Fireball3 · am 11. Feb. 2018 um 18:39 Uhr

Irgendwas stimmt bei mir nicht.
Kein VoIP check, keine log Einträge, aber erfolgreiche reconnects...
Muss mal einen Box Neustart hinlegen.

Chefi · am 11. Feb. 2018 um 20:31 Uhr

"Gar keine" Logeinträge ist eigentlich das letzte was passieren dürfte, daran wurde nichts geändert. Klingt für mich wie etwas was mit einem frisch formatierten USB Stick und einem Neustart behoben sein sollte.
Falls du das Problem allerdings auf die neueste Version festnageln kannst, probiere doch die Voipcheck.lua mal manuell über Telnet aus, wir haben die ja an eine SampeSize von Eins entwickelt, da rolex0815 keine Telefone an seiner FB mehr hat. Dieser Teil sollte eigentlich bei allen Boxen mit Telefon identisch sein.

Fireball3 · am 12. Feb. 2018 um 23:53 Uhr

Ich habe mal die 2875 geladen.
Nach click auf "Erneut verbinden" kommt sofort "Sende Neustartanweisung..." ohne Prüfung oder sonst was.
Bei der 2877 dasselbe.
Der Fehler scheint also schon vorher existent gewesen zu sein.
Auch nach Neustart der Box gibt es keine Einträge im log.
Ich muss mir nochmal die Sachen mit der voipcheck.lua anschauen und dann
probiere ich das mal auf der Konsole.

Chefi · am 12. Feb. 2018 um 01:43 Uhr

Bei 2875 ist ja auch noch nichts umgestellt. Und 2877 hat bei Share-Online einen Knacks. Stefanosperl hat noch einiges eingechekt, das habe ich aber noch nicht probiert.
Empfehlen kann ich im Moment erstmal nur 2876
EDIT: Ich habe das nochmal gelesen was du da gschrieben hast, und wenn ich mal so drüber nachdenke dann irgnoriert der Klick auf erneut verbinden die aktivierten Checks. Die Mac/und voip checks laufen nur bei eineim automatisiertem Reconnect.

Der Beitrag wurde geändert von Chefi (am 12. Feb. 2018 um 12:43 Uhr)

rolex0815 · am 12. Feb. 2018 um 12:46 Uhr

Chefi schrieb:

da rolex0815 keine Telefone an seiner FB mehr hat.

Die FB hat nie Telefone gehabt. Bin seit 4 Jahren an einem Kabelanschluss mit eigenem Modem und die FB hab ich rein für F!L (bei ebay ersteigert). smile

Fireball3 · am 12. Feb. 2018 um 16:18 Uhr

Chefi schrieb:

Ich habe das nochmal gelesen was du da gschrieben hast, und wenn ich mal so drüber nachdenke dann irgnoriert der Klick auf erneut verbinden die aktivierten Checks. Die Mac/und voip checks laufen nur bei eineim automatisiertem Reconnect.

Dürfte aber nicht sein, bzw. das war mal anders. hmm
Ich blicke leider nicht durch die Struktur des gesamten Programms - was wen wann aufruft etc.
Dieser Mix mit den .cgi Dateien die dann Teils doch shell-skripte sind und dann wieder doch nicht...harter Tobak - echt.
Aber ich meine ich konnte das Problem lokalisieren in der Datei

/cgi/gui_reconnect_do.cgi

Dort wird

/bin/reconnect 0

aufgerufen - das ist echt madig. Und ohne jeglichen Kommentar ins log usw.
Warum wird da nicht die

/lib/reconnect.sh

aufgerufen?
Offensichtlich sind ja beide Skripte lauffähig! Gibt's da einen technischen Grund?
Klärt mich gerne auf!

Der Beitrag wurde geändert von Fireball3 (am 12. Feb. 2018 um 16:21 Uhr)

Chefi · am 12. Feb. 2018 um 16:43 Uhr

Ich glaube das ist gewollt. Wenn man selbst reconnected wird man wohl alles manuell gecheckt haben und wissen was man tut. Ich weiß es aber auch nicht sicher.
Funktioniert den die voipcheck.lua bei deiner 7490?

Fireball3 · am 12. Feb. 2018 um 16:54 Uhr

Hab weiter gegrübelt...
Wenn die

/bin/reconnect

abgearbeitet ist, ruft die wiederum eine

reconnect "Manuell" 1 1

auf. Die Übergabe von "1 1" ist vermutlich der Schlüssel. Da werden die Prüfungen auf irgendwas gleich gültig gesetzt.
Wenn man die vielleicht wegläßt läuft vermutlich der normale Prozess ab.
Könnte man ruhig im log was ausgeben oder gleich auf der GUI.

Die .lua habe ich noch nicht ausprobiert - war schon spät gestern nach all dem Testen.
Vielleicht schaffe ich es heute Abend.
Oder ich tune mal eben diese beiden 1er weg und schau ob es pfeifft. big_smile

Der Beitrag wurde geändert von Fireball3 (am 12. Feb. 2018 um 16:56 Uhr)

rolex0815 · am 12. Feb. 2018 um 20:09 Uhr

Fireball3 schrieb:

Dort wird
/bin/reconnect 0
aufgerufen - das ist echt madig. Und ohne jeglichen Kommentar ins log usw.
Warum wird da nicht die
/lib/reconnect.sh
aufgerufen?
Offensichtlich sind ja beide Skripte lauffähig! Gibt's da einen technischen Grund?

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 big_smile

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. big_smile

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 ...

Der Beitrag wurde geändert von rolex0815 (am 13. Feb. 2018 um 12:32 Uhr)

Fireball3 · am 12. Feb. 2018 um 21:07 Uhr

rolex0815 schrieb:

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.

Irgendwo sagte ich ja bereits, dass das nicht so mein Metier ist tongue
Ich bemühe mich zwar, aber bin da nur Teilzeitsportler. Vielleicht kannst Du ja etwas helfen?

Der Auslöser ist in der

FritzLoad\cgi\gui_reconnect_do.cgi

und lautet:

#!/bin/ash
INSTANCE_BASE_LINK=gui_download.cgi
. ./gui_main.cgi
cd $pdir/bin

echo "<pre class=msg>Sende die Neustartanweisung...";
./reconnect 0
echo "</pre>"
PAGEEND

Ist damit nicht die Datei

\FritzLoad\bin\reconnect (ohne Endung)

gemeint? Das ist eine Funktion. Wußte nicht, dass man die einfach so ablegen kann. Welcher Teil in der Funktion verarbeitet den Parameter "0" (sehe nicht wer den auswertet).

/bin/reconnect 0

Die Funktion prüft dann ob irgendwelche reconnects bereits laufen und startet am Ende

reconnect "Manuell" 1 1

Ist dann damit die

FritzLoad\lib\reconnect.sh

gemeint? Ansonsten bin ich hier auf dem Holzweg. Und was die Übergabe von "Manuell" 1 1 angeht sowieso. hmm
Da sind dann weiter Prüfungen und irgendwo auch die Funktionen

doReconnect(){

und im weiteren Verlauf auch

upnp_reconnect(){

Wobei ich mir bei dieser upnp_reconnect nicht sicher bin ob das schon der reconnect-Befehl ist (den Inhalt des curl aufrufes verstehe ich nicht), denn vom Ablauf her ist die Funktion zu früh dran.

Danke für die Aufklärung! big_smile

rolex0815 · am 12. Feb. 2018 um 22:10 Uhr

Hast du meinen geänderten Beitrag gesehen? Könnte sich nämlich überschnitten haben.

Fireball3 · am 12. Feb. 2018 um 22:31 Uhr

Ja, jetzt.
Sieht ja ganz vernünftig aus was ich mir da zusammen gereimt habe.
Ich habe mal versucht was rauskommt, wenn reconnect ohne die Übergabe von

"Manuell" 1 1

ausgeführt wird.
Nun, es ändert nichts. Reconnect wird erfolgreich durchgeführt, keine weitere Ausgabe wie sie in der reconnect.sh eigentlich hinterlegt sind.
Irgendwo nimmt er immer noch die Abkürzung... mad

local showMsg="${1:--}" forceReconnect=${2:-0} showMsg=${3:-0}

Das erste showMsg ist in "", die sind irgendwie nicht gleich.

@Chefi
Die voipcheck.lua funktioniert auf der 7490. wink

Der Beitrag wurde geändert von Fireball3 (am 12. Feb. 2018 um 22:47 Uhr)

rolex0815 · am 13. Feb. 2018 um 23:01 Uhr

Fireball3 schrieb:

local showMsg="${1:--}" forceReconnect=${2:-0} showMsg=${3:-0}
Das erste showMsg ist in "", die sind irgendwie nicht gleich.

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

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

Fireball3 · am 13. Feb. 2018 um 00:18 Uhr

Hab Deine Änderung per diff-update eingespielt, kann aber keine Änderung beobachten.
Auch mit dem Haken bei debug gibts im log nicht mehr zu sehen.

Fireball3 · am 13. Feb. 2018 um 13:35 Uhr

Wer kann mir hier ein bisschen Licht ins Dunkel bringen?
Oder einfach nur sagen, ob ich das richtig verstehe.

Funktion:

reconnect() {

	local showMsg="${1:--}" forceReconnect=${2:-0} showMsg=${3:-0}

Lokale Variablendeklaration
1: 2: 3: sind dabei willkürlich gewählt und werden von dem Parameter mit dem die Funktion aufgerufen wird überschrieben?
Unser Beispiel

"Manuell" 1 1

Dann folgt

	if ! reconnectEnabled $forceReconnect $showMsg; then

Auf Deutsch:

wenn nicht reconnectEnabled 1 1 dann

dann nochmal, abhängig von der showMsg Variable eine Nachricht ausgeben und return 1.

 [ ${showMsg:-0} -ne 0 ] && print "Die erneute Verbindung wurde nicht ausgeführt, weil Einstellungen oder Signaldateien (laufende Download-Prozesse) dies verhindern..."
    return 1
  fi

Diese Zeile verstehe ich nicht.

if ! reconnectEnabled $forceReconnect $showMsg; then

Die Funktion reconnect Enabled ist erst weiter unten!? Wir die hier aufgerufen und ausgeführt?

Danke für die Aufklärung!

rolex0815 · am 14. Feb. 2018 um 12:19 Uhr

Fireball3 schrieb:

Diese Zeile verstehe ich nicht.
if ! reconnectEnabled $forceReconnect $showMsg; then
Die Funktion reconnect Enabled ist erst weiter unten!? Wir die hier aufgerufen und ausgeführt?
Danke für die Aufklärung!

Dafür sind ja Funktionen gedacht. Damit man sie an anderer Stelle aufrufen kann.
Stell dir den Spaghetti Code vor, wenn du bei jeder Funktionalität alles immer wieder neu schreiben musst.
Deswegen werden Bereiche, die man möglicherweise wieder benötigt, in Funktionen ausgelagert.

Wo die Funktion implementiert ist, ist von Programmiersprache zu Programmiersprache verschieden.
In Bash Scripts kann die unterhalb im File stehen und trotzdem oberhalb aufgerufen werden.

Plain old C erlaubt das z.B. nicht.

Fireball3 · am 14. Feb. 2018 um 13:25 Uhr

Der Rest ist so korrekt wie ich geschrieben habe?

rolex0815 schrieb:

In Bash Scripts kann die unterhalb im File stehen und trotzdem oberhalb aufgerufen werden.

Verständlich, aber wird die Datei dann von oben nach unten ausgeführt oder wird nach dem Abarbeiten der Funktion, hier reconnect(),
beendet?

Oder anders gefragt, wird mit

reconnect "Manuell" 1 1

die reconnect.sh aufgerufen oder nur die Funktion innerhalb der reconnect.sh?

Hiermit wird also die reconnectEnabled() mit den Parametern 1 1 aufgerufen?

if ! reconnectEnabled $forceReconnect $showMsg;

Das if ! kehrt den Rückgabewert der reconnectEnabled() um?
Wird da implizit ein positives Ergebnis erwartget? Anders macht der Ausdruck irgendwie keinen Sinn.

if ! 1 (oder wie?)

Ich hätte da einen Vergleich erwartet so a la

if 1=1; then ...

roadman17 · am 14. Feb. 2018 um 14:11 Uhr

Fireball3 schrieb:

Oder anders gefragt, wird mit
reconnect "Manuell" 1 1
die reconnect.sh aufgerufen oder nur die Funktion innerhalb der reconnect.sh?

Damit wird die Funktion reconnect aufgerufen, die in der lib/reconnect.sh definiert wurde.

Fireball3 schrieb:

Hiermit wird also die reconnectEnabled() mit den Parametern 1 1 aufgerufen?
if ! reconnectEnabled $forceReconnect $showMsg;
Das if ! kehrt den Rückgabewert der reconnectEnabled() um?
Wird da implizit ein positives Ergebnis erwartget? Anders macht der Ausdruck irgendwie keinen Sinn.
if ! 1 (oder wie?)

Wenn der die Funktion reconnectEnabled ein negatives Ergebnis ausgibt, wird abgebrochen und damit der Reconnect nicht durchgeführt.

Fireball3 schrieb:

Ich hätte da einen Vergleich erwartet so a la
if 1=1; then ...

return 0

beendet die Funktion und gibt einen positiven Rückgabewert zurück.
Jeder andere Returncode entspricht einem negativen Ergebnis.

Fritz!Load…

Ankündigung

#21 am 08. Feb. 2018 um 23:25 Uhr

Antw.: Umstellung des VoIP-Checks von webcm-Schnittstelle nach foncalls.lua

#22 am 11. Feb. 2018 um 10:23 Uhr

Antw.: Umstellung des VoIP-Checks von webcm-Schnittstelle nach foncalls.lua

#23 am 11. Feb. 2018 um 18:39 Uhr

Antw.: Umstellung des VoIP-Checks von webcm-Schnittstelle nach foncalls.lua

#24 am 11. Feb. 2018 um 20:31 Uhr

Antw.: Umstellung des VoIP-Checks von webcm-Schnittstelle nach foncalls.lua

#25 am 12. Feb. 2018 um 23:53 Uhr

Antw.: Umstellung des VoIP-Checks von webcm-Schnittstelle nach foncalls.lua

#26 am 12. Feb. 2018 um 01:43 Uhr

Antw.: Umstellung des VoIP-Checks von webcm-Schnittstelle nach foncalls.lua

#27 am 12. Feb. 2018 um 12:46 Uhr

Antw.: Umstellung des VoIP-Checks von webcm-Schnittstelle nach foncalls.lua

#28 am 12. Feb. 2018 um 16:18 Uhr

Antw.: Umstellung des VoIP-Checks von webcm-Schnittstelle nach foncalls.lua

#29 am 12. Feb. 2018 um 16:43 Uhr

Antw.: Umstellung des VoIP-Checks von webcm-Schnittstelle nach foncalls.lua

#30 am 12. Feb. 2018 um 16:54 Uhr

Antw.: Umstellung des VoIP-Checks von webcm-Schnittstelle nach foncalls.lua

#31 am 12. Feb. 2018 um 20:09 Uhr

Antw.: Umstellung des VoIP-Checks von webcm-Schnittstelle nach foncalls.lua

#32 am 12. Feb. 2018 um 21:07 Uhr

Antw.: Umstellung des VoIP-Checks von webcm-Schnittstelle nach foncalls.lua

#33 am 12. Feb. 2018 um 22:10 Uhr

Antw.: Umstellung des VoIP-Checks von webcm-Schnittstelle nach foncalls.lua

#34 am 12. Feb. 2018 um 22:31 Uhr

Antw.: Umstellung des VoIP-Checks von webcm-Schnittstelle nach foncalls.lua

#35 am 13. Feb. 2018 um 23:01 Uhr

Antw.: Umstellung des VoIP-Checks von webcm-Schnittstelle nach foncalls.lua

#36 am 13. Feb. 2018 um 00:18 Uhr

Antw.: Umstellung des VoIP-Checks von webcm-Schnittstelle nach foncalls.lua

#37 am 13. Feb. 2018 um 13:35 Uhr

Antw.: Umstellung des VoIP-Checks von webcm-Schnittstelle nach foncalls.lua

#38 am 14. Feb. 2018 um 12:19 Uhr

Antw.: Umstellung des VoIP-Checks von webcm-Schnittstelle nach foncalls.lua

#39 am 14. Feb. 2018 um 13:25 Uhr

Antw.: Umstellung des VoIP-Checks von webcm-Schnittstelle nach foncalls.lua

#40 am 14. Feb. 2018 um 14:11 Uhr

Antw.: Umstellung des VoIP-Checks von webcm-Schnittstelle nach foncalls.lua

Fußzeile des Forums