Probleme mit KNXnet/IP-Tunnel und Routeranbindung

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

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

[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

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

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

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

[heckmannju]

Hi,

Dann müste in dem Fall doch dieser Fall ziehen
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.

und Edomi via UDP ein Packet zum Router schicken diese sollten doch in dem Trace zu finden sein.

Vielleicht mal auf
ip.addr == 192.168.1.24
filtern.

Viele Grüsse
Jürgen

[Simone]

also filter geht nicht auf ip, aber sortieren wenn du das meinst. Von den Einträgen gibts ein Haufen

Source 24
24.PNG

Destination 24
24-2.PNG
wenn Rot bei Wireshark auch böse ist, gibts noch das (sortiert nach Length, ip 12 ist die edomi vm)

12.PNG

12-2.PNG

[SeatSLF]

Hi,

Dann müste in dem Fall doch dieser Fall ziehen
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.

und Edomi via UDP ein Packet zum Router schicken diese sollten doch in dem Trace zu finden sein.

Vielleicht mal auf
ip.addr == 192.168.1.24
filtern.

Viele Grüsse
Jürgen

dann wäre das +1 richtig, wenn ich meine Fehler habe dann ist es immer der seq. Counter -1.
Bis er sich wieder gefangen hat.

[gaert]

Die Implementierung ist korrekt - ich habe oben bei EDIT2 die Variablen verwechselt (ist schon ne Weile her). Es sollte also ein ACK gesendet werden, wenn der SeqCounter um 1 verringert ist (vom Router).

Mich irritiert eher diese Aussage um ehrlich zu sein:

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

Schließlich nutzt EDOMI ausschließlich Tunneling...

[heckmannju]

also filter geht nicht auf ip, aber sortieren wenn du das meinst. Von den Einträgen gibts ein Haufen

Sortieren ist glaube ich nicht so gut da es ja auch um die Reihenfolge geht. Filtern sollte eigentlich so gehen. Siehe Bild
Capture.PNG

[Simone]

Hat geklappt, das hattest du oben schon so vorgeschlagen, sorry

ws-filter.PNG

[heckmannju]

@Simone:
Sieht man jetzt nur eine Teil oder ist das schon alles?

@Geart:
Ist das überhaupt die gleiche codstelle die du gezeigt hast?

in deinem Code Auszug steht
trace(true,'ROUTER @ DE | TUNNELING_REQUEST / Hinweis: SequenceCounter abweichend (ACK): Ist-Wert='.$receiveRtg.', Soll-Wert='.$dE_seqCounterReceive.' / Raw: '.bytesToHex($response));

aber in dem edomi log von Simone steht was von ChannelID.

VG
Jürgen

[enertegus]

Mich irritiert eher diese Aussage um ehrlich zu sein:

Ich hab Dir eine PN geschickt. An dieser Stelle nur so viel:
Mögliches Szenario: Initialisierung => Logik/Visu braucht GA Werte => read Schnittstelle => Antwort des Buses => zurück an Logik. Wenn da die Schnittstelle schnell die Telegramm auf den Bus bekommt, kommt es zur Last auf der IP Seite durch die Antworten. Sicher nicht viel, aber vielleicht muss die Logik pro Telegramm eine Grafik laden, was auf den Webserver schreiben, etc. Auf einem Rechner ist m.E. eine Sekunde schon mal drin, v.a. in der VM kommt es schon im Normalfall zu Latenzen, sodass die Antwort vielleicht schon nach 500ms raus muss...

[Simone]

heckmannju was meinst du mit ist das schon alles? Auf dem Screenshot ist der erste Eintrag markiert, da kommt noch alles mögliche. Ich weiß aber nicht was genau interessant ist um zu analysieren.

Ich habe mir in Edomi nochmal die Logs bzgl. ChannelID angeschaut, ich dachte immer SequenceCounter abweichend ist immer das gleiche aber das sind unterschiedliche, die von 14:07 sind die mit der Channel ID (das war nach meiner Umsteckaktion auf Fritzbox Ports, ob die überhaupt für eine Analyse geeignet sind ist die Frage)

Hier eine Meldung, die sollte zum Code von Christian passen, wenn ich das richtig verstehe. Soweit ich mich erinnern kann, ist diese Meldung nach meiner ganzen Umsteckaktion davon habe ich kein Wireshark Log

 [TABLE="border: 0, cellpadding: 0, cellspacing: 0"]
 	 		[TR]
 			[TD]2016-08-05 15:46:32[/TD]
 			[TD]787412[/TD]
 			[TD]KNX[/TD]
 			[TD]1378[/TD]
 			[TD]ROUTER @ DE | TUNNELING_REQUEST / Hinweis: SequenceCounter abweichend (ACK): Ist-Wert=156, Soll-Wert=157 / Raw: 06100420001704429c002900bce0111f0c060300800caa[/TD]
 			[TD]ERROR[/TD]
 		[/TR]
 	 [/TABLE]

Vielleicht warten wir einfach bis jemand von den Leuten mit den Enertex Routern ein Wireshark Log hat, was dann vielleicht Enertex auswerten kann