ETS 6.1.0 mit knxd funktioniert nicht mehr

[icasasmarthome]

Hallo zusammen
Seit dem ETS 6.1.0 funktioniert das Programmieren der KNX-Geräte über knxd nicht mehr.
Der Gruppenmonitor funktioniert noch. Mit dem ETS 6.0.6 funktioniert es ebenfalls noch.

Es wurde mit der neusten Version vom knxd getestet (0.14.56.2).

Wir haben ca. 50 solche "knxd-Anlagen" in Betrieb und alle funktionieren mit dem ETS 6.1.0 nicht mehr.

Unsere knxd-Parameter (welche bisher funktionierten):
KNXD_OPTS="-e 1.1.245 -E 1.1.246:5 -D -T -S -b tpuarts:/dev/ttyS1"

Beste Grüsse
Heinz

[Smurf]

Das ist nicht nett.

Kannst du bitte je einen Programmierversuch mit 6.0 und 6.1 mit Wireshark protokollieren und die resultierenden .pcap-Dateien irgendwo hochladen und/oder mir per Mail schicken? (matthias@urlichs.de)

[Mr Robot]

Ich wollte fragen ob es schon Neuigkeiten bezüglich dem genannten Thema gibt. Ich habe nämlich das selbe Problem.

[mycroft2k]

in ETS 6.1 als (IP Routing Multicast) funktioniert die Programmierung

solltest du noch einen Wireshark Protokoll brauchen könnte ich einen erstellen

[schmarra]

Hab leider auch das Problem - gibt es mittlerweile Neuigkeiten?

mycroft2k: Was genau hast du für Parameter gesetzt?

Smurf: Nachdem es anscheinend keinen Weg mehr zurück gibt mit der Projektdatei - aufgrund des neuen Schemas - auf die 6.0.6 könnte ich höchstens 6.1 anbieten...

[mycroft2k]

KNXD_OPTS="-e 0.0.200 -E 0.0.201:20 -n RPI3_KNXDaemon -D -R -T --Server 224.0.23.12:3671 -b tpuarts:/dev/ttyAMA0"


In ETS ist die Multicast ausgewählt
image.png

[schmarra]

Vielen Dank, mycroft2k, ich kann bestätigen so ist programmieren noch möglich in der 6.1

[MarkusWarg]

Das mit multicast in der ETS geht aber nur, solange man mit der ETS im selben Netz ist wie der knxd.
Wir suchen gerade eine Möglichkeit, wie man das aus einem anderen Netz tun kann (VPN, aber auch die Trennung zwischen knx und Geräten im lokalen Netz in separate VLANs ist ja nichts ungewöhnliches).
Wir haben gerade genau den Effekt:
* knxtool Steuerung vom knxd Host geht
* Diagnose und Steuerung (Aktoren schalten) in ETS über den IP Tunnel geht
* weder Programmieren von physikalischen Adressen noch Applikation geht

Nachtrag:
* ETS 6.1 - sagt ja der Titel des Beitrags schon
* es gibt einen GIRA USB REG Koppler (1.0.240)
* knxd habe ich jetzt auf ip mit Multicast Adresse umgestellt, den Serverteil ohne multicast-address (Config siehe unten)

Effekt:
* auf dem knxd Host: knxtool groupswrite auf ip:localhost schaltet, die Datagramme kommen auch im Log vom knxd an, ABER die Rückmeldungen nicht. Die RM sieht man in der ETS nur, wenn man über USB gekoppelt ist
* ETS über IP mit dem knx als Schnittstelle: in der Diagnose über die Gruppenadresse schalten kommt an, taucht auch im Log vom knxd auf, ABER die Quelladresse ist 0.0.0 und die RM fehlt
* ETS über USB Koppler als Schnittstelle: Diagnose und Gruppenadresse schalten kommt an, Log schaut gut aus (sowohl Schaltbefehl als auch Rückmeldung)

Senden wir über knxd mit knxtool haben wir die Quelladressen aus der Config (0.0.10X). Senden wir mit ETS über knxd als Schnittstelle, haben wir 0.0.0 als Quelladresse (was vielleicht erklärt, wieso keine RM kommen). Senden wir mit der ETS über USB, haben wir die Adresse vom Koppler als Quelladresse (1.0.240).

Die beiden KNX IP Router sind komplett auf Durchzug geschaltet (also nicht filtern).

