Probleme mit KNXnet/IP-Tunnel und Routeranbindung

[eriche]

Da ich unzählige Fehlermeldungen erhielt (ich habe auch einen Enertex Router)

TUNNELING_REQUEST / Hinweis: SequenceCounter abweichend

habe ich jetzt eibd dazwischen laufen.
Die Software scheint eine gescheite Queue oder ein durchdachtes Buffering zu haben.
Seit dem erhielt ich nie wieder eine Meldung, dass bei der Sequenz der Ist- vom Sollwert abweicht.

[enertegus]

Danke für den Hinweis
Angemerkt sei, dass sich :

Die maximale Telegrammrate des Enertex IP-Routers ist 36 Telegramme/ Sekunde

auf die Tunnelverbindung bezieht. Beim Routing ist das 50 (=49,79..)/s

[ak68]

Nach Rücksprache mit Enertex ist zumindest MEIN "TUNNELING_REQUEST/ DISCONNECT_REQUEST-Problem" gelöst:

Es war NICHT die weiter oben beschriebene Linux-Firewall-Einstellung

Die maximale Telegrammrate des Enertex IP-Routers ist 36 Telegramme/ Sekunde.
Steht diese Einstellung (Basiseinstellungen/ KNX-Gateway/global_knxMaxSendRate) auf dem von Gaert empfohlenen Standard von 20,
werden inclusive Antworten je nach Initialisierung bereits bis zu 40 Telegramme/ Sekunde gesendet !
-> Daher sollte die Einstellung 12 T/d betragen (= max. 24 T/s + Reserve)

Eine weitere "Stellschraube" ist die Basis-Einstellung: Initscan: Anzahl der Überprüfungen pro Abfrage (global_InitScanTryCheck):
-> Bei mir funktioniert "20" jetzt problemlos

Ich hoffe, ich konnte hiermit auch Anderen hier im Forum helfen
Andreas


Basiseinstellungen.png

[ak68]

Ja, entweder iptables deaktivieren, dann ist es so wie vorher. Oder iptables CFG entsprechend anpassen und weiter aktiviert lassen.
Fuer die Nutzung daheim taet ich ersteres vorschlagen.

Ich gehe davon aus, dass ich ebenso genau diese Problem habe;

Nach der Umstellung von ETS 4 auf ETS 5 musste ich auch die KNX-(Tunnel)-Adressen meines Enertex IP-Routers von 15.15.1 auf 1.1.240(-245) ändern, da bei der ETS5 offensichtlich erkannt wird, dass die Adresse in einem anderen Adressbereich liegt.
Davor war nur 1 Tunnel-(15.15.1) Verbindung freigegeben, jetzt habe ich per Telnet 5 Tunnel-Verbindungen freigegeben (Default: 240-245).

Die Folge ist jetzt, dass immer beim Neustart folgende Fehlermeldungen erscheinen:

2017-05-13 08:55:48	816167	KNX	22704	ROUTER @ DE | TUNNELING_REQUEST / ErrMsg: Unbekannter Fehler / Raw: 061004200015046138002900bce011041d050100fe	ERROR
2017-05-13 08:55:49	784709	KNX	22704	ROUTER @ DE | TUNNELING_REQUEST / ErrMsg: Unbekannter Fehler / Raw: 061004200015046138002900bce011041d050100fe	ERROR
2017-05-13 08:55:50	379652	KNX	22704	ROUTER @ CE | DISCONNECT_REQUEST / Raw: 061002090010616108010a0a01210e57	ERROR
2017-05-13 08:55:50	390321	KNX	22704	KNX-Verbindung verloren.

Deaktivierung der Firewall mit folgenden Befehlen:

Type the following two commands (you must login as the root user):
# /etc/init.d/iptables save
# /etc/init.d/iptables stop

Turn off firewall on boot:
# chkconfig iptables off


Ergänzung: nach Deaktivierung der iptabels ist das Problem NICHT behoben:

