Fehlerhaftes Verhalten von JSON-RPC API nach Update aus IPS v5.2

Hallo,

nach dem Update von IPS v5.1 nach v5.2 habe ich beim Datentransfer über JSON-RPC zwischen zwei PIs groessere Probleme. Wenn beide neu gestartet wurden, läuft der Transfer (siehe PHP Script) ohne Probleme. Nach einer gewissen Zeit, werden aber keine Daten mehr übermittelt (siehe Temperaturgraph kurz vor 4 Uhr) und es werden Fehlermeldungen ausgegeben. Mit dem Fernzugriff von intern und extern ist alles andere in Ordnung.

Folgendes Skript stösst den Transfer an:

$temperatur = GetValueFloat(14504);
	
$rpc = new JSONRPC("http://MyIPS@mymailserver.de:password@192.168.188.95:3777/api/");
$rpc->SetValueFloat( 11814, $temperatur );

Hierzu die nachfolgenden Fehlermeldungen:

Warning:  file_get_contents(http://192.168.178.88:3777/api/): failed to open stream: Verbindungsaufbau abgelehnt in /usr/share/symcon/scripts/__rpc.inc.php on line 89

Fatal error:  Uncaught Exception: Unable to connect in /usr/share/symcon/scripts/__rpc.inc.php:93
Stack trace:
#0 /usr/share/symcon/scripts/__rpc.inc.php(37): JSONRPC::makeRequest('http://192.168....', 'MyIPS@mymail...', 'password', 'SetValueFloat', Array, false)
#1 /var/lib/symcon/scripts/18087.ips.php(7): JSONRPC->__call('SetValueFloat', Array)
#2 {main}
  thrown in /usr/share/symcon/scripts/__rpc.inc.php on line 93

Hat da jemand einen Tipp für mich, an was das liegen könnte und wie man es beseitigen kann.

Gruss
Bernd

Ich habe es mal in ein eigenes Thema ausgelagert.

Kannst du denn mal testen an welchem der beiden Pi’s es liegt? Also mal nur einen neu Starten und gucken ob es dann geht? Oder musst du beide neu Starten?

paresy

Hallo paresy,

genau das habe ich auch gedacht und sogar schon gemacht.

[ul]
[li]Zuerst den sendenden PI neu gebootet, keine Veränderung es wird nichts mehr übertragen und es gibt die bekannten Fehlermeldungen.
[/li][li]Anschließend den empfangenden PI durchgebootet und nach kurzer Zeit werden wieder Daten übertragen
[/li][/ul]
Noch als zusätzliche Info, auf dem empfangenden PI läuft auch pivccu und damit der LAN-Adapter im Bridge Mode

Gruss
Bernd

Kannst du dann den Gegentest machen und quasi anders herum neu starten? Dann sollte direkt nach dem Ersten alles wieder laufen.

Auf dem „empfangenden“ Pi: Läuft die Verwaltungskonsole dort noch?

paresy

Hallo paresy,

kann ich machen, wird aber etwas dauern, da der Fehler ja erst nach mehreren Stunden auftaucht.

Gruss
Bernd

Hallo paresy,

hat etwas gedauert bis der Fehler wieder aufgetreten ist (~3 Tage). Die JSON-RPC-Kommunikation ist Heute kurz nach 3 Uhr Nacht wieder abgebrochen (siehe Hardcopy). Auf dem empfangenden PI kann die Konsole weiterhin aufgerufen werden (http://192.168.1XX.XX:3777/console/).

Lokal funktioniert der Aufruf übrigens ohne Probleme (siehe Hardcopy Local_Script.jpg)

Nach dem Neustart (~21:30) des empfangenden PIs läuft alles wieder wie gewohnt. Ein Neustart der sendenden PIs war nicht erforderlich.

Gruss
Bernd

RPC_Transfergraph2.jpg

Hab damit (JSON-RPC) jetzt auch Probleme, allerdings beim update von 5.2 auf 5.3 … aber etwas anders: Die JSON-Befehle kommen erst nach ziemlich genau 6 Minuten an. Die Zeiten auf den RasPis stimmen !

Und diese Latenzzeit steigt bei mir, jetzt nach etwa einer halben Stunde beträgt die Verzögerung schon 13 Minuten.

Da schaukelt sich irgendetwas auf…

top - 09:06:15 up  1:19,  1 user,  load average: 2.39, 2.87, 2.68
Tasks: 150 total,   1 running,  91 sleeping,   0 stopped,   0 zombie
%Cpu(s): 36.5 us,  2.9 sy,  0.0 ni, 59.3 id,  0.0 wa,  0.0 hi,  1.3 si,  0.0 st
KiB Mem :   948304 total,    34292 free,   398104 used,   515908 buff/cache
KiB Swap:   204796 total,     3288 free,   201508 used.   463792 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
  440 root      20   0 1416916 241720  33880 S 138.0 25.5 124:17.91 symcon
29701 fr24      20   0   25700   6960   1928 S   8.9  0.7   0:34.17 dump1090-m+
 1783 root      20   0    9336   1612   1428 S   3.6  0.2   2:59.47 pigpiod
  625 root      10 -10   13368   3112   2776 S   3.0  0.3   2:30.96 lcnpchk
31941 root      20   0    9732   3264   2740 R   0.7  0.3   0:00.18 top

Wie komme ich am einfachsten auf die 5.2 zurück ? Von Fragen nach Backups bitte ich abzusehen :frowning:

NACHTRAG: Mein Beitrag ist hier im falschen Thread, glaube ich.

ich habe jetzt einfach ein wenige Wochen altes Backup des symcon Verzeichnisses zurückgespielt - allerdings die symon binary im bin Verzeichnis auf die 5.3. belassen und die Probleme sind verschwunden.

Es lag also weniger am upgrade von 5.2 nach 5.3. sondern vielleicht an den Modulupgrades, die ich parallel auch gemacht hatte.

Ich probiere mal weiter …

@icey: Ich habe bisher keine Idee was dort schief laufen kann. Wenn die Konsole und der lokale Aufruf geht, dann bedeutet das, dass IP-Symcon per se korrekt funktioniert. Hast du irgendeine Firewall im Netzwerk installiert die ggf. auf die Menge der Anfragen früher oder später allergisch (DDoS) reagiert und blockiert?

paresy

Hallo paresy,

ich bin auch etwas ratlos, zumahl der Fehler erst nach mehreren Tagen auftritt. Alles andere (Webfront, Remoteconsole, SSH-Zugriff, usw.) funktioniert ja weiterhin ohne Einschränkung.

Ja, bei mir läuft eine Firewall. Die beiden betroffenen PIs sind aber im gleichen Netzsegment, müssen also nicht über die Firewall kommunizieren. Sie können sich auch gegenseitig mit IPv4 anpingen, über RPC kommt aber die bekannte Fehlermeldung.

Ich habe auf dem Ziel-PI ein kleines Script erstellt, welches die LAN-Schnittstelle down und wieder up setzt und gehofft, dass ein Reset der LAN-Schnittstelle hilft. Leider auch erfolglos.

# interface down
$command= "sudo ifdown eth0";
exec($command);

# 1 Sekunden warten
sleep(1);

# interface up
$command= "sudo ifup eth0";
exec($command);

Zuletzt habe ich Symcon auf dem Ziel PI neu gestartet. Anschließen lief die RPC-Kommunikation wieder erfolgreich.

sudo /etc/init.d/symcon stop
sudo /etc/init.d/symcon start

Ich werde weiter versuchen dem Thema auf den Grund zu gehen. Für Tipps aus der Community wäre ich sehr dankbar.

Gruss
Bernd

Ich kann dir anbieten, dass wir uns das Problem zusammen einmal ansehen, sobald es wieder auftritt. Aktuell habe ich nämlich noch keine Idee wer dies verursacht. Schick mir doch mal eine PM sobald es wieder da ist (oder ruf tagsüber gerne direkt im Office an)

paresy

Hallo paresy,

ich werde den Ziel-PI3B+ nun mal „from scratch“ neu mit allen Zusatzkomponenten PIGPIO, Zigbee2Mqtt, Z-Wave und piVCCU auf Rasbian Buster (oder sollte ich noch bei Stretch bleiben) hochziehen und dann testen.

Sollte es dann immer noch bei dem Fehlerbild bleiben, nehme ich deine Hilfe gerne in Anspruch.

Gruss
Bernd

Hallo paresy,

nach vielen Stunden durchflöhen von Logfiles und Wireshark dumps habe ich den Fehler endlich gefunden. Im DHCP Log habe ich gesehen, dass die IP-Adresse des IPsymcon-PI auch an einen AVM Repeater vergeben worden ist. Da der PI über LAN am Netzwerk angebunden ist und der AVM nur über WLAN, konnte der PI meistens schneller reagieren und war damit im arp-cache des Quellsystems gespeichert. Wenn das Quellsystem aber gerade seinen arp-cache gelöscht hat, der PI zu dem Zeitpunkt beschäftigt ist, antwortet der AVM schneller und schon steht die falsche MAC im arp-cache des Quellsystems. Da diese Konstellation sehr selten vorgekommen ist, hat es auch immer sehr lange gedauert, bis der Fehler wieder aufgetreten ist.

Saublöder Fehler, aber jetzt ist Ruhe. Warum mein DHCP-Server die gleiche IP an zwei unterschiedliche MAC-Adressen vergeben hat, konnte ich nicht mehr nachvollziehen.

Gruss
Bernd

Danke für dein Feedback. Das muss man ja auch erstmal finden :slight_smile:

paresy