Verbindungsprobleme mit PL4

Hallo zusammen,

ich wurde freundlich darauf aufmerksam gemacht, dass ich keine fremden Threads hijacken soll. Daher fange ich hier nochmal von vorn an ;-)

Ich habe meinen PL4 seit Anfang 2017 - direkt als er auf den Markt kam. Von Anfang an gab es Probleme mit der Netzwerkverbindung.

Mein Setup:
FritzBox, verschiedene Apple Geräte - MacBook Pro meistens mit der aktuellsten MacOS Version. GCC läuft entweder unter CrossOver, oder ein einer VMware Fusion VM. Verschiedene iOS Geräte.
Zugriff über auf den PL4 erfolgt via Browser via Cloud, iOS App (Cloud & LAN) oder GCC (LAN, USB nur bei Updates)

Der PL4 ist im WLAN und bekommt via DHCP eine feste IP zugewiesen.

Merkwürdigkeiten:
- ein Gerät kann sich verbinden, ein anderes nicht - wobei die Geräte wechseln
- Eine längere GCC-Session z.B. beim Erstellen eines neuen Beleuchtungsprofils stirbt zuverlässig irgendwann
- Die Verbindung über die Cloud ist weniger instabil, und funktioniert häufiger
- Wenn GCC keine Verbindung bekommt, ist der der PL4 via ping und Browser erreichbar

Damit ist klar, dass Problem ist nicht die LAN Verbindung, sondern die Kommunikation zw. GCC und dem PL4. Und natürlich habe ich mit den Timeouts experimentiert - ohne Erfolg.

Die 1. Antwort von @Mathias:

Wenn es Kommunikationsprobleme GCC<->ProfiLux gibt, folgendes tun:
- feste IP einstellen - im Gerät wie in GCC (nicht Auto)
- prüfen, ob andere Geräte im Netzwerk die gleiche IP haben, auch an DHCP-Range denken
- Firewall am PC checken (Port 10001)
- Timeout evtl. vergrößern, höchstens 2000ms, alles andere macht keinen Sinn
- stets neueste Versionen von Firmware, GCC und WiFi verwenden

Mein PL4 bekommt eine feste IP via DHCP, die ist im GCC eingestellt.
Da der PL4 die IP via feste IP DHCP bekommt, gibt es keinen Konflikt
Firewall ist entweder an, oder aus. Mein Verbindungsproblem läßt sich durch einen Power-Cycle des PL4 zuverlässig beheben. Damit kann es kein FW Problem sein.
Mit den Time-Outs habe ich experimentiert, ohne dass sich eine Verbesserung eingestellt hat
Solange bei einer neuen Version der Software nicht die beschriebenen Probleme behoben werden ist der Hinweis auf die neueste Version wenig hilfreich

Und nochmal: der PL4 ist via ping erreichbar, und antwortet im Browser auf Port 80. Es ist ein reines GCC Problem

Randbemerkung: das meiste geht inzwischen mit der iOS App. Über LAN gibt es hier keine Verbindung mehr, über die Cloud geht's. Hier gibt es auch Verbindungsabbrüche, aber seltener. Ich experimentiere gerade mit der Beleuchtung, das geht vernünftig nur mit GCC. Ich würde mir sehr wünschen, die komplette GCC Funktionalität über den eingebauten Web-Server nutzen zu können. Dann würde ich mich als Nicht-Windows Anwender weniger ausgegrenzt fühlen ;)

Kann das sein das der WLAN-Chip da Blödsinn treibt? Ich hab mir das mal Angeschaut.
Wenn ich z.B. ein Backup vom PL4 ziehe, kommen immer schön 70Byte Pakete (16Byte Nutzdaten) zum GCC-Rechner und 68Bytes (14 Bytes Nutzdaten) zum PL4 zurück. Zwischendrin kommt aber nur ein 64er Paket vom PL4. Das wird dann als "Ethernet Frame Check Sequence Incorrect" als schlechtes Paket erkannt. Und diese Pakete kommen laufend. Meistens schickt er das korrekte Paket dann gleich hinterher. Wenn nicht? Connection Lost!

Niedlich wird's wenn man sich das Paket mal anschaut.
Schlechtes Paket:
...
0030 08 60 1f 51 00 00 00 00 00 00 00 00 00 00 00 00

Gutes Paket:
...
0030 06 56 83 3f 00 00 01 70 51 c2 02 46 4c 41 40 30
0040 30 30 30 03 5c 04

Anstatt 16 Bytes Nutzdaten kommen 10 Bytes Nullen... (Edit: eigentlich darf da gar nix sein, da die Pakete ohne [PSH] eigentlich keine Nutzdaten haben sollten!)