2017-05-13 14:49:52	032613	KNX	17220	ROUTER @ DE | TUNNELING_REQUEST / ErrMsg: Unbekannter Fehler / Raw: 0610042000150481de002900bce011041d050100e0	ERROR
2017-05-13 14:49:52	982707	KNX	17220	ROUTER @ DE | TUNNELING_REQUEST / ErrMsg: Unbekannter Fehler / Raw: 0610042000150481de002900bce011041d050100e0	ERROR
2017-05-13 14:49:53	588741	KNX	17220	ROUTER @ CE | DISCONNECT_REQUEST / Raw: 061002090010818108010a0a01210e57	ERROR
2017-05-13 14:49:53	600325	KNX	17220	KNX-Verbindung verloren.

[wintermute]

Ja, entweder iptables deaktivieren, dann ist es so wie vorher. Oder iptables CFG entsprechend anpassen und weiter aktiviert lassen.
Fuer die Nutzung daheim taet ich ersteres vorschlagen.

[SeatSLF]

ja

[benji]

Merkt man u.A. daran, dass zwar SSH noch erreichbar ist, HTTP aber nicht mehr...

ich bin gerade Alexa Custom Still am testen und habe auf dem Edomi yum installiert laut Anleitung. Anschließend hatte ich kein zugriff mehr über http, allerdings über ssh. Wird wohl dann daran liegen oder??? Einfach Firewall deaktivieren und dann läuft wieder????

[Aktor]

Danke. Ich glaube das war bei mir die Ursache. Ich hatte Grafikprobleme und hatte mir dann versucht mit meinen mangelnden Linux-Kenntnissen Pakete dazu zuladen

[wintermute]

Ich glaube wenn man "zufällig" mal ein "yum update" gemacht hat, dann ist die Firewall aktiv, wenn ich mich da recht erinnere.

Korrekt
Merkt man u.A. daran, dass zwar SSH noch erreichbar ist, HTTP aber nicht mehr...

[jonofe]

Ich glaube wenn man "zufällig" mal ein "yum update" gemacht hat, dann ist die Firewall aktiv, wenn ich mich da recht erinnere.

[gaert]

Richtig - ab Werk ist die Firewall (iptables) deaktiviert.

[Andreas1]

Hi,

ich habe centos nach Anleitung installiert, keine Updates gemacht und Edomi installiert:

[root@edomi ~]# service iptables status
iptables: Firewall läuft nicht.

[Aktor]

TUNNELING_REQUEST
----------------------------------------

Nachdem ich alles mögliche geprüft hatte (KNX-seitig, Netzwerkleitungen, Switch, Firmeware beim IP Interface) habe ich über Wireshark die Netzwerkaktivitäten geprüft und ab und zu bei einem ICMP-Protokoll folgende Fehlermeldung erhalten: Destination unreachable (Host administratively prohibited)

Daraufhin habe ich einfach mal über "service iptables stop" die iptables deaktiviert und seit dem läuft es ohne Probleme.

Nach der Edomi Installationsanleitung sollte die Firewall des Betriebssystems standardmäßig ja nicht aktiviert sein. Entweder hat das nichts mit den iptables zu tun oder ich hatte es geschafft hier irgendwas zu aktivieren.

Jetzt habe ich die Frage an die Linux-Experten hier: Habt Ihr die iptables aktiviert und wenn ja in welcher Konfiguration? Für die entsprechenden Befehle wie ich da hinkomme wäre ich dankbar.

[SeatSLF]

Schau mal übernTelnet drauf, da siehst du die Tunnelbelegung.

Ist die neuste Firmware installiert?

Bei funktioniert der Enertex absolut perfekt.

[eriche]

Generell eine Frage zu den Tunnel.
Ich habe einen Enertex Router, wobei auch hier täglich TUNNELING_REQUEST Errors im Edomi autreten.

Kann ich nun einen Tunnel fix Edomi zuordnen und einen anderen der ETS?
Ich dachte (hoffte) immer, dass der Router so gescheit ist und selbstständig einen neuen Tunnel aufmacht, wenn bereits einer belegt ist