GELÖST: EDOMI KNX-Ethernet-Interface/Gateway Probleme

[jdc]

Edit vom 2023-08-30:
Den folgenden im Original wiedergegebenen Post muss ich zum ggw. Zeitpunkt stark relativieren. Die typischen Verbindungsprobleme zwischen EDOMI und KNX Gateway sind auch bei mir aufgetreten und ich dachte zunächst eine Lösung zu haben. Nach mehrtägiger Analyse hat sich jedoch herausgestellt, dass ich nur einen Teilaspekt gelöst, bzw. beeinflusst habe.

Die mitlerweile einige Tage andauernde Analyse hat ergeben, dass die KNX Implementation von EDOMI leider nur unter quasi Laborbedingungen mit meiner Konstellation funktioniert, also insbesondere nur ohne Timingprobleme auf dem Hostrechner (z.B. durch andere Software/Prozesse die auch darauf laufen). Später wurde erkannt, dass UDP Paketverlust zwischen EDOMI und Gateway ebenso zu einer hängenden Verbindung führen kann, da ein Softwarebug vorliegt.
Beides ist unter realen Bedingungen jedoch kaum auszuschliessen und die meisten Benutzer dürften in variierendem Maße betroffen sein.
In diesem Thread wird versucht das Problem weiter zu analysieren, Tools zum Provozieren der Probleme zu finden (Stresstests) und einen Fix für die Protokollimplementierung zu finden.

-- Originaltext des Posts folgt --


Hallo Leute,

wie viele andere im Forum hatte ich bis gestern sporadische seltsame Verbindungsverluste zwischen EDOMI und KNX Gateway (in meinem Fall MDT).
Ich finde die Threads nicht mehr, jedoch erinnere ich mich noch dass viele Leute dieselben esoterischen Probleme hatten und ebenso esoterische Lösungen gehandelt wurden und diskutiert wurde, welche KNX Gateway Hersteller besser/schlechter sind.

Das Problem habe ich gestern gelöst, als es mir wie Schuppen von den Augen gefallen ist.
Es ist ein Ethernet Halbduplex-Vollduplex mismatch-Problem. Vor Jahren gabs das auch mal zwischen diversen Routern/Switches und LaFonera-FON WLAN Access Points und hatte mich auch damals schon Nerven gekostet das zu erdulden und letztlich zu diagnostizieren.

Hier schauen: https://en.wikipedia.org/wiki/Duplex_mismatch

! ------------------------------------------------------------------------------------------------------- !
! Lösung zusammengefasst: Port am Switch oder im Plasterouter auf "Halbduplex" umstellen. Problem gelöst. !
! ------------------------------------------------------------------------------------------------------- !

Schönen Tag noch,
-- Jens :-)

[jonofe]

Wie genau hast du diesen Mismatch diagnostiziert. Das würde ja bedeuten, dass das MDT KNX Gateway kein Auto-Negotiating kann, oder?

Ich habe die eibmarkt IP Schnittstelle und hier schreibt eibmarkt explizit, wenn der Router nicht erkannt wird, soll man den Switch manuell auf full-duplex stellen.

Bei manchen Switches kann es Probleme mit Standardeinstellungen geben und die IP Geräte werden nicht erkannt. Stellen Sie dann folgendes am Switch ein:

Full-Duplex-Mode
Übertragunsrate: 10 Megabit/s
Ein Leuchten der Ethernet LED am IP Router oder IP Interface signalisiert einen vorhandenen Link, d.h. dass auch die Übertragungsrate sowie der Modus richtig eingestellt sind.

Das passt auch zur Beschreibung von Duplex Mismatch auf der Wikipedia Seite:

When a device set to autonegotiation is connected to a device that is not using autonegotiation, the autonegotiation process fails. The autonegotiating end of the connection is still able to correctly detect the speed of the other end, but cannot correctly detect the duplex mode. For backward compatibility with Ethernet hubs, the standard requires the autonegotiating device to use half duplex in these conditions. Therefore, the autonegotiating end of the connection uses half duplex while the non-negotiating peer is locked at full duplex, and this is a duplex mismatch.

Wenn wir davon ausgehen, dass der Switch Auto-Negotiating kann und der KNX Router nicht, dann würde der Switch gemäß Standard auf half-duplex schalten, obwohl der KNX Router vermutlich auf full-duplex läuft. Das wäre genau der beschrieben Mismatch. Aber man müsste doch dann den Switch fest auf Full-Duplex stellen. Oder?

