IP-Interface (MDT SCN-IPxxx.03): Tunnel-zu-Tunnel-Forwarding wirkt GA-selektiv

[DAZ]

Hallo zusammen,

ich beobachte ein Verhalten, das ich mir nicht erklären kann, und hoffe auf Hinweise von euch.

Setup

- MDT SCN-IP000.03 IP-Interface (A7.1a)
- Tunnel "Kanal 1" → physikalische Adresse `1.1.2`: eine eigene Software (`knx-nats-bridge` auf xknx), die KNX-Telegramme mitliest und auf NATS publisht
- Tunnel "Kanal 3" → physikalische Adresse `1.1.4`: ETS Gruppen-Monitor

Problem

Wenn ich aus dem ETS-Tunnel (1.1.4) ein Telegramm auf bestimmte GAs sende, sieht der Bridge-Tunnel (1.1.2) das Telegramm **nicht** — bei anderen GAs **doch**. Beide Tunnel hängen am selben IP-Interface.

Test 1 — funktioniert nicht

ETS-Group-Monitor sendet auf `14/3/3` (DPT 5.010 Zählimpulse):

```
17:37:08 1.1.4 Tunnelling Kanal 3 → 14/3/3 $02 | 2
```

→ kein Eintrag im Bridge-Reader, keine Zeile im nachgelagerten Log.

Test 2 — funktioniert

ETS-Group-Monitor sendet auf `14/3/4` (DPT 1.005 Alarm):

```
17:52:46 1.1.4 Tunnelling Kanal 3 → 14/3/4 $01 | Alarm
```

→ Bridge sieht es ~600 ms später, Telegramm landet sauber im nachgelagerten Log.

Was identisch ist zwischen beiden GAs

- Selber Bus-Empfänger: `1.1.160 Basalte Core S4` mit einer "Dummy"-Applikation, einziges Group-Object pro GA
- Kommunikations-Flags am Group-Object identisch (K, L, S, Ü, A gesetzt)
- Linie/Topologie identisch (1.1)
- "Weiterleiten" am Linienkoppler explizit aktiviert (für die Test-GA) und Linienkoppler programmiert → keine Änderung

Was sich unterscheidet

- DPT (5.010 vs 1.005)
- Object-Länge (1 Byte vs 1 Bit)

Empirisches Muster

Über mehrere Tage hinweg: DPT-1.005-Alarm-GAs werden zwischen Tunneln zuverlässig forwarded, DPT-5.010-Counter/Zählimpuls-GAs nicht. Auch eigene Writes vom Bridge-Tunnel auf `15/4/*` (DPT 14.056 PV-Werte) sieht der Bridge-Tunnel selbst nicht zurück (= erwartet, anti-loop), aber andere Bus-Geräte / andere Tunnel-Clients sehen sie auch nicht.

Frage

Wie entscheidet das IP-Interface, ob es ein Telegramm zwischen zwei aktiven Tunneling-Verbindungen forwarded? Im Handbuch finde ich dazu nichts, und das Interface hat ja im Gegensatz zum IP-Router keine Filtertabelle. Hat das Verhalten mit dem DPT oder mit der Telegramm-Länge zu tun, oder gibt es eine interne "aktive GA-Liste" die nur befüllt wird wenn bestimmte Bus-Geräte ein passendes Group-Object haben?

Danke!

[Klaus Gütter]

Dass das im funktionierenden Fall erst nach 600ms erscheint, ist auch rätselhaft. Hast du mal mit dem Busmonitor auf der TP-Linie geschaut, ob da etwas auffälliges ist (z.B. fehlende oder negative Bestätigungen)?

[DAZ]

Hat sich aufgeklärt: die Bridge-Writes laufen sauber auf den Bus (L_Data.ind im Bus-Monitor sichtbar), aber die Bridge-eigene Tunnel-Verbindung bekommt sie nicht als Ind zurück — nur L_Data.con. Das scheint normal für viele IP-Schnittstellen zu sein (Originator-Tunnel filtert eigene Writes), wird mir aber zum Verhängnis weil mein Reader und Writer in xknx auf derselben Tunnel-Connection sitzen. Lösung wäre: separater Tunnel für Read oder Wechsel auf IP-Routing.

Den ursprünglichen "14/3/4 lebt, 14/3/3 nicht"-Eindruck kann ich aktuell nicht reproduzieren — alle Test-GAs verhalten sich symmetrisch (alle drei reichen den Bus, keine zurück zur Bridge). Möglicherweise war das früher eine Linienkoppler-Echo-Situation die seither weggefallen ist.

[volkerPotsdam]

DAZ ich kann leider bei Deinem Problem nicht helfen, wollte aber fragen, ob Du das MDT IP Interface mit dem Gira Homeserver mit Tunneling erfolgreich im Einsatz hast. Ich hab mit dem Weinzierl 731 hier leider keinen Erfolg gehabt und suche nun nach Alternativen.

viele Grüße
Volker