Korrekte Konfiguration eines IP Routers in ETS5

[Pirx]

Das Upgrade der Firmware-Version im Enertex KNX/IP-Router hat leider nichts gebracht. Mittlerweile habe ich festgestellt, dass der Fehler immer nach dem Neustart von OH3 passiert. Nach ein Paar Minuten schickt das KNX-Binding vom OH3 requests an den IP-Router. Die Antworten versteht Calimero anscheinend nicht und es kommt zum regelrechten Bombardement. Nach ein paar Stunden hört das ganze von alleine auf und alles funktioniert einwandfrei.
Ich gehe davon aus, dass entweder der KNX-Router Unfug sendet, oder Calimero einen Bug hat. Wie nähere ich mich dem Problem?

[Pirx]

Da kann es sein, dass der IGMP Probleme hat. Früher mal hatten die alten Speedports die IGMP Pakete zurückgespiegelt und dann den Router solange in den Datenwahn versetzt, bis das Routing Busy kam. Das ist aber schon einige Jahre her. Such mal nach irgendwelchen IGMP Einstellungen oder Multicasts...

Danke für den Hinweis, aber ich habe keine IGMP oder Multicast-EInstellungen im Speedport Pro gefunden. Ich habe etwas gegoogelt und sehr alte Meldungen über das von dir beschriebene Phänomen gefunden. Ich denke jedoch nicht, dass es auf meinen Fall zutrifft.

[enertegus]

Ich bin leider kein IP-Fachman, daher die Frage: Kann es auch etwas mit meinem neuen LAN-Router (Speedport Pro Plus) zu tun haben?

Da kann es sein, dass der IGMP Probleme hat. Früher mal hatten die alten Speedports die IGMP Pakete zurückgespiegelt und dann den Router solange in den Datenwahn versetzt, bis das Routing Busy kam. Das ist aber schon einige Jahre her. Such mal nach irgendwelchen IGMP Einstellungen oder Multicasts...

[Pirx]

Ich habe vorhin entdeckt, dass es für meinen KNX/IP Router eine neue Firmware-Version gibt mit 'Router: Stability improvements'.... Ich habe nun von v1.039 auf v1.043 upgegrated.
Im Moment habe ich keine Fehlermeldungen. Warten wir es ab. Die Hoffnung stirb zuletzt....

Enertex KNXnet/IP Router - Firmware - Changelog
--------------------

* v1.043
- Router: Stability improvements

* v1.042
- Router: Adding Locking of application programming
Inhibits re-programming of an router via TP

* v1.041
- A line scan bug (introduced in 1.040) fixed

* v1.040
- Line scan behaviour changed
- Increased tunnel output buffer size

[Pirx]

Aber "Routing Busy"-Frames klingt nicht gut. Die schickt ein IP-Router, wenn von der IP-Seite so viele Telegramme reinkommen, dass es keine Chance mehr hat, die auf die TP-Seite weiterzuleiten. Normalerweise sollte der Sender daraufhin langsamer tun, aber Calimero versteht die Frames offenbar nicht (die Fehlermeldung "wrong size for routing busy indication: 0x4" ist Unsinn, 4 ist genau richtig).

Danke für die Erklärung. Nun ist die Frage woher die Anfragen kommen (ausser von OH)? Mein KNX/OH-Binding war und ist auf Standard-Werte gesetzt (bis auf autoReconnectPeriod):

Bridge knx:ip:bridge "KNX IP Interface"
[type="ROUTER",
readingPause=50,
responseTimeout=10,
readRetriesLimit=3,
autoReconnectPeriod=60   // Standard = 0
]

Ich bin leider kein IP-Fachman, daher die Frage: Kann es auch etwas mit meinem neuen LAN-Router (Speedport Pro Plus) zu tun haben?

[Klaus Gütter]

Aber "Routing Busy"-Frames klingt nicht gut. Die schickt ein IP-Router, wenn von der IP-Seite so viele Telegramme reinkommen, dass es keine Chance mehr hat, die auf die TP-Seite weiterzuleiten. Normalerweise sollte der Sender daraufhin langsamer tun, aber Calimero versteht die Frames offenbar nicht (die Fehlermeldung "wrong size for routing busy indication: 0x4" ist Unsinn, 4 ist genau richtig).

[gbglace]

Mit dem IP-Kram kenne ich mich nicht so aus.

Gibt hier ja auch ein OH Subforum. Da mal das hier hin verlinken, da sind bestimmt einige unterwegs die sich da besser mit auskennen.

[Pirx]

Aber es ist Murks besonderer Art.

