KNX/EIB ETS4: Verändertes Connect-Verhalten

[mmartin]

Hallo zusammen,

für die, die auf Link-Layer-Ebene Programme schreiben vielleicht interessant (nur IP):

Die ETS4 hat ein ganz anderes Verhalten beim Connect als die ETS3:
Beim CONNECT_REQ werden innerhalb des HPAI nicht wie bei der ETS3 die Remoteadressen für Control- und Data-Endpoint mitgegeben, sondern mit Nullen aufgefüllt.

ETS3:
15:41:53.623937 IP 0.0.0.0.2029 > 192.168.178.100.3671: UDP, length 26
0x0000: 4500 0036 9600 0000 8011 31aa 0000 0000
0x0010: c0a8 b264 07ed 0e57 0022 6278 0610 0205
0x0020: 001a 0801 c0a8 b23f 07ed 0801 c0a8 b23f
0x0030: 07ee 0404 0200

ETS4:
09:20:23.950830 IP 0.0.0.0.58605 > 192.168.178.100.3671: UDP, length 26
0x0000: 4500 0036 8606 0000 8011 41a4 0000 0000
0x0010: c0a8 b264 e4ed 0e57 0022 7b23 0610 0205
0x0020: 001a 0801 0000 0000 0000 0801 0000 0000
0x0030: 0000 0404 0200

D.h. die Software, die einen solchen Request entgegennimmt, sollte den HPAI auf Nullen prüfen und Control- und Data-Endpoint dann aus der Remote-Adresse des UDP-Datagrams ermitteln.

Keine Ahnung, ob das ein Fehler der ETS4 ist oder die HPAI-Felder leer sein dürfen. Wäre schön, wenn mal sämtliche Protokoll-Informationen (kosten-)frei zur Verfügung gestellt werden.

Zusätzlich erzeugt die ETS4 beim Test nach dem Verbindungsaufbau auf Tunnel-Layer-Ebene einen weiteren Socket und öffnet eine Device-Management-Connection:

09:20:24.135566 IP 0.0.0.0.58606 > 192.168.178.100.3671: UDP, length 24
0x0000: 4500 0034 8a06 0000 8011 3da6 0000 0000
0x0010: c0a8 b264 e4ee 0e57 0020 7f29 0610 0205
0x0020: 0018 0801 0000 0000 0000 0801 0000 0000
0x0030: 0000 0203

... und macht anschließend zwei Device-Management-Requests.

Wer das verhindern will antwortet auf den zweiten Connect-Request mit 0x22 (connection type not supported)

Gruß,
Martin

[Gaston]

Die ETS4 hat ein ganz anderes Verhalten beim Connect als die ETS3:
Beim CONNECT_REQ werden innerhalb des HPAI nicht wie bei der ETS3 die Remoteadressen für Control- und Data-Endpoint mitgegeben, sondern mit Nullen aufgefüllt.

Ein VW hat ein ganz anderes Verhalten bei einer Kreuzung wie ein Audi, Ich habe letztens auf einer kreurung einen VW gesehen der ist bei Rot einfach durchgefahren, während der Audi ordnungsgemäss stehen blieb.

Was Ich damit sagen will: Es ist nicht weil man zwei unterschiedliche Verhalten beobachtet dass dies an den ETS Versionen liegt. Liegt ja auch vieleicht einfach nur an den Einstellungen.

Keine Ahnung, ob das ein Fehler der ETS4 ist oder die HPAI-Felder leer sein dürfen.

Ich denke Du hast in der ETS4 den Router im NAT-Modus definiert.

Gruss,
Gaston

[mmartin]

Hallo Gaston,

Was Ich damit sagen will: Es ist nicht weil man zwei unterschiedliche Verhalten beobachtet dass dies an den ETS Versionen liegt. Liegt ja auch vieleicht einfach nur an den Einstellungen.

Ich denke Du hast in der ETS4 den Router im NAT-Modus definiert.

Danke für die Rückmeldung. Es handelt sich tatsächlich um NATing.

Allerdings:
- das scheint in der ETS4 default zu sein
- es ist nicht vor erfolgreichem Verbindungsaufruf abwählbar (oder es gibt noch einen anderen Schalter)

d.h. NATing muss unterstützt werden, um es abzuwählen (?)

Gruß,
Martin

[Gaston]

d.h. NATing muss unterstützt werden, um es abzuwählen (?)

Tut mir leid aber Ich verstehe die Frage nicht so recht.

Wenn du in der ETS 4 unter Einstellungen eine neue KNXnet/IP Verbindung erstellst hats Du die Option "NAT-Modus", diese ist bei mir auf jeden Fall defaultmässig abgeschaltet.

Im NAT Modus ist die HPAI Null. Das Verhalten ist also korrekt.

Gruss,
Gaston

[mmartin]

Tut mir leid aber Ich verstehe die Frage nicht so recht.

Wenn du in der ETS 4 unter Einstellungen eine neue KNXnet/IP Verbindung erstellst hats Du die Option "NAT-Modus", diese ist bei mir auf jeden Fall defaultmässig abgeschaltet.

Im NAT Modus ist die HPAI Null. Das Verhalten ist also korrekt.

Ich versuche mal zu präzisieren:
Wenn Du die Verbindung manuell erstellst, ist NAT per default aus - easy.

Sobald Du in der ETS auf Kommunikation gehst, sendet die ETS alle 5 Sekunden ein Multicast (SEARCH_REQ), um alle potentiellen Gateways und Router im Netz zu finden.
Die Gefundenen werden dann auf der Seite angezeigt. Diese können getestet und eingestellt werden, sind aber defaultmäßig auf NAT konfiguriert. Das Testen funktioniert dann auch nur mit NAT. Wenn Du auf Einstellungen gehst, wird dann auch erst ein Connect per NAT durchgeführt - ist ja auch so eingestellt - der funktioniert aber nicht, wenn das Gateway (oder hier die Software) nicht auf die Nullen im HPAI korrekt reagiert.

Ich habe aber den Button "Bearbeiten" übersehen. Damit kannst Du auch Verbindungen konfigurieren, ohne dass sie sich connecten müssen.

Damit passt das für mich.

Gruß,
Martin

[Gaston]

Die Gefundenen werden dann auf der Seite angezeigt. Diese können getestet und eingestellt werden, sind aber defaultmäßig auf NAT konfiguriert.

Ja, da die ETS 4 IGMP verwendet kann sie nicht ausschliessen dass NAT verwendet wird.

Das Testen funktioniert dann auch nur mit NAT.

Was bedeutet hier "nur mit NAT" ? Das müsste eigentlich funktionieren ob NAT wirklich verwendet wird oder nicht, sogar im gleichen Netz da NAT in diesem Modus transparent ist.

Also: Bei angewählter "NAT"-Option sollte die Kommunikation in jedem Fall funktionieren. Bei ausgeschaklteter "NAT"-Option funktioniert die Kommunikation nur wenn kein NAT verwendet wird.

Wenn Du auf Einstellungen gehst, wird dann auch erst ein Connect per NAT durchgeführt - ist ja auch so eingestellt - der funktioniert aber nicht, wenn das Gateway (oder hier die Software) nicht auf die Nullen im HPAI korrekt reagiert.

Dann ist die Software m.E. nicht Norm-Konform.

Ich habe aber den Button "Bearbeiten" übersehen.

Ja, den haben sie ja super plaziert, und dann ein "Einstellungen" Button direkt bei der Konfiguration wo man eigentlich denkt der sei für das Zuständig was der "Bearbeiten" Butten macht: Schlechte Ergonomie.

Gruss,
Gaston