Probleme mit KNXnet/IP-Tunnel und Routeranbindung

[gaert]

Es geht mir nicht darum EDOMI unter allen Umständen als "unschuldig" zu deklarieren - vielmehr muss doch das Ziel sein, die Ursache für diese Problematik aufzudecken. Daher möchte ich die Diskussion mal in eine andere Richtung lenken, damit wir in dieser Sache weiterkommen. Feststellungen wie "mit dem HS geht's, mit EDOMI nicht" bringen uns mittlerweile nicht wirklich weiter, denn das greift irgendwie zu kurz

Daher wäre es m.E. deutlich zielführender, wenn wie gesagt ein Vergleichsrouter eingesetzt werden würde (einer, der nachgewiesener Maßen keine Probleme verursacht). Alles andere verwirrt letztlich nur und mündet irgendwie in der Parawissenschaft... Am Ende ist's der Sonnenwind und die Mondphase

[MarkusS]

Im Prinzip sollte das doch _relativ_ einfach sein:

Mit einem Rechner den Netzwertraffic (Wireshark, Switch mit SPAN-Port) und KNX-Traffic aufzeichnen - Ein Rechner damit die Zeitstempel im Sync sind, sonst ist das ein Albtraum. Mit so einer Protokollierung könnte man zumindest sehen ob die Fehlermeldung überhaupt zutrifft. Könnte ja ganz theoretisch sein dass Edomi da was falsch interpretiert...

Ganz toll wäre es wenn man gleichzeitig mit Wireshark zwei Switch-Ports abgreifen könnte, den Port in dem der KNX-Router steckt und den Port in dem Edomi steckt.

Für die KNX-Seite sollte die ETS zum Aufzeichnen reichen, ich kann aber gerne auch leihweise meinen Eibdoktor zur Verfügung stellen - was Fehler angeht geht der deutlich tiefer als die ETS. Ich kann auch gerne einen Enertex- und/oder Gira-Router leihweise zur Verfügung stellen.

das aufzeichnen sollte jemand machen bei dem der Fehler auch auftritt.

[MIT]

Hab nen Entertex Router, Wiregate hängt halt per IP am Bus.
Obs nur mit Wiregate funktioniert, weiß ich nicht, hab ich nicht getestet.

Also - nur mal so zur Info - bei mir läuft es mit dem WireGate und RS232 TP-UART ohne Probleme (seit Januar 24/7).

[gaert]

Danke für Dein Feedback (MIT) - und besten Dank für das Angebot (MarkusS).

Da das Problem offenbar trotz gleicher Hardware (Router/Wiregate) bei einigen Nutzer auftritt und bei anderen nicht, liegt der Verdacht nahe.....

Zu "interpretieren" gibt's bezüglich des SeqCounters eigentlich nicht viel - ist halt ein Byte 0..255 und fertig

[fisch3009]

Um das Problem vielleicht ein bisschen eingrenzen zu können.
Bei mir lief EDOMI bisher in einer VirtualBox VM. Nachdem ich meinen Server neu aufgesetzt hatte, habe ich EDOMI neu in eine Hyper-V VM installiert und im Zuge dessen auch den LBS Hostcheck wieder aktiviert (war vorher deaktiviert). Seit dem hatte ich auch ohne Ende SequenceCounter Fehler.
Seit ich die Logik mit Hostcheck deaktiviert habe, habe ich seit 3 Tagen keinen einzigen SequenceCounter Fehler mehr.
Ich meine aber, dass ich den Hostcheck auch schonmal ne Weile in meiner VirtualBox VM am laufen hatte ohne die Fehler, das kann ich jetzt aber nicht mehr nachstellen. Vielleicht hilft das ja bei der weiteren Analyse.

[gaert]

Ohne den LBS jetzt genauer zu kennen: Dieser "macht" offenbar Netzwerk... Hat mit dem SeqCounter natürlich erstmal rein garnichts zu tun - allerdings könnte durchaus die Netzwerk-Kommunikation "gestört" werden (v.a. in einer VM).