Wieso kommen die Datagramme aus der ETS über knxd mit einer 0.0.0 als PD raus? Was auffällt, legt man in der ETS einen neuen Tunnel an, zeigt er nach Eingabe der IP kurz eine plausible PD an (bei mir 0.0.101). Öffnet man die Verbindung später wieder, steht dort 0.0.0 und das läßt sich auch nicht mehr ändern. Fehler in der ETS?

Haben wir in der knx.ini noch irgendwelche Denkfehler? Oder deuten die Merkwürdigkeiten an, dass wir einen Denkfehler in der Topologie (mit dem IP Backbone) haben?

Danke,

Markus

[A.ip]
driver = ip
multicast-address = 224.0.23.12
interface = enp3s0

[A.ipt]
debug = debug-A.ipt
driver = ipt
filters = single
ip-address = 10.255.128.100
retry-delay = 5

[debug-A.ipt]
trace-mask = 0x3fe

[debug-main]
error-level = 0x9
trace-mask = 0x3fe

[debug-server]
name = mcast:knxd

[main]
addr = 0.0.100
client-addrs = 0.0.101:8
connections = server,A.ip
debug = debug-main
systemd = systemd

[server]
debug = debug-server
discover = true
router = router
server = ets_router
tunnel = tunnel
#multicast-address = 224.0.23.12

[MarkusWarg]

Noch ein Nachtrag:
Wir haben ein DNAT Forwarding auf dem knx Host eingerichtet, was direkt auf einen der beiden KNX IP Router geht. Tragen wir das als Tunnel Device in der ETS ein, gehts einwandfrei. Sowohl Programmieren als auch Lesen/Schreiben.
Da das alles bei uns intern im Netz passiert ist das sicherheitstechnisch kein Problem. Für den Zugriff von $welt per NAT gibt es genug Warnungen, das sollte man nicht machen.

Was aber auch hier anzumerken ist: die mitlaufende Diagnose in der ETS zeigt beim Programmieren jede Menge Datagramme an. Das knxd Log bleibt leer.
Schalten wir über Diagnose einen Aktor, sehen wir das Datagramm + die RM in der ETS. Das knxd Log bleibt leer.
Schalten wir mit knxtool auf dem knx Host einen Aktor, sehen wir wieder nur das gesendete Datagramm.

Stelle ich knxd auf A.ipt um, sehen wir auch RM.

Programmieren über die ETS geht aber in beiden Fällen nicht.

Da das mittlerweile alles relativ kraus ist und wir noch relativ wenig Peil von dem haben, was wir hier tun: kann uns jemand evtl. sagen, was wir noch an Doku zur Verfügung stellen oder welchen Fall wir noch testen welche Logs wir posten sollen?

vielen Dank,
Markus

[roadrunnerv2]

Hallo!

Gibt es hierfür schon eine Lösung?

Danke!

[dwxx]

Hallo,

das Problem tritt auch auf, wenn man eine Geräteinfo ausliest. Damit kann man es auch ausprobieren, ohne etwas an der Gerätekonfiguration herumzuschreiben.
Ich habe mal einen Wireshark Mitschnitt gemacht, einmal mit der ETS 6.0.6, mit der es noch funktioniert, und einmal mit der ETS 6.2.1, mit der es nicht mehr funktioniert.
Vielleicht kann damit jemand etwas anfangen.

[matt82]

Hallo,

gibt es Neuigkeiten zu dem Thema?
Leider bin ich mit knxd 0.14.46-1 und ETS 6.2.2 auch betroffen. Multicast ist für mich keine Option, da sich knxd in einem entfernten IP Subnetz befindet.

P.S. Wireshark Trace habe ich gemacht, falls von Interesse, würde ich diesen hier hochladen.

[Smurf]

Es wäre super, wenn man die ETS irgendwie dazu bewegen könnte, uns zu sagen, was zum Geier sie eigentlich für ein Problem hat. Der Log zeigt ja deutlich, dass sie im Fehlerfall auf Paket 27 (dem data.Ind) zwar mit einem Tunnel-Ack antwortet, aber nicht mit einem Data-Ack, das Paket somit ignoriert und nach drei Sekunden dann in den Timeout geht und die Verbindung beendet.

Denke das ist ein Fall für "wir schreiben einfach mal die ETS-Leute an und fragen". Habe somit soeben einen entsprechenden Request (Nr. 252306) bei der ETS eingekippt.

[henfri]

Vielleicht kann Klaus Gütter helfen?

[Klaus Gütter]

Das Support-Ticket landet sowieso auf meinem Schreibtisch, schaue ich mir dann gleich an.