Noch etwas:
Solange TCP-Flags [Push, Ack] gesetzt sind, ist alles gut. Alle Pakete [ACK] oder [RST, ACK] haben eine falsche "Frame Check Sequence" da sie alle mit den 10 Nullen aufhören. Kommen zwei dieser [ACK] Pakete hintereinander bricht die Verbindung ab.
GCC->PL4 [PSH, ACK]
PL4->GCC [PSH, ACK]
GCC->PL4 [ACK] bad frame
GCC->PL4 [PSH, ACK]
PL4->GCC [PSH, ACK]
GCC->PL4 [ACK] bad frame
Diesmal kommt das Paket nicht korrigiert
also: Wartezeit "Connection Timeout"
GCC->PL4 [FIN,ACK] (Verbindung beenden)
PL4->GCC [RST,ACK] bad frame
GCC->PL4 [SYN] (Neuaufbau der Verbindung)
PL4->GCC [SYN,ACK] bad frame
GCC->PL4 [ACK]
GCC->PL4 [PSH,ACK] (wenn dies nicht kommt = Kommunikationsfehler Error Code 28 und nix geht mehr)
…

Ein gutes [ACK] Paket hat üblicherweise 54Bytes, die bad frames haben 64Bytes.
gutes ACK:
0030 ff 70 82 69 00 00

Kann das sein, das da einfach die Schreibpufferlänge 10Bytes zu lang ist, und er deshalb an alles andere 10Bytes eines geleerten Puffers dranhängt? Er also alles unter 64Bytes mit Nullen auffüllt?


Also ein böses [ACK]Paket genommen, auf 54Bytes gestutzt und nochmal geprüft. Siehe da: Das Paket ist nun korrekt. Also wurde die Prüfsumme für das 54Byte Packet erstellt, und die Nullen haben da nix verloren!

Vielleicht hilts Euch ja weiter.

Schönen Gruss, Volker

Also ich habe noch ein wenig weitergemacht, und es einfach oben ergänzt. Also er bekommt nicht ein einziges Paket ohne [PSH] hin. Die sind durch die Nutzdaten ja auch länger als 64Bytes. Ansonsten schickt er alles mit 64 Bytes raus, und damit als Bad-Package.
Bitte sagt mir doch einer das ich Stuss rede ;o)
Volker

ich habe mir die Kommunikation noch nicht auf der Ebene angesehen.

Was m.E. gegen ein Problem im WLAN Chip spricht, ist die Tatsache, dass die Probleme zw. den Kommunikationspartnern wechseln, und die Cloud stabiler ist. Daher habe ich die GCC App, bzw. den entsprechenden Dienst auf dem PL4 im Verdacht.
Ich werde mal mein etwas angestaubtes Netzwerk KnowHow ausgraben, und mir die Kommunikation ansehen ;-)

Also wenn die grundlegende Kommunikation zwischen PL und GCC schon korrupt ist, kann GHL lange suchen und nix finden. Dieser Fehler liegt dann normalerweise an der Firmware des WLAN-Zulieferers.
Die fehlerhaften Pakete habe ich erst zwischen PL und GCC nachgewiesen. Das ist die OUC auf Port 10001. Die Weboberfläche hat aber andere Netzwerkprotokolle (http über Port 80 oder https...), welche ja funktionieren können. Das würde erklären warum GCC öfter abbricht als die anderen Verbindungen.
Über was myGHL überträgt, weiß ich noch nicht. Um diese Pakete (myGHL/http) abzufangen muss ich mich aber mit meinen PC zwischen WLAN Accesspoint und meinen Router klemmen, sonst bekomm ich die nicht. Ich werde das mal heute Abend probieren, und schauen was sich findet.
Wenn man wissen will was im Netzwerk passiert, ist "Wireshark" dein bester freund ;o)
Schönen Gruß, Volker

Versucht einmal das GCC Version 1.1.1.2. Diese ist bei mir (PL3) die letzte Version, welche problemlos eine Verbindung zum PL aufbauen konnte. Bei den neueren muss ich einen Timeout von 30000 einstellen, damit eine Verbindung aufgebaut wird. Wenn die Daten da sind funktionieren auch die neuen Versionen problemlos.

Gruss Pit

Habe jetzt auch mal Wireshark installiert. Ist wie gesagt ein paar Jahre her, dass ich mich mit TCP/IP beschäftigt habe :/
Habe gerade wieder die Situation, das keine Verbindung zustande kommt.

Hier ist was passiert:
1. GCC: SYN, Seq=0 -- PL4: SYN, ACK, Seq=0, Ack=1
2. GCC: ACK, Seq=1, Ack=1
3. GCC: PSH, ACK, Sec=1, Ack=1 -- PL4: FIN, ACK, Seq=1, Ack=13
4. GCC: PSH, ACK, Seq=13, Ack=2 -- RST, ACK, Seq=2, Ack=20

