Probleme mit KNXnet/IP-Tunnel und Routeranbindung

[MarkusS]

Ich bin mir nicht sicher ob der Handshake bei / wegen der PA in die Binsen geht. Theoretisch könnte das auch noch wegen den Ports sein.

Ich bin schon die ganze Zeit am Grübeln was ich alternativ Edomi nehmen könnte was den Tunnel sauber aufbaut - außer der ETS, da habe ich aber noch die 4er im Einsatz und die verhält sich bez. KNXnet/IP-technisch anders als die 5er wo der Falcon komplett neu geschrieben wurde. Ich würde da ungern Edomi mit Edomi vergleichen wegen dem Einäugigen der der König der Blinden ist ... - Referenz muss immer was sein was bekannt fehlerfrei und standardkonform ist und das dürfte in Ermangelung der speziellen Tools die die Prüflabore haben wohl die ETS sein.

Ansonsten kann ich nächste Woche mal einen Wireshark von einem kaputten Edomi an Enertex schicken und ganz lieb fragen ob die da mal draufschauen können ...

[SeatSLF]

sind denke ich egal oder die ETS braucht ganz andere

anbei mal die Tunnel von mir Tunnel 1 = Edomi, Tunnel 2 die ETS, Tunnel 3 = EIBD

[SeatSLF]

es wird so sein wie Christian sagt, das normal der Router die PA angibt

EIBD kann man vorgeben was man wie er "übernimmt" scheinbar die PA

[MarkusS]

[USER="2"]
Dem EIBD ist es komischerweiße völlig egal wie die interne PA ist gegenüber der tatsächlichen Tunnel PA.

Leider gehen meine Programmierkenntnisse hier nicht sehr weit,
aber eibd greift ja nun auch per Tunnel auf den Router zu.

Könnte man nicht die "Software" Schnittstelle von EDOMI und EIBD vergleichen, irgendwas macht der EIBD da momentan besser.

Ich behaupte mal ganz bescheiden dass dieses "egal" schlagartig in Problem umschlägt wenn man das richtig macht, sprich:

1. Tatsächlich mehrere Linien betreibt und dabei die Topologie nicht vergewaltigt
2. In die Linienkoppler (AKA"Router") mal die Filtertabellen reinlädt so dass der Linienkoppler in beide Richtung nur noch gefilterte Telegramme durchlässt

Gerade wenn die Linienkoppler offen sind bzw. wenn man überhaupt nur eine Linie hat lässt der KNX diverse Schweinereien zu die einem z.B. bei TCP/IP unmittelbar auf die Füße fallen.

[gaert]

Es ist offenbar tatsächlich so, dass die PA vom ROUTER nach dem Verbindungsaufbau mitgeteilt wird! Ich bitte noch um etwas Geduld - aber mein Gefühl sagt mir: Bald funktioniert es mit JEDEM Router

[coliflower]

Update:

Ich habe weiterhin die Tunnel PA die ich im Gruppenmonitor der ETS5 bei Schaltvorgängen über Edomi gesehen habe (1.1.201) in der edomi.ini eingetragen. Der KNXnet/IP-Router selbst hat als Host die 1.1.0
Die ETS5 ist selbst über den Tunnel 1.1.251 verbunden.

Es ist mir aufgefallen, dass wenn ich auf der Edomi Visu am iPad2 einen 1bit Schaltbefehl ausführe, dass bei 1 OK und bei 0 kein Schaltvorgang ausgeführt wird und der ERROR Eintrag in der LOG erscheint … was „interessant“ dabei ist, dass der ERROR erst nach längerem „Leerlauf“ von Edomi und oder iPad kommt ...

Starte ich das Projekt neu, dann funktioniert 1bit fehlerlos und es gibt auch keinen ERROR Eintrag … bis zum nächsten „Mal“.

Soviel zu Gira I02

[SeatSLF]

MarkusS grundsätzlich gehört eine Visu/Logik Server meiner Meinung nach auf die Backbone, ich lasse mich gern eines besseren belehren.