Ich habe die Topologie bereinigt, d.h. es gibt bei mir nur noch eine Linie. Des Weiteren habe ich mein OH und das KNX-Binding auf die aktuelle Version gebracht. Ich habe auch Easy-KNX ausprobiert....
Das interessante ist, dass der Fehler den ich hatte nicht konstant ist, sondern manchmal auftritt (für mehrere Stunden) und dann wieder verschwindet. Man sieht dann im openhab.log tausende dieser Fehlermeldungen:

2021-08-31 14:04:21.911 [WARN ] [p.KNXnet/IP Routing 224.0.23.12:3671] - received invalid frame
tuwien.auto.calimero.KNXFormatException: wrong size for routing busy indication: 0x4
at tuwien.auto.calimero.knxnetip.servicetype.RoutingB usy.<init>(RoutingBusy.java:83) ~[bundleFile:?]
at tuwien.auto.calimero.knxnetip.KNXnetIPRouting.hand leServiceType(KNXnetIPRouting.java:369) ~[bundleFile:?]
at tuwien.auto.calimero.knxnetip.ReceiverLoop.onRecei ve(ReceiverLoop.java:87) [bundleFile:?]
at tuwien.auto.calimero.internal.UdpSocketLooper.loop (UdpSocketLooper.java:134) [bundleFile:?]
at tuwien.auto.calimero.knxnetip.ReceiverLoop.run(Rec eiverLoop.java:69) [bundleFile:?]
at java.lang.Thread.run(Thread.java:829) [?:?]

2021-08-31 14:04:21.912 [WARN ] [p.KNXnet/IP Routing 224.0.23.12:3671] - received invalid frame
tuwien.auto.calimero.KNXFormatException: wrong size for routing busy indication: 0x4
at tuwien.auto.calimero.knxnetip.servicetype.RoutingB usy.<init>(RoutingBusy.java:83) ~[bundleFile:?]
at tuwien.auto.calimero.knxnetip.KNXnetIPRouting.hand leServiceType(KNXnetIPRouting.java:369) ~[bundleFile:?]
at tuwien.auto.calimero.knxnetip.ReceiverLoop.onRecei ve(ReceiverLoop.java:87) [bundleFile:?]
at tuwien.auto.calimero.internal.UdpSocketLooper.loop (UdpSocketLooper.java:134) [bundleFile:?]
at tuwien.auto.calimero.knxnetip.ReceiverLoop.run(Rec eiverLoop.java:69) [bundleFile:?]
at java.lang.Thread.run(Thread.java:829) [?:?]

2021-08-31 14:04:21.913 [WARN ] [p.KNXnet/IP Routing 224.0.23.12:3671] - received invalid frame
tuwien.auto.calimero.KNXFormatException: wrong size for routing busy indication: 0x4
at tuwien.auto.calimero.knxnetip.servicetype.RoutingB usy.<init>(RoutingBusy.java:83) ~[bundleFile:?]
at tuwien.auto.calimero.knxnetip.KNXnetIPRouting.hand leServiceType(KNXnetIPRouting.java:369) ~[bundleFile:?]
at tuwien.auto.calimero.knxnetip.ReceiverLoop.onRecei ve(ReceiverLoop.java:87) [bundleFile:?]
at tuwien.auto.calimero.internal.UdpSocketLooper.loop (UdpSocketLooper.java:134) [bundleFile:?]
at tuwien.auto.calimero.knxnetip.ReceiverLoop.run(Rec eiverLoop.java:69) [bundleFile:?]
at java.lang.Thread.run(Thread.java:829) [?:?]

Vorgestern hörten nachts um 03:17 diese Meldungen auf und ich habe keine Ahnung warum. Danach funktionierte alles perfekt, sowohl auf der KNX-Seite, als auch auf der Openhab-Seite. Ich werde auch in der OH-Community nachfragen, aber habt ihr eine Idee ?

[vento66]

Daher einfach machen lassen. Die Leute die eh alles besser wissen brauchen doch eigentlich keine Hilfe.

[gbglace]

Aber es ist Murks besonderer Art.

[Pirx]

@Florian,

Deine 3 Linien scheinen topologisch falsch zu sein. wenn der Router 1.1.0 ist kann es keine Verbindung zur Linie 1.2 und 1.3.
Ich vermute, dass du gar keine Linienkoppler hast und die Linien einfach verbunden sind.
Gruß Florian

Du hast zwar grundsätzlich recht, aber es ist kein Grund dafür, warum ich von OH keine Verbindung kriege.

[gbglace]

Die Verbindungseinstellung auch der einen Linie nimm raus aus den Linieneigenschaften. Es genügt die Einstellungen im ETS Basismenü. Die Linienspezifischen macht man bei großen Anlagen wo ggf auch noch komplexe LAN Strukturen hinzukommen.

