ETS5 und Schnittstellen

[makki]

Das liest sich für mich, als gäbe es Probleme mit der lokalen Firewall!

Kann ich bei meinen eigenen Tests ausschliessen. Abgeschaltet, keine Drittprodukte installiert.

Ansonsten bin ich voll bei salixer, das "sauber" darzulegen und mit Captures zu untermauern kostet allerdings Zeit. Viel Zeit..
VM's akzeptiert die Konnex ja nicht, also mache ich das mit zwei Rechnern nebeneinander.
saubere Captures folgen (bitte eMail-Adresse, nicht PN)..

Die Entscheidung, den NAT Modus in der ETS5 NICHT standardmäßig zu aktivieren, ist vor dem Hintergrund von Security gefallen, weil die Praxis gezeigt hat, dass sehr viele Installationen ungeschützt über Port 3671 mit NAT Modus ins Internet gehängt wurden.

Was purer Harakiri ist.. Aber ich muss es leider bestätigen: es ist so.

Und der KNXnet/IP-Header iSv ISO/OSI bestenfalls ein Designfehler, aber das ist ein anderes Thema..

Ich glaube nicht, dass das User Forum der richtige Platz ist, für derart tiefgreifende technische Diskussionen. Das hilft den Nutzern nicht weiter!

Das sehe ich allerdings komplett anders!
Denn (zahlende) Nutzer sind offenbar davon betroffen, sonst hätten sie mich nicht angerufen.
Ich kenne nun schon mindestens drei davon, die Tage und Nächte versch*** haben; also warum sollte dem aufmerksamen Benutzer/Leser die Information verwehrt werden, das er evtl. garnichts falsch macht?!
"Normale" Anwender haben oft weder das Know-How noch die Zeit sowas fundiert zu begründen oder zu erläutern.

Denen helfen wir dann mit Hinweisen auf die FW o.ä...
Wenn man damit bei der Konnex (oder einem beliebigen anderen Hersteller) anruft, verbringt man mehr Zeit mit der Erklärung, das man nicht zu dämlich ist, als dem eigentlichen Problem..

Da Sie offenbar Hersteller sind,

Eben, genau deswegen

Die 36h sind zwar schon länger um, aber ich gehe mal auf 4:2

Win 7 32 (VM) (Firewall deaktiviert)
Gira 216700 & Raspi mit ROT (eibd) & EIBlib (HS mit USB) (& Weinzierl USB)
lokales LAN

-> keinerlei Probleme

Interessant, da ansich identisch; aber doch komplett anders (wenn ich das richtig verstehe?):
ETS5 -> EIBlib/IP(HS) -> KNXnet/IP -> eibd -> KNX(TP1)
Das KNXnet/IP ansich funktioniert ist unstrittig, wiederhole den Test doch mal bitte ohne HS, direkt aufn eibd (Tunneling oder Routing)

Makki

[Twilek]

Der Vollständigkeit halber

Weinzierl 730 IP ohne NAT Modus keine Verbindung, mit NAT gehts. Win 7 64bit keine Firewall. ETS 4 läuft problemlos.

[MuckiLegden]

Das ist schön für dich, allerdings steht es gerade 4:1
Denn ansonsten hat sich seit 36h keiner gemeldet, bei dem das funktioniert.

Also für nen sauberen Bugreport sollten wir mal sammeln:

- Windows 7/8, 32/64 Bit?
- Welche Schnittstelle (exakte Produktbezeichnung)?
- Netzwerkstruktur (sofern nicht lokales LAN)?
- Gerät?

Makki

Die 36h sind zwar schon länger um, aber ich gehe mal auf 4:2

Win 7 32 (VM) (Firewall deaktiviert)
Gira 216700 & Raspi mit ROT (eibd) & EIBlib (HS mit USB) (& Weinzierl USB)
lokales LAN

-> keinerlei Probleme

Viele Grüße,
Mucki

P.S. dafür finde ich die Fehler, die ich beim Beta-Test schon gemeldet hatte, nach und nach wieder

[coliflower]

Vielen Dank auch !

[salixer]

Oder anders gesagt: jeder Tunnel hat eine eigene PA, da ja prinzipiell an jedem Tunnel auch ein Endgerät angeschlossen ist, das dann über diese PA identifiziert werden kann.

[coliflower]

Vielen Dank für die - für mich - sehr gute Erklärung, da mir bis dato diese Tatsache nicht so bewusst war !

[Elwedritsche]

Wenn ich dort die oben genannte PA 1.1.0 eintrage dann bekomme ich eine Fehlermeldung: „die PA 1.1.0 wird bereits von einem anderen Gerät verwendet“ Wenn ich 1.1.254 eintrage, dann erhalte ich eine OK Meldung …

Hallo coilflower,
Die 1.1.0 ist die Adresse des Routers. Die braucht er, damit er Koppler sein kann.
Damit er das weiter sein kann, auch dann, wenn sich jemand über ihn auf den Bus verbindet, haben IP Router noch weitere Adressen (je nachdem wie viele Tunneling Verbindungen sie gleichzeitig akzeptieren), unabhängig von der Koppler Adresse. Dieser Umstand ist in der ETS5 daher extra dargestellt als "Host PA" und "PA". Diese extra Busverbindungsadresse darf natürlich nicht identisch sein mit der Adresse, die der Router für seine Koppler Funktionalität selbst braucht (die ".0" Adresse) oder einer der Adressen, die andere Tunneling Verbindungen schon nutzen. Daher die Meldung.
Es ist also richtig, bei Verwendung der Buszugangsschnittstelle (Tunneling) des Routers dieser eine andere PA (innerhalb der Linie des Routers) zu vergeben.

