Fehler: Plötzlich keine KNX-Kommunikation mehr nach Update auf V2.00?

[JonDonSponky]

Hallo miteinander!

Ich bin sehr verwirrt und komme nicht auf die Ursache des Problems:

Letztes Wochenende habe ich EDOMI auf die Version 2.00 upgedatet, nachdem ich das Arbeitsprojekt seit ca. zwei Jahren am Laufen habe und bis zur Version 1.64 auch keine Probleme. Doch seit dem Update bleibt plötzlich in unregelmäßigen Abständen die KNX-Kommunikation hängen...

Unbenannt.PNG
Nur zum Verständnis, Edomi hängt sich nicht auf, ich komme auf die Visu, es werden bloß keine KNX-Telegramme mehr empfangen. Durch einen Neustart ist dann das Problem wieder behoben, aber es tritt in unregelmäßigen Abständen wieder auf (ein bis zwei mal pro Tag, heute um ca. 8Uhr und eben um 15:10).

Ich bin total ratlos und hoffe mit eurer Hilfe auf die Ursache bzw. Lösung des Problems zu kommen.

Bin für alle Ideen offen!

[JonDonSponky]

So, konnte das Problem ein wenig einkreisen.

Scheinbar liegt es an meinem QNAP-NAS was ebenfalls im Netzwerk arbeitet. Hier habe ich ebenfalls ein Firmware-Upgrade (V4.4.1) durchgeführt und das scheint mir die unerklärlichen Abbrüche im KNX-Stream zu erzeugen. Wie da sein kann, eine Ahnung, vielleicht kann mir von euch einer auf die Sprünge helfen...

Jedenfalls habe ich auch bei QNAP ein Supportticket eröffnet, da die Netzwerkadapter seit dem Upgrade im Zusammenhang mit dem Ruhezustand nicht richtig funktionieren.

[pitschr]

Bist sicher, dass QNAP der Übeltäter ist? Wie / womit hast du dein Problem eingekreist? Läuft dein Edomi auf QNAP? Wenn ich recht informiert bin, dann läuft Edomi nur im Tunneling - Modus, d.h. 1:1 Kommunikation weshalb "andere" Pakete (wie z.B. Broadcast) nicht stören sollten. Die Paketverluste aufgrund UDP sind extrem unwahrscheinlich, und wenn, dann sollte - spätestens - der 2. UDP Frame ankommen. Ausser du hast grössere Netzwerkprobleme.

Gibt es einen Grund, warum QNAP überhaupt mit Edomi oder/und KNX Router/Interface kommuniziert? Wenn nein -> bearbeite deine Firewall-Einstellungen

Für weitere Analyse nutze z.B. WireShark und finde die Gemeinsamkeiten heraus was die Abbrüche erklären könnten (beachte dann alle: QNAP, Edomi, KNX NET/IP Device). Damit kannst du diese Probleme einfacher und schneller eingrenzen.

[JonDonSponky]

Bist sicher, dass QNAP der Übeltäter ist?

Ja, kann ich schon, da kurz nach dem Start aus dem Ruhezustand (kein regulärer Start) Edomi seine Kommunikation einstellt.

Läuft dein Edomi auf QNAP?

Nein, Edomi läuft schön brav auf einer eigenen Hardware (apu2d4).

Ausser du hast grössere Netzwerkprobleme.

Sind mir nicht bekannt, jedenfalls läuft sonst alles wie es soll...

Gibt es einen Grund, warum QNAP überhaupt mit Edomi oder/und KNX Router/Interface kommuniziert?

Die QNAP sollte eigentlich gar nicht mit Edomi kommunizieren, lediglich andersherum für Backups. Wenn deine Frage in Richtung VLAN für KNX-Kommonenten abzielt, dann nein, hier hab ich mich noch nicht ran gewagt.

WireShark

Danke für den Tipp, werde ich kommendes Wochenende mal probieren und berichten.

[pitschr]

Wenn deine Frage in Richtung VLAN für KNX-Kommonenten abzielt, dann nein, hier hab ich mich noch nicht ran gewagt.

Hier dachte ich an Einstellung mittels iptables (oder über Switch, je nachdem). VLAN wäre eher sinnvoll für Isolation in Bereichen wie z.B.: 1) Privat, 2) Gäste und 3) IoT (=Fernseher, Mähroboter, Waschmaschine, Backofen, ...). Mit anderen Worten, QNAP und Edomi wären in diesem Fall im selben VLAN. Wir wollen uns ja nicht zu sehr einschränken ;-)

---

Zurück zu QNAP. Ich gehe davon aus, dass dein QNAP sowieso eine statische IP-Adresse hat. In deinem Fall wäre diese Zeile wohl ausreichend (auf EDOMI CentOS):

iptables -A INPUT -s <QNAP IP-Adresse> -j DROP

Mach jedoch vorher ein Backup:

iptables-save > backup.iptables

und
Wiederherstellung mit:

iptables-restore < backup.iptables

Und wenn du dir sicher bist, dass deine Firewalleinstellungen passen:

service iptables save

weitere Infos, siehe: https://wiki.centos.org/HowTos/Network/IPTables