[SeatSLF]

Die Seq.Counter Fehler kommt auf einem dedizierten Rechner.
Das einzige was bei mir noch mit Netzwerk zutun hat außer dem Edomi, ist die Wetteranfrage aber die Fehler habe ich auch ohne die.

Gibt es jemanden außer Christian der keine solche Fehler hat?

[Dragonos2000]

Bis jetzt zumindest bei mir. Allerdings hab ich es bisher nur 2 Tage durchgängig laufen lassen. Da es bei manchen schon nach Stunden, aber anderen erst nach Tagen zum Fehler kommt, ist das für eine belastbare Aussage wohl zu kurz.

[wintermute]

Gibt es jemanden außer Christian der keine solche Fehler hat?

Ich - noch nie gesehen... weder in einer VM, noch auf dedizierter Hardware.
KNX-Anbindung ueber eine 750er Wago, Verbindung zwischen der Wago und Edomi laeuft ueber einen "unsmarten" REG-Switch von Phoenix Contact (an dem die Wago haengt) zu einem "smarten" D-Link an dem dann der Hypervisor haengt bnzw nochmal zu einem "unsmartem" D-Link an dem die dedizierte Hardware angeschlossen ist (die im uebrigen 2 Interfaces im Bonding betreibt wovon aber momentan nur eines angeschlossen ist).
Und auch wenn ich "meinen" Hostcheck-Baustein aktiviere kommen keine Fehler

[MarkusS]

Ich will das nicht beschreien weil mein Edomi ist so alt dass "gut abgehangen" da nicht mehr treffend ist - aber ich habe diesen Fehler bei mir nie gesehen.

Werde Pfingsten mal nutzen und meine Installation in die Tonne treten und von Grund auf neu machen.

[Simone]

Mein letzter Fehler dazu war am 1.5. aber nur ein einzelner (am 5.5 wurde auf 1.32 aktualisiert)


-Edomi 1.32 (eben erst gesehen, dass ich schon wieder hinterher bin)
-verwendete Bausteine: Ausgangsbox, Termin Reminder by RD, ics Cal Dav Kalender, Datum/Zeit

-VM Hyper-V, Host hängt an einem Switch
-Fritzbox neueste Version
-Siemens IP Schnittstelle 148

 [TABLE="class: log, border: 0, cellpadding: 0, cellspacing: 0, width: 1, height: 12"]
 	 		[TR]
 			[TD]2016-05-01 00:00:00[/TD]
 			[TD]397928[/TD]
 			[TD]EXEC[/TD]
 			[TD]20649[/TD]
 			[TD]Logs/Archive/Autobackups aufräumen[/TD]
 			[TD]Ok[/TD]
 		[/TR]
 		[TR]
 			[TD]2016-05-01 00:00:01[/TD]
 			[TD]132065[/TD]
 			[TD]EXEC[/TD]
 			[TD]20671[/TD]
 			[TD]Autobackup erstellen: 2016-05-01-000001.edomibackup[/TD]
 			[TD]Ok[/TD]
 		[/TR]
 		[TR="class: sErr"]
 			[TD]2016-05-01 07:38:23[/TD]
 			[TD]711000[/TD]
 			[TD]KNX[/TD]
 			[TD]6737[/TD]
 			[TD]ROUTER @ DE | TUNNELING_REQUEST / ErrMsg: SequenceCounter abweichend (ACK): Ist-Wert=4, Soll-Wert=5 / Raw: 061004200017044004002900bce011081c01030080141a[/TD]
 			[TD]ERROR[/TD]
 		[/TR]
 		[TR]
 			[TD]2016-05-02 00:00:00[/TD]
 			[TD]152275[/TD]
 			[TD]MAIN[/TD]
 			[TD]6641[/TD]
 			[TD]Aktuell: CPU 21% / RAM 10% / HDD 14% / LOAD 1.02% / PHP 6 / HTTP 3[/TD]
 			[TD]Ok[/TD]
 		[/TR]
 		[TR]
 			[TD]2016-05-02 00:00:00[/TD]
 			[TD]155963[/TD]
 			[TD]MAIN[/TD]
 			[TD]6641[/TD]
 			[TD]Peaks : CPU 100% / RAM 10% / HDD 14% / LOAD 1.67% / PHP 7 / HTTP 4[/TD]
 			[TD]Ok[/TD]
 		[/TR]
 		[TR]
 			[TD]2016-05-02 00:00:00[/TD]
 			[TD]400232[/TD]
 			[TD]EXEC[/TD]
 			[TD]51877[/TD]
 			[TD]Logs/Archive/Autobackups aufräumen[/TD]
 		[/TR]
 	 [/TABLE]