Lt. Wikipedia sollte die ACK-NR immer eins höher sein, als die Sequence-Nr des bestätigten Paketes. Die Ack Nummern der FIN und RST Pakete passen nicht ins Schema.K.A. was das zu bedeuten hat. Ist hier nicht der Fall, aber das scheint der Sache keinen Abbruch zu tun.

Jedenfalls, nach einem Reboot des PL 4 ist der Ablauf wie folgt:
1. GCC: SYN, Seq=0 -- PL4: SYN, ACK, Seq=0, Ack=1
2. GCC: ACK, Seq=1, Ack=1
3. GCC: PSH, ACK, Sec=1, Ack=1 -- PL4: PSH, ACK, Seq=1, Ack=13
4. GCC: PSH, ACK, Seq=13, Ack=15 -- ACK, Seq=15, Ack=20

Ich muss gestehen, ich habe keine Ahnung was das bedeutet :confused:

Quote:

---

Originally Posted by PIWAWT

Versucht einmal das GCC Version 1.1.1.2. Diese ist bei mir (PL3) die letzte Version, welche problemlos eine Verbindung zum PL aufbauen konnte. Bei den neueren muss ich einen Timeout von 30000 einstellen, damit eine Verbindung aufgebaut wird. Wenn die Daten da sind funktionieren auch die neuen Versionen problemlos.

---

Ich habe den PL4 seit Anfang 2017, und immer recht aktuelle GCC Versionen gefahren. Und das Problem bestand von Anfang an. Ein Erhöhen des Timeouts macht keinen Unterschied.

Die Probleme hier liegen nicht in der Kommunikation zwischen GHL Control Center und ProfiLux 4, sondern an der grundsätzlichen WLAN-Verbindung.
In den genannten Fällen kommen diese Unterbrechungen aber in GCC eher zum Tragen, da GHL Connect toleranter mit Reconnects umgeht und es dort nicht direkt zum Verbindungsabbruch kommt.

Trotzdem würden wir uns die Wireshark-Mitschnitte gerne betrachten und dazu die Bitte diese im Ticket-System als Anhang mit kurzer Fehlerbeschreibung zur Verfügung zu stellen,
damit wir hierfür die Gründe und Lösungen finden können:
https://www.aquariumcomputer.com/de/...kets-anfragen/

Also leider hat mir keiner gesagt, dass ich Stuss rede... Ist aber so. Foren sind ja prädestiniert um Halbwissen in die Welt zu posaunen, und nun bin ich auch darauf reingefallen. Mist.

Also Fakt ist, das der PL kein Paket kleiner als 64Byte rausschickt. Nicht mal ein Ping (was er alle 5s zum Gateway schickt). Das markiert "Wireshark" als schlechtes Paket, weil er in den Standardeinstellungen es anders interpretiert. Es ist aber ein normgerechtes Paket und vollkommen in Ordnung. Meine Waschmaschine macht das übrigens auch so. Also Entwarnung und Blödsinn Erzählt. (Wobei ich es immer noch behämmert finde, dass man kleine Pakete mit Nullen aufblasen tut)
Aber Erfahrung tut gut:
1. myGHL läuft über Port80 auf ein Niederländischen Server und scheint genauso wie das Webinterface weniger Störungsempfindlich zu sein, solange man sich Daten nur anschaut. Beim Empfang steigt der PL aber auch öfters aus.
2. Bei der Verbindung zwischen GCC und PL fällt mir aber auf, das diese 2 ACK's kurz hintereinander immer zu einem reconnect führen. Den der PL aber manchmal nicht hinbekommt, was das eigentliche Problem sein dürfte.
3. Wenn man sich den Netzwerkverkehr anschaut, erkennt man auch für was diese ominöse Connection-Timeout ist. Das geht auch mit dem GCC über den Reiter Verbindung. Kontinuierlich kommen Daten an, kommt nix (die Verbindung ist kaputt) wartet GCC genau diese Zeit bis er die Verbindung abbricht und neu startet. Also langt es vollkommen da vielleicht 10xdie Normale Laufzeit anzugeben: 300ms. Normalerweise bekommt man so gar nicht mit, dass er sich gerade aufgehängt hat. Wenn ich aber erst 30s warten will bis es weitergeht... bitte. Aber die Kommunikation wird dadurch nicht stabiler. Es gibt außer dem Timeout keinen Mechanismus um die Verbindung wiederaufzunehmen. Er schickt ein Nichtquittiertes Paket nicht nochmal.

So, ich lass mal den Kopf nun unten. Falls ich doch noch was finde gebe ich Bescheid.
Volker

danke für eure unterstützung ..