[jdc]

Hi Jonofe,

ich muss dazu sagen, dass der Port vorher am Switch manuell auf 100fdx, dazu Current-RX, Current-TX, "Configured" checked, Frame Size 1518, Collision Mode "discard", Power Control (port power saving) auf "enabled" konfiguriert war. Jetzt auf 100hdx, "collision mode" testweise auf "restart" geändert.
Ich bin kein Experte für den 802.3(u/z) PHY, nur Anwender, kann ich also nicht viel sagen wie die Autonegotiation funktioniert. Bei dem WLAN-AP damals gings jedenfalls schief. Ggf. erfahrenen (!) Netzadmin fragen.
Mir ist nur einfach klar geworden, dass die Unstabilitäten, Paketverlust und Verbindungsabbrüche, die teilweise nur durch Switch-Reboot zu beheben waren genau so waren wie damals. Vermutlich hätte ich ansonsten auch mal die Statistiken des Ports angeschaut. Die sind jetzt in 14h53min seit reboot jedenfalls 0 für RX und TX. Kollisionen/Duplexprobleme könnten sich bei "Rx Jabber", "Tx Late Collisions" und "Rx Undersize" bemerkbar machen. Jedenfalls sind jetzt keine Fehler mehr im EDOMI Errorlog zu finden.
Dasselbe Problem könnte übrigens so manche knxd-Installation betreffen. Keine Ahnung wie die einzelnen Treiber/OSe/KNX-Gateways mit der Autonegotiation umgehen und in welchen Fällen/Kombinationen diese funktioniert und wann nicht. Jedenfalls ist diese Einstellung _ein_ Knackpunkt. Daher die Empfehlung: Setting umstellen, prüfen ob Fehler weg wie bei mir.

Ich habe auch kein anderes Gateway als den MDT, daher kann ich nichts dazu sagen, aber die Fehlerbilder die ich im Forum gelesen habe von Anderen Benutzern stimmen überein, daher vermute ich dieselbe Ursache. Ansonsten funktioniert der MDT sehr gut bei mir mit EDOMI wie auch die anderen Geräte von denen.

Jens

[EinAnfaenger]

100fdx, dazu Current-RX, Current-TX, "Configured" checked, Frame Size 1518, Collision Mode "discard", Power Control (port power saving) auf "enabled" konfiguriert war. Jetzt auf 100hdx, "collision mode" testweise auf "restart" geändert.

Ich würde mal testweise "power saving" disablen. Hat bei mir in der Vergangenheit immer mal wieder Probleme gemacht (bei anderen Netzwerkgeräten). Bei mir (MDT-IP-Router) habe ich auch ab und an mal einen disconnect, aber der ist so selten das es mir egal ist bzw. das ich keinen Sinn sehe danach zu suchen, weil es eh nur ein Eintrag im Log ist und danach gleich wieder funktioniert.

[jdc]

Hallo EA,

ja, gute Idee, hab ich jetzt auch mal abgeschaltet, aber wie gesagt bei mir scheint es der Duplexmodus gewesen zu sein. Wenn noch was auftritt würde ich auch mal noch die Erdung genauer unter die Lupe nehmen aber das scheints jetzt gewesen zu sein.

--Jens

[NorbertB]

Es ist übrigens keine gute Idee die Speed-/Duplex Settings auf einer Seite festzunageln und auf der anderen Seite auf Autosense zu stellen.
Entweder beide Seiten Auto oder, wenns dabei Probleme gibt, beide Seiten identisch festnageln.

[jdc]

Zwischenreport: Immernoch keine neuen Fehler seit der Änderung auf Halbduplex und Powersafe-off.

Addendum: Dies hier könnte auch eine Rolle spielen:
https://en.wikipedia.org/wiki/Ethernet_flow_control

Pause frame


An overwhelmed network node can send a pause frame, which halts the transmission of the sender for a specified period of time. A media access control (MAC) frame (EtherType 0x8808) is used to carry the pause command, with the Control opcode set to 0x0001 (hexadecimal).^[1] Only stations configured for full-duplex operation may send PAUSE frames. When a station wishes to pause the other end of a link, it sends a pause frame to either the unique 48-bit destination address of this link or to the 48-bit reserved multicast address of 01-80-C2-00-00-01.^{[2]: Annex 31B.3.3} The use of a well-known address makes it unnecessary for a station to discover and store the address of the station at the other end of the link.

