Probleme mit KNXnet/IP-Tunnel und Routeranbindung

[gaert]

salixer
EDOMI hält sich an diese "Gesetze" aus der Spezifikation (oder sollte es zumindest tun - ich prüfe das nochmal):

If a KNXnet/IP Tunnelling Client receives a frame with a sequence number that equals the expected sequence number then it shall reply with a TUNNELLING_ACK (Status = E_NO_ERROR) frame and process the received frame.

If a KNXnet/IP Tunnelling Client receives a frame with a sequence number that is one less than the expected sequence number then it shall reply with a TUNNELLING_ACK (Status = E_NO_ERROR) message and discard the received frame.

If a KNXnet/IP Tunnelling Client receives a frame with a sequence number that is not equal to the expected sequence number and not equal to one less than the expected sequence number, the KNXnet/IP Tunnelling Client shall not reply and shall discard the received frame.


EDIT:
Im Code ist es korrekt implementiert - hier ein Auszug:

...
                                        } else if ($receiveRtg==($dE_seqCounterReceive-1)) {
                                            //ACK und verwerfen
                                            $dE_ACK=true;
                                            $dE_seqCounterReceiveINC=false;
                                            trace(true,'ROUTER @ DE | TUNNELING_REQUEST / Hinweis: SequenceCounter abweichend (ACK): Ist-Wert='.$receiveRtg.', Soll-Wert='.$dE_seqCounterReceive.' / Raw: '.bytesToHex($response));
                                            $SRAM[6]++;
                                        } else {
                                            //kein ACK und verwerfen
                                            $dE_ACK=false;
                                            $dE_seqCounterReceiveINC=false;
                                            trace(true,'ROUTER @ DE | TUNNELING_REQUEST / Hinweis: SequenceCounter abweichend (noACK): Ist-Wert='.$receiveRtg.', Soll-Wert='.$dE_seqCounterReceive.' / Raw: '.bytesToHex($response));
                                            $SRAM[6]++;
                                        }
... 