Eine saubere TP-Topologie hilft natürlich auch immer.

Wenn die ETS funktioniert, kannst ja mal noch ne simple Handy-App für KNX probieren, EASY-KNX ist da gut. Da kannst glaube auch zwischen Tunnelverbindung und Routing wechseln. Beginne mit Tunnel. Wenn Routing nicht funktioniert, dann liegt das OH Problem am neuen Router im LAN. Da gibt es hier ja auch diverse Beiträge welche 4-Buchstaben-Kürzel-Funktion/Protokoll aktiviert werden müssen das das wieder läuft. Gerade bei Nutzung via WLAN. Aber da bin ich raus, das LAN Gedöns können andere besser.

[Beleuchtfix]

Deine 3 Linien scheinen topologisch falsch zu sein. wenn der Router 1.1.0 ist kann es keine Verbindung zur Linie 1.2 und 1.3.
Ich vermute, dass du gar keine Linienkoppler hast und die Linien einfach verbunden sind.
Gruß Florian

[Pirx]

@gbglace, danke für die Rückmeldung.

Die da wären?

. ... Ich musste die alte Fritzbox gegen Speedport Pro Plus tauschen, da ich nun eine Hybride Internet-Anbindung habe (VDSL+LTE). Ich musste daraufhin einige TCP-Geräte von DHCP auf statische IP-Adressen umstellen, u.a. auch bei dem KNX IP-Router. Der funktionierte zwar vorher, aber er war nicht perfekt konfiguriert. Ich habe daher ihn resetet und baue von neuem auf.

Passen die Einstellungem im Router noch, Enertex hat doch auch so eine Telnet-Verbindungsoption zur Einstellung von Parametern, also nicht über die ETs zu konfigurieren.

Guter Tipp!! Ich habe dort auch schon den ersten Fehler gefunden.
So sieht derzeit die Konfig aus:

#ifconfig
IP............: 192.168.178.17
Subnet mask...: 255.255.255.0
Gateway.......: 192.168.178.1
NTP server....: 192.168.178.1
Sys multicast.: 224.0.23.12
RT multicast..: 224.0.23.12
Hardware addr.: 00:50:c2:79:37:f0

# tpconfig
KNX bus state.: up
KNX address...: 01.01.000
Serial number.: 00-a6-01-00-04-8e

# lcconfig

Coupler type.: line coupler

IP -> KNX:
GA 0-13......: route
GA 14-15......: route
Ph. add.......: filter
Broadcast.....: route

KNX -> IP:
GA 0-13......: route
GA 14-15......: route
Ph. add.......: filter
Broadcast.....: route
PW fail. mon..: enabled

# tunaddr

1: KNX address: 01.01.060
2: KNX address: 01.01.061
3: KNX address: 01.01.062
4: KNX address: 01.01.063
5: KNX address: 01.01.064

# stats

uptime: 4:40
KNX communication statistics:
TX to IP (all): 1883 (ca. 6 t/m)
TX to KNX: 1535 (ca. 5 t/m)
RX from KNX: 1537 (ca. 5 t/m)
Overflow to IP: 2
Overflow to KNX: 0
TX tunnel re-req: 2

Ich werde die Tunneladressen heute Abend ans Ende packen.

Gibt es Linien spezifische Einstellungen zur Schnittstelle im Projekt?

Grundsätzlich: Ich habe in der Topo nur einen Bereich (IP) und drei TP-Linien. In der ersten Linie hängt der IP-Router. Diese Linie hat in der Verbindungseinstellung den Enertex-Router. Die anderen beiden Linien haben keine Verbindungseinstellungen.
Mittlerweile kann ich alle KNX-Geräte (in allen drei Linien) über ETS5 wieder programmieren. Der erste Erfolg ist also da.
Nur von OpenHAB kriege ich keine Verbindung.....

[gbglace]

aber nachdem ich einige Veränderungen vornahm,

Die da wären?

Gibt es Linien spezifische Einstellungen zur Schnittstelle im Projekt? Das aktualisiert sich nicht wenn Du in der ETS in den allgemeinen Schnittstellenkonfigurationen Änderungen machst HW austauschst usw.

Passen die Einstellungem im Router noch, Enertex hat doch auch so eine Telnet-Verbindungsoption zur Einstellung von Parametern, also nicht über die ETs zu konfigurieren.

Als "Physikalische Adresse" habe ich 1.1.60 eingegeben (eine freie Adresse in der Linie).

Ist die auch als Tunneladresse dem Router zugewiesen und Programmiert?
Ich würde Tunneladressen immer eher ans Ende der Linie packen, je nach dem wieviele Tunneladressen der Router kann. So mitten aus der Topologie führt das nur zu Verwirrungen.