Another advantage of using this multicast address arises from the use of flow control between network switches. The particular multicast address used is selected from a range of address which have been reserved by the IEEE 802.1D standard which specifies the operation of switches used for bridging. Normally, a frame with a multicast destination sent to a switch will be forwarded out to all other ports of the switch. However, this range of multicast address is special and will not be forwarded by an 802.1D-compliant switch. Instead, frames sent to this range are understood to be frames meant to be acted upon only within the switch.

Ist hier besonders relevant wg. dem hohen Geschwindigkeitsübergang 100baseT -> KNX 9600bps.
Würde erklären, dass auf-halbduplex-setzen das Problem löst. Zum Beispiel könnte EDOMI/knxd beim Startup eine ganze Menge KNX-Frames (Gruppenaddressen-Abfragen oder gar -Writes) raushauen, dabei das Gateway bzw. den KNX Bus überlasten. Was das Gateway dann macht dürfte Herstellerabhängig sein, queuen oder verwerfen, evtl. auch so ein Pausen-frame schicken, falls nicht auf Halbduplex konfiguriert oder nicht mit Autonegotiation auf Halbduplex runtergeschaltet. Ob das funktioniert dürfte auch Herstellenabhängig sein, und wie der Switch reagiert, auch. Evtl. kommt die Situation auch häufiger vor, zu vollen Stunden/Minuten, wenn z.B. in der Logikengine viele KNX Telegramme zeitgleich getriggert werden.
Irgendwie sowas. Vermutlich würde ich dem doch noch zuerst nachgehen wenn das Problem bei mir noch bestehen würde bevor ich mich auf Suche nach Kriechströmen auf dem baseT-Shielding machen würde. So habe ich für beides leider nicht die Zeit. Ggf. füge ich meinem Tip also noch hinzu mit den FlowControl-Settings am Switch/Router für den jeweiligen Port zu spielen. Evtl. auch das Gateway direkt ohne Switch mit dem EDOMI-Rechner verbinden. Ich kann mich wage erinnern, dass zu dem Zeitpunkt ich auch keine KNX-Errors im EDOMI-log hatte (bei mir bge0: <Broadcom NetXtreme Gigabit Ethernet Controller>, EDOMI auf FreeBSD).

Hoffe das hilft hier jemandem weiter.
Bei der Gelegenheit noch mal vielen Dank ins Forum für all die fleissigen Leute, die mir geholfen haben mit ihren Threads meine Automatisierung in den Griff zu kriegen und das alles zu lernen! Ihr seid super! Und auch Danke an Christian für die tolle Software!

--jens

[jdc]

Hallo Norbert,

ja, korrekter Einwand!
Ist wohl eine Philosophische Frage, einige Netzwerk Admins bevorzugen die Eine (alles AutoNeg), Andere die andere Variante (alles Festnageln, mehr Arbeit). Kann mir aber vorstellen, dass viele KNX-Gateway-Hersteller da keine Einstellungsmöglicheit bieten, und einigen die Problematik ggf. gar nicht bewusst ist. Am Switch haste mehr Einfluss und ich könnte mir Vorstellen, dass das Ethernet-Verfahren den Switches die Möglichkeit bietet der anderen Station mitzuteilen, dass der Link jetzt definitiv halbduplex ist, so dass dem Gateway das Halbduplex praktisch aufgezwungen wird und somit obige Flow-Control Geschichte beeinflusst wird. Wie gesagt, ich bin kein Experte für 802.3 PHY, nur 802.11 PHY und da ist aufgrund des geteilten Mediums alles anders.

--jens

[sipiyou]

Moin,

interessanter Ansatz. Ich hab das Problem auch hin und wieder - nutze das Siemens N148/22, was allerdings nur mit 10M/FD hier im Automodus läuft.
Am Wochenende hab ich den Port, auf 10Mbit/HD umgestellt und auch FlowControl auf inaktiv gelassen.

Gestern abend hab ich wieder Fehler gehabt, lustigerweise, nachdem ich beim Fronius WR über die Cloud den Firmware update getriggert hab. Danach hab ich FC aktiviert, aber wie man das heute sieht, bringt 10M/HD+FC auch nichts.

Teste jetzt 100M/HD ohne FC aus, obwohl das Ding eigentlich nur mit 10M läuft.