Allerdings schießt man sich ins Knie, wenn man auf Tunnelverbindungen setzt, wenn es in der Umgebung noch andere Teilnehmer mit
"Tunnelwünschen" gibt.
Z.b. nach einem Stromausfall kommen 3 IP Geräte zurück wie kontrolliert man nun welchen Tunnel die Geräte bekommen.
Vielleicht sollte die Konnex IP Binding für die Tunnel zulassen und nicht nach dem "Friss oder Stirb" Prinzip vorgehen.

Scheinbar nutzt Gira deshalb Multicast genau deswegen, um diesem Problem aus dem Weg zugehen.

@gaert: da steht einer "Probe" Final nix mehr im weg *duckundweg*

coliflower das kann ich beim Enertex nicht nachvollziehen.
geht nach dem Error die Kommunikation grundsätzlich nicht mehr?
Oder du wartest es ab, das Christian es hinbekommt, das Edomi die PA des Routers/Tunnel akzeptiert.
Dann hat man das selbe Verhalten wie im EIBD und theoretisch keine Probleme mehr.

[apoc4lyps]

Ich hab gerade noch mal mit ETS5 (Verbindungstest) und EIBD mitgesniffert (EIBD antwortet mit 0.0.0).

[ATTACH=CONFIG]n895130[/ATTACH]

[coliflower]

Hier der ERROR Log:

[SIZE=10px]2016-01-05 16:56:26    010588    KNX    3508    ERROR: HEARTBEAT TIMEOUT (no ACK). Reconnect...    ERROR
2016-01-05 16:56:26    021183    KNX    3508    KNX-Verbindung verloren, Reconnect...    ERROR
2016-01-05 17:46:58    824958    KNX    3508    ERROR: IPRTR --> RECEIVE 1.1.26 ---> 0/3/3 = 0 / Rtg:42!=43 Size:3 / 061004200017040e2a002900bce0111a030303008007b2    ERROR
2016-01-05 17:50:57    399630    KNX    3508    ERROR: IPRTR --> RECEIVE 1.1.20 ---> 0/3/8 = 0 / Rtg:110!=111 Size:3 / 061004200017040e6e002900bce0111403080300800729    ERROR
2016-01-05 19:41:25    002264    KNX    3508    ERROR: EDOMI --> READ/WRITE: TIMEOUT REC / Rtg:1 / 0610020700100e0008010a0064080e58    ERROR
2016-01-05 19:41:29    008248    KNX    3508    ERROR: EDOMI --> READ/WRITE: TIMEOUT REC / Rtg:2 / 061004200015040e01001100bce011c91148010081    ERROR
2016-01-05 19:41:33    008400    KNX    3508    ERROR: EDOMI --> READ/WRITE: TIMEOUT REC / Rtg:3 / 061004200015040e02001100bce011c91148010081    ERROR
2016-01-05 19:41:33    021822    KNX    3508    ERROR: EDOMI --> READ/WRITE: TOO MANY ATTEMPTS (3) / DROPED    ERROR
2016-01-05 19:41:37    000861    KNX    3508    ERROR: EDOMI --> READ/WRITE: TIMEOUT REC / Rtg:4 / 061004200015040e03001100bce011c91148010081    ERROR
2016-01-05 19:41:41    006320    KNX    3508    ERROR: EDOMI --> READ/WRITE: TIMEOUT REC / Rtg:5 / 061004200015040e04001100bce011c91148010081    ERROR
2016-01-05 19:41:45    001884    KNX    3508    ERROR: EDOMI --> READ/WRITE: TIMEOUT REC / Rtg:6 / 061004200015040e05001100bce011c91148010081    ERROR
2016-01-05 19:41:45    012645    KNX    3508    ERROR: EDOMI --> READ/WRITE: TOO MANY ATTEMPTS (3) / DROPED    ERROR
2016-01-05 19:41:49    001051    KNX    3508    ERROR: EDOMI --> READ/WRITE: TIMEOUT REC / Rtg:7 / 061004200015040e06001100bce011c91148010081    ERROR
2016-01-05 19:41:53    006166    KNX    3508    ERROR: EDOMI --> READ/WRITE: TIMEOUT REC / Rtg:8 / 061004200015040e07001100bce011c91148010081    ERROR
2016-01-05 19:41:57    004066    KNX    3508    ERROR: EDOMI --> READ/WRITE: TIMEOUT REC / Rtg:9 / 0610020700100e0008010a0064080e58    ERROR
2016-01-05 19:41:57    014941    KNX    3508    ERROR: EDOMI --> READ/WRITE: TOO MANY ATTEMPTS (3) / DROPED    ERROR
2016-01-05 19:42:01    003745    KNX    3508    ERROR: EDOMI --> READ/WRITE: TIMEOUT REC / Rtg:10 / 061004200015040e09001100bce011c91148010081    ERROR
2016-01-05 19:42:05    005361    KNX    3508    ERROR: EDOMI --> READ/WRITE: TIMEOUT REC / Rtg:11 / 061004200015040e0a001100bce011c91148010081    ERROR
2016-01-05 19:42:09    010040    KNX    3508    ERROR: EDOMI --> READ/WRITE: TIMEOUT REC / Rtg:12 / 061004200015040e0b001100bce011c91148010081    ERROR
2016-01-05 19:42:09    021965    KNX    3508    ERROR: EDOMI --> READ/WRITE: TOO MANY ATTEMPTS (3) / DROPED    ERROR[/SIZE]