[panzaeron]

Ich habe diese Fehler auch noch nicht gehabt, mein Zugriff erfolgt über einen älteren Weinzierl KNX IP LineMaster 760 (älteres Modell mit nur einem möglichen Tunnel) und zwei kleinen Cisco Switchen dazwischen...
Edit: EDOMI lief erst in einer Virtualbox VM, jetzt auf einem MSI N3150I ECO beide ohne diesen Fehler...

[gaert]

Ich tippe tatsächlich auf eine "instabile" Netzwerkverbindung - die Kommunikation erfolgt schließlich via UDP, also quasi verbindungslos (nicht wirklich, aber so in Etwa). Das heißt: Wenn ein UDP-Paket auf die Reise geht wird dieses nicht(!) vom Networklayer bestätigt, wie z.B. bei TCP/IP. Vielmehr müssen die Kommunikationspartner selbst dafür sorgen, was der KNX-Stack bzw. der Router auch macht. Nur wenn ein Paket verloren geht, "merkt" der SeqCounter dies und stimmt eben nicht mehr mit der Erwartung überein => "Fehler"-Meldung...

[NurMa]

Auch bei mir gibt's den Fehler bei Dauerbetrieb fast durchgängig seit Beta Release nicht mehr.

Anbindung ist ein Enertex Router mit aktueller Firmware.

Vor dem FW-Update hatte ich die LOG-Einträge ab und an. Seither ist Ruhe.

[baumhaus123]

Ich wollte mal meine aktuellen Erfahrungen zu diesem Thema durchgeben:
Ich hatte seit Einsatz von Edomi die hier beschriebenen Sequencecounter Fehler. Diese tauchten nach ca. 1-2 Stunden nach Projektaktivierung zum ersten Mal auf, nach ca. 10 Stunden ist regelmäßig das Errorlog auf ein paar tausend Einträge gewachsen, das ging so weit, dass irgendwann meine Logiken und die Visu nicht mehr richtig funktioniert haben.

Mein Setup ist relativ simpel: Enertex IP Router mit aktueller Firmware, verbunden mit Switch, an dem auch der Edomi-Server hängt. Switch hängt an der Fritzbox. Ich habe dann sämtliche Kombinationen ausprobiert von alle IP- Geräte abziehen und nur IP-Router und Edomi verkabeln, IP-Router und Edomi-Server an einem separaten Switch, beide direkt an der FB, neue Patchkabel getestet, alle möglichen Parameter-Einstellungen im Enertex ausprobiert. Half alles nix, die Fehler sind immer wieder aufgetaucht, was mich ganz schön frustriert hat.

Nun habe ich in den sauren Apfel gebissen und mir einfach mal den aktuellen MDT IP-Router bestellt, weil das meine letzte Hoffnung war. Ausgepackt, angeschlossen, parametriert - und seitdem keinen einzigen Fehler mehr. Setup ist dabei unverändert, aktuell läuft Edomi seit knapp zwei Tagen fehlerfrei. Scheinbar lag es bei mir am Router, oder zumindest an der Kombination Router i.V.m. meinem Setup. Edomi läuft übrigens nach wie vor in einer VM, die war also auch nicht schuld.

Jedenfalls bin ich sehr happy, dass ich Edomi jetzt uneingeschränkt genießen kann.