2023-06-11 18:56:14	588083	KNX	711324	DE < | TUNNELING_REQUEST / Hinweis: SequenceCounter abweichend (ACK): Ist-Wert=229, Soll-Wert=230 / Raw: 0610042000170446e5002900bce0116502060300805400 / letzter request: / letzer response: 0610042000170446e5002900bce0116502060300805400	ERROR
2023-06-12 11:49:19	075404	KNX	711324	DE < | TUNNELING_REQUEST / Hinweis: SequenceCounter abweichend (noACK): Ist-Wert=236, Soll-Wert=235 / Raw: 0610042000170446ec002900bcd01201420103008015e4 / letzter request: / letzer response: 0610042000150446ea002e00bce08fff0604010080	ERROR
2023-06-12 11:49:19	086205	KNX	711324	KNX-Verbindung verloren.

/edit: auf 100M geht nix bei dem Ding. Fazit: In Verbindung mit dem Siemens N148 ist das Problem durch diesen workaround nicht gelöst.

[jdc]

Mahlzeit,

ich denke die Problematik tritt immer dann auf, wenn der Bus überlastet ist, d.h. die 9600 bps Bandbreite auf dem Bus erschöpft sind. Das kann mehrere Ursachen haben, z.B. Programmierung eines KNX Geräts, Softwareupdate über den Bus oder wenn aus irgend einem Grund (z.B. volle Stunde, Mitternacht oder Startup) viele Geräte gleichzeitig viele Telegramme auf dem Bus absetzen. Oder EDOMI beim Start falls GAs abgefragt werden oder default-init Werte versandt werden. Schon möglich dass bei Dir hier dein WR-Update irgendwie die Ursache war, evtl. hat das Ding ja viele Telegramme auf den Bus gesandt nachdem er mit dem Update fertig war oder EDOMI hat danach eine Abfragewelle gestartet.
Was genau nach einem Bus Overload passiert und welche Art von Fehler auftritt scheint u.a. vom Gateway und der Ethernet-PHY Einstellung abzuhängen. Bei mir ist die Stabilität sehr gestiegen seit der Umstellung, heute nacht um 3 gings dann aber wieder in einer anderen Variante los, ein Glastaster hat freigedreht und in einer Endlosschleife den Bus zugemüllt mit "SOLL Temperaturverschiebung" Telegrammen in Endlosschleife. Die konnte ich im EDOMI Busmonitor sehen, ca 10 Stück pro Sekunde. EDOMI wollte offenbar selber senden, kam aber durch den voll ausgelasteten Bus nicht dazu.
Ich hab den Glastaster abgeklemmt und es war Ruhe auf dem Bus alles andere ging wieder aber EDOMI hat nicht recovered (ging seit dem Zeitpunkt um 03:00 Uhr als das angefangen hat überhaupt nichts mehr, alle zu sendenen Telegramme gequeued), musste ich wieder neustarten.

Log:

2023-06-13 03:09:44	486495	KNX	48071	DE > | TUNNELING_ACK / Timeout nach 1s / ErrMsg: Kein TUNNELING_ACK vom Router erhalten / Wiederholen	ERROR
2023-06-13 03:09:52	534466	KNX	48071	DE > | TUNNELING_ACK / Timeout nach 1s / ErrMsg: Kein TUNNELING_ACK vom Router erhalten / Wiederholen	ERROR
2023-06-13 03:09:53	658226	KNX	48071	DE > | TUNNELING_ACK / Timeout nach 1s / ErrMsg: Kein TUNNELING_ACK vom Router erhalten / Verwerfen	ERROR
2023-06-13 03:09:54	983201	KNX	48071	DE > | TUNNELING_ACK / Timeout nach 1s / ErrMsg: Kein TUNNELING_ACK vom Router erhalten / Wiederholen	ERROR

[...]

2023-06-13 08:23:15	425112	KNX	48071	DE > | TUNNELING_ACK / Timeout nach 1s / ErrMsg: Kein TUNNELING_ACK vom Router erhalten / Wiederholen	ERROR
2023-06-13 08:23:16	595916	KNX	48071	DE > | TUNNELING_ACK / Timeout nach 1s / ErrMsg: Kein TUNNELING_ACK vom Router erhalten / Verwerfen	ERROR
2023-06-13 08:23:17	749964	KNX	48071	DE > | TUNNELING_ACK / Timeout nach 1s / ErrMsg: Kein TUNNELING_ACK vom Router erhalten / Wiederholen	ERROR
2023-06-13 08:23:18	903970	KNX	48071	DE > | TUNNELING_ACK / Timeout nach 1s / ErrMsg: Kein TUNNELING_ACK vom Router erhalten / Verwerfen	ERROR
2023-06-13 08:23:20	043661	KNX	48071	DE > | TUNNELING_ACK / Timeout nach 1s / ErrMsg: Kein TUNNELING_ACK vom Router erhalten / Wiederholen	ERROR

