Probleme mit KNXnet/IP-Tunnel und Routeranbindung

[WagoKlemme]

+Wago
Meine Wago als Router hatte hin und wieder auch die SequenceCounter Fehler. Mit der MDT IP (neue Version) habe ich in jetzt 3 Monaten keinen einzigen Fehler mehr gesehen. Läuft sehr geschmeidig.
Der Umstieg auf MDT IP hatte aber nichts mit dem Fehler zu tun. Ich hätte damit leben können, ausser es wären viele Fehler geworden.

[coliflower]

Ich denk, dass sich viele nicht trauen sich zu Wort zu melden oder es ihnen egal ist oder sie warten was da heraus kommt ...

Wenn ich mich nicht irre, dann wurde folgende HW bis jetzt gemeldet:

GIRA
SIEMENS
ENERTEX
WAGO

[Simone]

passt schon soweit, das Wireshark Log hat den Dateinamen 14:07 und das Edomi Log hat auch Einträge 14:07 (siehe unten). Da ich in dieser Zeit aber umgesteckt habe und es Channel ID Einträge sind und nicht ACK müsste ich wohl noch mal loggen und auf diese zufälligen Fehler warten.

Aktuell würde ich es erstmal dabei belassen und warten was bei Enertex Routern als Ergebnis rauskommt

  / Raw: 061004200015044805002900bce011232416010080    ERROR 2016-08-05 14:07:48    782608    KNX    12854    ROUTER @ DE | TUNNELING_REQUEST / ErrMsg: ChannelId abweichend: Ist-Wert=72, Soll-Wert=73 / Raw: 061004200015044805002900bce011232416010080    ERROR 2016-08-05 14:07:49    786041    KNX    12854    ROUTER @ DE | TUNNELING_REQUEST / ErrMsg: ChannelId abweichend: Ist-Wert=72, Soll-Wert=73 / Raw: 061004200017044806002900bce011061c000300800cba    ERROR 2016-08-05 14:07:50    517761    KNX    12854    ROUTER @ CE | DISCONNECT_REQUEST / Raw: 06100209001048000801c0a801180e57    ERROR 2016-08-05 14:07:50    643572    KNX    12854    KNX-Verbindung verloren.    ERROR 2016-08-05 14:07:50    645241    KNX    12854    KNX-Verbindung verloren.    ERROR 2016-08-05 14:10:25    332844    KNX    12854    ROUTER @ DE | TUNNELING_REQUEST:L_Data.ind / Typ: Read / ErrMsg: Unbekannte GA / SeqCounter: 50 (50) / PA: 1.1.193 / GA: 2/1/192 / Raw: 061004200014044a32002900b06011c111c00080    ERROR 2016-08-05 15:08:51    007844    KNX    1378    EDOMI @ CE | CONNECTIONSTATE_REQUEST / Timeout nach 5s / ErrMsg: Kein CONNECTIONSTATE_RESPONSE vom Router erhalten    ERROR 2016-08-05 15:08:51    021325    KNX    1378    KNX-Verbindung verloren.    ERROR 2016-08-05 15:08:51    023206    KNX    1378    KNX-Verbindung verloren.    ERROR 2016-08-05 15:09:05    000654    KNX    1378    EDOMI @ CE | DESCRIPTION_REQUEST / Timeout nach 10s / ErrMsg: Kein DESCRIPTION_RESPONSE vom Router erhalten    ERROR 

[heckmannju]

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

Hi,

ich weiss ja nicht was und wielange da aufgezeichnet wurde.

passt den rein Zeitlich dein Trace zu dem log den du gepostet hast? Wenn ja dann lade ihn doch irgentwo hoch.
VG
Jürgen

[gaert]

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

Verstehe ich nicht wirklich - die KNX-Kommunikation (also TUNNEL_REQUESTS, ACK, etc.) läuft vollkommen unabhängig und mit Sicherheit schnell genug. Logik und Visu haben damit prinzipiell nichts zu tun (höchstens bezüglich der CPU-Last, aber die ist normalerweise <3-5%). Am Timing kann's grundsätzlich eher nicht liegen, schließlich funktioniert's ja mit anderen Schnittstellen. Damit z.B. ein ACK zu spät gesendet wird, müsste die Hardware schon 100% auf alles Cores ausgelastet sein - dies dürfte i.d.R. nicht der Fall sein.

[SeatSLF]

Ich sehe bei mir im Wireshark gar keine Kommunikation auf den eingestellten Ports, immer nur auf 3671 vom Router.
Von Edomi selber sehe ich gar nix

Scheinbar bin ich zu blöde wireshark zu bedienen...

Dafür stehen in den Packeten die GAs und Werte drin.

[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

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

[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

[Simone]

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

ws-filter.PNG

[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

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

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

[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

[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