EDIT2:
Ich glaube ich stand damals auf'm Schlauch?!

} else if ($receiveRtg==($dE_seqCounterReceive-1)) {...

ist genau falsch herum - richtig wäre wohl "+1" statt "-1"

Dies ist möglicherweise bereits die Lösung für das Problem! Ich werde dies im nächsten Update korrigieren und dann schauen wir weiter. Sorry für die Umstände!

Allerdings erklärt dies natürlich noch nicht, warum überhaupt Telegramme verloren gehen - bei mir ging noch nie(!) ein Telegramm verloren...

EDIT3:
Quatsch. Ich habe die Variablen verwechselt... $receiveRtg ist der SeqCounter "vom Bus" - insofern stimmt's.

[Simone]

salixer
dann wünsch ich dir einen schönen Urlaub

ja Siemens IP Schnittstelle, dann warten wir mal auf die Router von Enertex Router

danke für die Info´s

[salixer]

Simone
Du hast ja den Siemens Router? In deinem EDOMI Log sieht man folgendes Problem: Der Router sendet ein Telegramm mit der Nummer 72, EDOMI erwartet aber schon Telegramm mit Nummer 73. Das passiert, wenn das TUNNELING_ACK von EDOMI zum Router verloren geht (Der Router wiederholt dann das Telegramm mit der Nummer 72).
gaert
EDOMI verwirft zwar das Telegramm (korrekt) verpasst aber, hier trotz falscher Nummer (die Nummer ist genau um 1 kleiner als erwartet) ein TUNNELING_ACK an den Router zu schicken. So tritt der Fall ein, dass der Siemens Router aufgrund ausbleibenden ACKs immer wieder mit Nummer 72 sendet.
Weiterer Vorschlag: Wird erkannt, dass Telegramme mit einer Nummer rein kommen, die höher als erwartet ist, kann man sicher sein, dass ein Telegramm auf dem Weg zu EDOMI verloren wurde. In dem Fall einen DISCONNECT schicken und die Verbindung neu aufbauen.

P.S. Nochmal der Hinweis, dass ich die nächsten beiden Wochen nicht mitlesen werde...

[Simone]

Ich hab jetzt noch die Schnittstelle auf die Fritzbox gesteckt, da war dann natürlich die Verbindung unterbrochen, als ich ins Log geschaut habe waren auf einmal diese Fehler von 14:07 (da hab ich den Hyper-V, VM Edomi) kurz umgesteckt.Die Fehler hab ich davor nicht gesehen?Übersehen oder hat Edomi die erst jetzt beim Ausfall der Schnittstelle ins Log geschrieben

hier sieht man die Uhrzeit 14:07 Fehler im Edomi Log
Log-Edomi.PNG

und die Fritzbox logs haben genau um 14:07 gestartet so heißt zumindest die Datei, sind da Einträge dabei die was helfen?
die 192.168.1.12 ist die Edomi VM 1 ist die Fritzbox und 24 die IP Schnittstelle

Das log ist jetzt aber vom Port des Hyper-VLog-WS.PNG

[Simone]

Zwischenstand vom Zaubern

Parallel
Edomi Busmonitor gestartet
ETS gestartet
Ets Gerät programmiert, danach Physikalische Adressensuche
Surface Windows Updates laden
Ipad Youtube Video aufgerufen
Squeeze Musik eingeschalten

Zusätzlich
Edomi Projekt aktiviert
Edomi neugestartet
Telegramme zwischenzeitlich auf 20 gestellt

Keine Fehler, ich glaub das verantwortliche gerät will nicht, dass wir den Fehler finden


Neu im Netzwerk wäre
ich habe den Hyper-V direkt auf den Port der Fritzbox gesteckt

edit: ja ich weiß ich soll den Port von der Schnittstelle loggen, das muß ich noch umstecken, bissel schwieriger weil Schnittstelle POE und Fritzbox hat ja kein POE

[salixer]

Am besten den Switch-Port, an dem der KNXnet/IP Router hängt spiegeln und dort alles mitschneiden. Aktuelles Wireshark benutzen.

EDIT: Oder mit der Fritzbox versuchen...

[Simone]

ok, die Fritzbox soll das wohl auch können. Ich probier das mal, obwohl ich mit dem Log vermutlich nichts anfangen kann
Capture.PNG

[enertegus]

Direkt was am Host ankommt spiegeln, wär das Beste. Ob es dann am Ende in der VM stecken bleibt oder im Host etc. wäre ja erst mal egal

[Simone]

Muß für das Wireshark Log der Edomi Port gespiegelt und geloggt werden (in der VM dann eher schwierig)? und dann irgendwie Fehler herbeizaubern

[enertegus]

EDOMI läuft i.d.R. ja auf relativ performanter x86-Hardware, von daher glaube ich eher weniger an ein Performanceproblem seitens EDOMI. !

Aus meiner Hardwareerfahrung kann ich sowas nicht ausschließen: Auch im EibPC gab es anfangs genug Nettigkeiten, die man so nicht gedacht hatte. i.d.R. sagt auch nicht aus, was sonst noch so läuft, und die Top Auswertung ist sicher nicht granular genug Es kommt wohl hier z.B. auf die Rückmeldungezeit an (muss <1s sein).
Ich sage sicher nicht, dass Edomi ein Performancefresser ist, das wir noch nie einen Fehler in der Software hatten - die Unterschiede zum eibd und Edomi kenn ich nicht. Von dieser Ecke z.B. Smarthome.py, etc. gabs da nie gemeldete Probleme.

[gaert]

EDOMI läuft i.d.R. ja auf relativ performanter x86-Hardware, von daher glaube ich eher weniger an ein Performanceproblem seitens EDOMI. Die KNX-Kommunikation läuft als eigenständiger Prozess und braucht so gut wie keine Ressourcen (top). Das "Nadelöhr" wäre maximal der DB-Zugriff (Queue), aber das spielt nur EDOMI-intern eine Rolle - nicht nach aussen (Netzwerk). Und für mich ist das wichtigste Indiz die Tatsache, dass es mit anderen Routern funktioniert (dies meine ich jetzt nur hinsichtlich der Performance - etwaige Fehler in der Implementierung seitens EDOMI kann ich natürlich nicht ausschließen).

Was ich dann allerdings nicht verstehe: Warum funktioniert's offenbar mit eibd/HS/etc.? Welche Telegrammrate nutzt eibd/knxd überhaupt?!

[enertegus]

- lahme Hardware/Netzwerk kann doch ausgeschlossen werden,

grundsätzlich sind die KNX Router stark unterschiedlich performant. Während für das Routing ein Performancetest Bestandteil der KNXnetIP Prüfung ist, ist das für das Tunneling nicht der Fall (ob es das inzwischen ist, weiß ich nicht). Offenbar tritt das Problem bei Telegrammratenbegrenzung nicht auf, d.h. der Edomi schickt nicht weniger als z.B. 10 Telegramme pro Sekunde. Unsere telnet-Verbindung sagt bei den Usern die das probiert haben, dass, wenn da mehr als 10 Telegramme geschickt werden, die Telegramme, die der Router an Edomi schickt, nicht beantwortet werden (In unseren Tests, schafft unser Router bei Tunnelverbindung dauerhaft >35 Telegramme/s).
Und das ist dann eben der Punkt. Wenn es stimmt, dass die Telegramme nicht mehr vom Edomi verarbeitet werden, läge das Problem auf der Edomi Seite, wenn nicht auf der Router Seite. Rausfinden kann man das eben nur mit Wireshark, weil der Log würde zeigen: Die Telegramme kommen erst gar nicht vom Edomi auf das LAN oder - kommen und werden dann aber nicht vom Router sauber verarbeitet. Dass der Fehler zudem z.B. beim Videostreamen häufiger auftritt oder wegen mir bei Edomi in der VM eher als im nativen System, ist zumindest ein Indiz...aber wie gesagt, können wir auch so belassen.

[Simone]

Hi,

erstmal finde ich es toll, dass sich Enertex/ salixer für sowas Zeit nimmt.

Ich habe die Fehler auch mit einer Siemens IP Schnittstelle (Beitrag 536) und werde das Problem mittelfristig wie Baumhaus123 mit einem empfohlenen Router zb. MDT lösen

Da es mich trotzdem interessiert was da eigentlich los ist, hier meine Überlegungen/Zusammenfassung

- lahme Hardware/Netzwerk kann doch ausgeschlossen werden, wenn es mit dem MDT Router keine Probleme mehr gibt (Rückmeldung @Baumhaus123
- wenn die Fehler bei mir auftreten manchmal nur 50 oder auch über 1000 werden in dieser Zeit meine Datenarchive nicht mehr befüllt, danach schreibt er wieder ins Archiv
- vermutlich wird in dieser Zeit auch eine Information vom Bus an Edomi verloren gehen (nocht nicht getestet) zb. KO-Lastüberschreitung >LBS aktivieren
- die Fehler kommen bei mir nicht unbedingt sofort nach dem Start von Edomi, es gibt wie von anderen bereits erwähnt keinen bestimmten Rhythmus
- was macht der MDT anders?

Aktuell teste ich mit 15 Telegrammen/sek. (wieder Fehler) als nächstes werde ich 10 Telegramme wie von Woda empfohlen testen

[salixer]

Wollte noch anmerken, dass ich die nächsten beiden Wochen Urlaub habe. Da wird sich bezüglich Firmware oder Wireshark-Log prüfen von unserer Seite also erst mal nichts tun.

[SeatSLF]

Momentan habe ich auf meinem Router die Beta von Salixer am laufen, mal schauen wie es läuft.
Ich kann leider nur an Wochenenden Wireshark mitlaufen lassen.