Insgesamt 16000 Fehler oder so im Log.
Irgendwie noch nicht wirklich befriedigend aber die kurzzeitigen Ausfälle zwischendurch sind definitiv weg seit der Umstellung. Mal sehen ob/wie ich das noch hinbekomme. Ich bleibe dran und reporte meine Erkenntnisse.

[sipiyou]

Ich muss mal den Beitrag nochmal hochholen. Ist es bei denjenigen, bei denen die Fehler auftreten auch so, dass die Anzahl der KNX-Connections nach oben schwappt ?

Solange Edomi keine Verbindungs-Fehler hat - sprich: nach dem Neustart - ist die Anzahl der KNX-Connections bei mir 1.

Das Problem ist bei mir besser geworden, nachdem ich die global_knxWait auf 5ms gesetzt habe (default waren 10).

[jdc]

Hallo sipiyou,

seit dem Ändern des Duplexsettings ist es bei mir um 90% besser geworden mit den nicht-automatisch-recovernden Verbindungsproblemen, aber diese sind leider noch nicht ganz weg. Die treten stattdessen hauptsächlich dann auf, wenn ich EDOMI und KNX Bus längere Zeit sich selber überlasse, also als wir in den Sommerferien unterwegs waren. Sonst mache ich öfter mal eine kleine Logik- oder Visu-Änderung hier und da mit Neustart, was das Problem zu preventieren scheint.
Ausserdem bestätigt sich noch langsam die Vermutung dass es was mit der Erdung des Switches bzw. der Ethernet-Installation zu tun hat. Das ist aufgrund baulicher Verhältnisse bei uns noch nicht ganz sauber (Altbau) und steht auf der TODO-Liste. Zweimal musste ich schon den ganzen Ethernet-Switch warmstarten da weder EDOMI-Neustart noch KNX-Bus Kaltstart das Problem lösten.
Welche Zähler in der EDOMI-Statistik im Fehlerfall hochzählen werde ich das nächste Mal dokumentieren und hier einstellen, kann aber zwei, drei Wochen dauern bis das wieder auftritt.

--Jens

[sipiyou]

Ich hab 3 verschiedene Fehler, die Duplex-Einstellung usw. ändern nichts am Problem, es scheint eher so zu sein, dass durch die Sleep-Time in Edomi Pakete flöten gehen. Verbaut ist ein Siemens KNX-IP Gateway.

Bei A geht die Verbindung nicht verloren.

A)
DE < | TUNNELING_REQUEST / Hinweis: SequenceCounter abweichend (ACK): Ist-Wert=86, Soll-Wert=87 / Raw: 061004200017044456002900bce0116502060300803ef4

B)

CE > | CONNECTIONSTATE_REQUEST / Timeout nach 5s / ErrMsg: Kein CONNECTIONSTATE_RESPONSE vom Router erhalten
KNX-Verbindung verloren.

C)
DE < | TUNNELING_REQUEST / Hinweis: SequenceCounter abweichend (noACK): Ist-Wert=23, Soll-Wert=22 / Raw: 061004200015044117002900bce011350104010080
KNX-Verbindung verloren.

Aber mir geht es erstmal dadrum, ob die Verbindungszahl hoch geht, wenn die Verbindung verloren geht.
Denn soweit ich das sehe, sollte Edomi nur 1 Verbindung halten und nicht mehere.

[Albert]

Hallo

Im Fall

2023-08-19 03:00:14

468185

KNX

25708

DE < | TUNNELING_REQUEST / Hinweis: SequenceCounter abweichend (ACK): Ist-Wert=54, Soll-Wert=55 / Raw: 061004200015044036002900bce011652810010080

ERROR

geht die Verbindungszahl nicht hoch - Verbindungen = 1

[sipiyou]

Ja, bei Fall A geht es nicht hoch. Nur bei Fall B+C geht der Zähler hoch, d.h. nur wenn Edomi die Verbindung verliert.