So ab 19:41 wurde zuerst eine 1 geschickt = OK, danach eine 0 >> ERROR
Erst durch Neustart funktioniert es wieder.

[DiMa]

Es ist offenbar tatsächlich so, dass die PA vom ROUTER nach dem Verbindungsaufbau mitgeteilt wird! Ich bitte noch um etwas Geduld - aber mein Gefühl sagt mir: Bald funktioniert es mit JEDEM Router

Warum reden wir eigentlich die ganze Zeit von ROUTERN wo doch Edomi offensichtlich TUNNELT?

apoc4lyps der eibd sendet immer 0.0.0 sobald er als Server konfiguriert ist - völlig egal, was man ihm an Parametern mitgibt (Handbuch 10.2.5, S. 163+164).

[gaert]

Problem sehr wahrscheinlich gelöst!

Ich habe es offenbar versäumt, die Antwort des Routers in Sachen PA richtig zu interpretieren. Nach dem Verbindungsaufbau teilt der ROUTER die PA mit - EDOMI's Konfiguration hat damit nichts zu tun. In der neuen Version ist also in der edomi.ini keine(!) PA mehr zu definieren!

Die neue Version lade ich gleich hoch (2016.3). Dauert wie immer eine Weile...

[gaert]

Der Tunnelaufbau funktioniert jetzt so:

• EDOMI fordert einen Tunnel vom Router an
• der Router antwortet (hoffentlich) mit "OK" - und teilt EDOMI u.a. die PA des zugewiesenen Tunnels mit
• EDOMI merkt sich u.a. diese PA und verwendet sie für alle weiteren Tunneling-Requests (also dem Senden/Empfangen von Telegrammen)

Übrigens: Die PA wird AUSSCHLIESSLICH beim Senden und Empfangen von Telegrammen benötigt - nicht etwa beim Verbindungsaufbau, Close, Heartbeat, etc. Dies erklärt auch, warum die Fehlermeldungen erst beim Senden/Empfangen aufgetreten sind - und nicht schon beim Connect...

[gaert]

Warum reden wir eigentlich die ganze Zeit von ROUTERN wo doch Edomi offensichtlich TUNNELT?

Mit "Router" ist die Hardware gemeint, nicht das "routing"

[SeatSLF]

bist du grad am Upload?

[MarkusS]

bist du grad am Upload?

Wie interpretierst Du denn die Aussage:

Die neue Version lade ich gleich hoch (2016.3). Dauert wie immer eine Weile...

"lade hoch" ≊ "Upload"