Probleme mit KNXnet/IP-Tunnel und Routeranbindung

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

[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]

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

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

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

[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

[saegefisch]

Hallo Christian,
danke für Deine rasche Rückmeldung.

Ich gehe auch nicht davon aus, dass es Edomi ist, aber doch fällt es mir (und anderen) schwer, die Ursache einzukreisen. Ich denke, dazu dient dieses Thema. Dass für Dich da wenig erhellendes dabei ist, liegt auf der Hand. Bei Dir tritt es ja auch nicht auf...

Mit Vergleichsrouter kann ich leider nicht dienen. Meine Vermutung ist der Enertex (so wie bei anderen Gira andere Probleme zu machen scheint), das LAN sehe ich eher weniger. Und: Ja, sporadische Fehler sind ein Graus, es liegt auf der Hand, dass da etwas "dazwischen funkt". Aber genau darum geht es ja hier: Die gemeinsame Suche nach Mustern, um der Ursache auf die Schliche zu kommen. Ich kann z.B.die ETS als Ursache beim Enertex ausschließen.

Ein eigenes Log erschien mir zwar sinnvoll, aber ich kann sehr gut nachvollziehen, dass es wichtigeres gibt. Einzig die Angabe der Sequenz-Fehler in der Visu finde ich weiterhin wenig sinnvoll für einen produktiven Betrieb - das reduziert durchaus den WAF... Daher: In der Admin-Sicht: klar. Mail bei Auftreten: ist auch eine gute Idee. Aber solange der Betrieb nicht gefährdet ist oder wirklich eine Fehlfunktion auftrat, erscheint es mir tatsächlich zu prominent.
Andererseits könnte man auch sagen: Hey, ist beta-Stadium, da muss es an prominente Stelle. ok, ist auch eine Sicht. Allerdings habe ich schon unfassbar viel Zeit mit "fertiger" SW verbracht/verbringen müssen, die bei weitem nicht den Stand von Edomi als beta hatte...

[gaert]

Eigentlich zeigt dies recht deutlich, dass das Problem nicht bei EDOMI zu suchen ist... Denn EDOMI macht immer das gleiche (bzw. der KNX-Stack). Sporadische Fehler sind daher recht "unlogisch" aus Entwicklersicht, d.h. hier funkt irgendetwas anderes dazwischen (Netzwerk, Bus, Router, ...).

Ein eigenes SeqCounter-Log halte ich für etwas übertrieben Und Fehler (jaja) in der KNX-Kommunikation gehören m.E. durchaus auch in die Visu - schließlich "lebt" die Visu irgendwie von KNX...

EDIT:
Ich muss mich hier erstmal ausklinken, denn ich kann aktuell eh nicht weiterhelfen... Die Logs kenne ich inzwischen auswendig - aber das bringt mich nicht weiter in Sachen Erkenntnisgewinn Wie gesagt: Ein "Vergleichsrouter" ist m.E. die einzig sinnvolle Herangehensweise: In ein und derselben KNX-Installation mal ne Woche mit dem einen und dann ne Woche mit dem anderen Router loggen. Am Besten ein Modell, dass definitiv keine Probleme macht (z.B. mein Eibmarkt-Teil).

[saegefisch]

Hi,

auch mit Enertex bekomme ich tagelang gar keine Meldungen, dann mal sehr viele. Fehler tauchen auch auf, wenn keine ETS aktiv ist (die ist bei mir nur selten aktiv, da im wesentlichen alles steht).

Oft sah ich früher, dass Soll und Ist um einen oder wenige abwichen. Gestern hatte ich dieses...ein ganzer Sack zu einem einzigen Soll:

2016-05-08 00:32:18    453891    KNX    1441    ROUTER @ DE | TUNNELING_REQUEST / ErrMsg: SequenceCounter abweichend (noACK): Ist-Wert=170, Soll-Wert=169 / Raw: 0610042000160471aa00290084d0ff0c011202008006    ERROR
2016-05-08 00:32:19    380708    KNX    1441    ROUTER @ DE | TUNNELING_REQUEST / ErrMsg: SequenceCounter abweichend (noACK): Ist-Wert=170, Soll-Wert=169 / Raw: 0610042000160471aa00290084d0ff0c011202008006    ERROR
2016-05-08 00:32:19    413248    KNX    1441    ROUTER @ DE | TUNNELING_REQUEST / ErrMsg: SequenceCounter abweichend (noACK): Ist-Wert=171, Soll-Wert=170 / Raw: 0610042000190471ab002900bce011082b5c050080436075c3    ERROR
2016-05-08 00:32:20    379380    KNX    1441    ROUTER @ DE | TUNNELING_REQUEST / ErrMsg: SequenceCounter abweichend (noACK): Ist-Wert=171, Soll-Wert=170 / Raw: 0610042000190471ab002900bce011082b5c050080436075c3    ERROR
...
NX    1441    ROUTER @ DE | TUNNELING_REQUEST / ErrMsg: SequenceCounter abweichend (noACK): Ist-Wert=254, Soll-Wert=170 / Raw: 0610042000190471fe002900bce011072b5b050080431523d7    ERROR
2016-05-08 00:34:26    532860    KNX    1441    ROUTER @ DE | TUNNELING_REQUEST / ErrMsg: SequenceCounter abweichend (noACK): Ist-Wert=255, Soll-Wert=170 / Raw: 0610042000190471ff002900bce011072b5b050080432f7852    ERROR
2016-05-08 00:34:27    523542    KNX    1441    ROUTER @ DE | TUNNELING_REQUEST / ErrMsg: SequenceCounter abweichend (noACK): Ist-Wert=255, Soll-Wert=170 / Raw: 0610042000190471ff002900bce011072b5b050080432f7852    ERROR
2016-05-08 00:34:27    679872    KNX    1441    ROUTER @ DE | TUNNELING_REQUEST / ErrMsg: SequenceCounter abweichend (noACK): Ist-Wert=0, Soll-Wert=170 / Raw: 061004200019047100002900bce011062b490500803d75c28f    ERROR
2016-05-08 00:34:28    624604    KNX    1441    ROUTER @ DE | TUNNELING_REQUEST / ErrMsg: SequenceCounter abweichend (noACK): Ist-Wert=0, Soll-Wert=170 / Raw: 061004200019047100002900bce011062b490500803d75c28f    ERROR
2016-05-08 00:34:28    635535    KNX    1441    ROUTER @ DE | TUNNELING_REQUEST / ErrMsg: SequenceCounter abweichend (noACK): Ist-Wert=1, Soll-Wert=170 / Raw: 061004200019047101002900bce011072b5b050080431730a4    ERROR
....
NX    1441    ROUTER @ DE | TUNNELING_REQUEST / ErrMsg: SequenceCounter abweichend (noACK): Ist-Wert=168, Soll-Wert=170 / Raw: 0610042000170471a8002900bce0111434960300800c5b    ERROR
2016-05-08 00:40:36    960742    KNX    1441    ROUTER @ DE | TUNNELING_REQUEST / ErrMsg: SequenceCounter abweichend (ACK): Ist-Wert=169, Soll-Wert=170 / Raw: 0610042000190471a9002900bce011072b5b0500804314f5c3    ERROR

* Was könnte die Ursache für die minutenlange Suche nach dem einen Soll-Wert sein? KNX-Schnitstelle und Edomi stecken am selben Switch in unmittelbarer Nähe zum Switch. Auf Netzwerk würde ich da weniger tippen.
* Wenn das doch keinen "echten" Fehler sind, aber wichtige Hinweise, denen man durchaus nachgehen sollte, scheint mir sinnvoll, den LOG-Level nicht zu reduzieren. Doch bläht es aus meiner Sicht das Fehler-Log so auf, dass "echte" Fehler etwas untergehen. Wäre es nicht vielleicht sinnvoll, die Meldungen nicht zu unterdrücken, aber sie in ein eigenes SequenceCounter-Log auszulagern? Wenn es problemlos läuft wie bei Dir, Christian, dann hast Du das Log gar nicht. In der Admin-Sicht von Edomi sollten die Fehler auch als Fehler angezeigt werden "0 Fehler / 731 Sequence-Fehler im Log". In der Visu sollten nur die "echten" gezeigt werden. Als Admin sehe ich die und gehe den nach, aber meine Familie interessiert sich dafür nur wenig, solange alles an sich funktioniert.

Viele Grüße,
Carsten

[gaert]

Klar, es ist strenggenommen ein Fehler - daher bleibt das Verhalten auch so (ab ins Fehlerlog damit). Nur hat der Fehler im Regelfall keine Auswirkung. Ähnlich eines defekten Bits auf einer CD: Ist ein Fehler, wird aber korrigiert

Normal ist dieser Fehler/Hinweis/Notice/was-auch-immer jedenfalls nicht - ich habe und hatte immer ein komplett leeres Fehlerlog in Bezug auf die KNX-Kommunikation, und das seit über einem Jahr inzwischen... Und ich nutze EDOMI produktiv als zentrales Hirn meiner gesamten Installation!

Das Thema "Sequence-Counter" wird in der Spezifikation zwar recht sparsam behandelt, aber dafür sehr eindeutig (vereinfacht dargestellt):
- entspricht der SC der Erwartung (also dem internen Zählerstand des Servers) wird geACKed und das Telegramm wird verarbeitet
- entspricht der SC der Erwartung-1 wird auch geACKed, aber das Telegramm wird verworfen
- trifft beides nicht zu, wird nicht geACKed und das Telegramm wird verworfen

Mehr gibt die Spec nicht her und EDOMI hält sich penibel daran. Daher tippe ich eher auf Netzwerkfehler o.d.G. - weniger auf Router/Schnittstellen-Probleme. Wie gesagt wäre es äußerst sinnvoll, wenn jemand verschiedene Router an ein und der selben Installation testen könnte! Ich kann's nicht - hab nur einen

[DirtyHarry]

Nochmal zum mitschreiben... das ist kein Fehler!!!!! Das ist ein Hinweis... Ein Fehler wäre es erst, wenn das Telegramm endgültig verloren wäre! Ist es aber nicht, es wird doch nur wiederholt...

Du hast es beim Programmieren doch als Fehler deklariert.

Ich lasse mir mal etwas einfallen

Spitze.

Vielleicht nur als Hinweis deklarieren... Wobei es ja streng genommen doch ein Fehler ist, wenn auch einer der automatisch korrigiert wird. Aber im Idealfall sollte er halt selten bis gar nicht auftreten. Was er, vermutlich, in einem sauberen Netzwerk mit einem streng nach Spezifiation arbeitenden Router/Schnittstelle auch tun wird.

Werde wohl doch mal irgendwann separate Hardware für Edomi anschaffen, testweise mit nem zweiten Router ne separate Linie aufmachen und darin die IP-Schnittstelle mit vollständig getrenntem Netzwerk zu Edomi. Gehe davon aus, dann taucht das gar nicht mehr auf. (Habe bei mir im Büro keinen direkten Zugriff auf den Bus, deshalb muss ich mir anderweitig den direkten Buszugriff erzeugen. Und da wo die Schnittstelle aktuell sitzt, mag ich keine Testumgebung aufbauen...)

[gaert]

Dann setze doch einfach das LogLevel auf 0... Gut, dann werden natürlich garkeine KNX-Fehler mehr geloggt. Ich lasse mir mal etwas einfallen

[stonie2oo4]

Nochmal zum mitschreiben... das ist kein Fehler!!!!! Das ist ein Hinweis... Ein Fehler wäre es erst, wenn das Telegramm endgültig verloren wäre!

Das hab ich ja verstanden, funktioniert ja auch alles wunderbar .
Is halt bloß nervig, das in der Visu oben immer hunderte bis tausende Fehler in Rot eingeblendet werden.
Deswegen hätt ichs gern abgestellt, ansonsten würds mich nicht stören, da ja die Funktion gegeben ist.

[stonie2oo4]

ja wie? Ich dachte mit dem WG läuft alles?! Soll ich mir die Arbeit etwa sparen?!

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

[gaert]

Nochmal zum mitschreiben... das ist kein Fehler!!!!! Das ist ein Hinweis... Ein Fehler wäre es erst, wenn das Telegramm endgültig verloren wäre! Ist es aber nicht, es wird doch nur wiederholt...