[coliflower]

Ich hätte da doch noch eine Frage - möglicherweise have ich etwas in der Gira Anleitung des Routers überlesen oder schlicht und einfach nicht verstanden …

Ich habe einen GIRA IP-Router V2.
Es sind zwei Adressen zu vergeben, eine für den Router (1.1.0) und eine für den Datenlogger/Zeitgeber (1.1.1) .. das funktioniert grundsätzlich ohne Auffälligkeiten …

Wenn ich in die ETS5 gehe auf Bus > Schnittstellen > Konfigurierte Schnittstellen, dann habe ich bei KNXnet/IP (Tunneling) die 192.168.193.15:3671 (mit Routing 224.0.23.12:3671 erhalte ich keine Verbindung zum Router).
Wenn ich dort die oben genannte PA 1.1.0 eintrage dann bekomme ich eine Fehlermeldung: „die PA 1.1.0 wird bereits von einem anderen Gerät verwendet“
Wenn ich 1.1.254 eintrage, dann erhalte ich eine OK Meldung …

Was übersehe ich nicht bzw. was habe ich nicht beachtet, was müsste ich korrigieren ?

DANKE vorab !!

[Uwe!]

Wer mir Wireshark Aufzeichnungen seiner Verbindungsprobleme der Form "ETS4 geht/ETS5 geht nicht (oder zumindest nicht ohne NAT Modus)" zusenden kann, darf das gerne tun.

Kannst Du gerne haben, PM ist unterwegs!

PS: welche Aspekte findest Du denn haarsträubend?

[coliflower]

… über die fortschritte/ergebnisse informiere ich in diesem thread gerne ...

danke !

[Elwedritsche]

Gerne trage ich weiter zu einer Versachlichung dieses teilweise haarstreubenden Threads bei. Dazu benötige ich allerdinge Ihre Mithilfe:

Wer mir Wireshark Aufzeichnungen seiner Verbindungsprobleme der Form "ETS4 geht/ETS5 geht nicht (oder zumindest nicht ohne NAT Modus)" zusenden kann, darf das gerne tun. Dazu PM an mich, dann gibt es die E-Mail Adresse.

Über die Fortschritte/Ergebnisse informiere ich in diesem Thread gerne.

Gruß
Elwedritsche

[mumpf]

Ich glaube nicht, dass das User Forum der richtige Platz ist, für derart tiefgreifende technische Diskussionen. Das hilft den Nutzern nicht weiter!

Ich gebe gerne zu, dass ich nicht alle Details eurer Diskussion verstehe, aber ich finde es gut, dass es hier im Forum diskutiert wird! Mich verwirrt das nicht, sondern es erlaubt mir, den Fortschritt zu verfolgen. Bei einem Ticket klappt das nicht.

Gruß, Waldemar

[Uwe!]

ich hatte es, wie gesagt, auch schon mit deaktivierter Firewall versucht. Gleiches Ergebnis.

Gleichwohl ist anzumerken, dass die ETS5 KEINE Anfrage der Windows-Firewall hervorgerufen hat, also scheinbar gar nicht aktiv versucht hat, auf das Netz zuzugreifen. Ich werde mal spaßeshalber die passenden Einträge vornehmen und prüfen, ob sich was ändert.

Parallel ist seit einigen Tagen ein Ticket bei der Konnex offen, aber noch ohne Reaktion.

@Jan:
Bist Du an der ETS-Entwicklung beteiligt?

[Elwedritsche]

da die FW für die ETS4 beide, TCP und UDP Ports erlaubt, genügt der UDP für die ETS5 wie du schreibst ?

Ja, das reicht. Alle anderen Optionen wie bei dem ETS4 Eintrag auf beliebig.

[Elwedritsche]

Die Antwort dürfte aber sowohl im NAT als auch im Nicht-NAT-Modus an den gleichen Port gehen.

Die ConnectResponse schon. Die ETS5 ohne NAT Modus sendet darin aber für den Data Endpoint einen HPAI mit vom Control Endpoint unterschiedlichem UDP Port.

Außerdem: falls nur die Antworten (ACK) der ETS durch die Firewall gefiltert werden, dann müssten die Telegramme trotzdem im Gruppenmonitor erscheinen. Tun sie aber nicht.

Die Firewall filtert die eingehenden Gruppentelegramme an den Data Endpoint. Daher sieht man die bei Firewall Problemen nicht, so lange man selbst nicht einmal eine Gruppe beschrieben/gelesen hat. Das ist jedenfalls das typische Fehlerbild bei Firewall Problemen. Wenn Sie ein anderes Fehlerbild haben, mag es sich bei Ihnen in der Tat um ein anderes Problem handeln. Das kann ich allerdings ohne weitere technische Details nicht beurteilen.

Von daher bin ich mir ziemlich sicher, der Fehler liegt an der ETS5.

Dann wenden Sie sich bitte an den Support der KNX Association mit ausführlicher Fehlerbeschreibung (Wireshark Traces und Log Dateien).

Ich glaube nicht, dass das User Forum der richtige Platz ist, für derart tiefgreifende technische Diskussionen. Das hilft den Nutzern nicht weiter!

Da Sie offenbar Hersteller sind, sollten Sie sich an die KNX Association wenden, wenn Sie von Inkompatibilitäten der ETS5 mit Ihren Produkten überzeugt sind. Generell "kaputt" ist die KNX/IP Kommunikation in der ETS5 jedenfalls nicht!

MfG
Elwedritsche