27.03.2026, 06:53
From Rithum support:
Our analysis is pointing to it being a LogicMachine router issue:
With 3 tunnel clients (ETS + 2 switches):
- Gateway receives ETS's frame from the TP bus
- Forwards to switch A's tunnel → switch A's gateway-side processing generates an L_Data.ind on the bus
- Forwards to switch B's tunnel → same thing
- Does NOT forward back to ETS's tunnel
The two L_Data.ind echoes that ETS sees are the gateway putting the frame back on the TP bus once per forwarded tunnel client. The gateway is treating tunnel-forwarded frames as if they need a bus confirmation back to the originator.
So it looks like a gateway bug — it's generating spurious L_Data.ind on the bus for frames it forwards to tunnel clients. With 0 switches connected, 0 echoes. With 2 switches, 2 echoes. The KNX spec does say a tunnelling server should forward bus telegrams to all connected tunnel clients — but it should NOT generate spurious L_Data.ind frames on the TP bus as a side effect of that forwarding. The LogicMachine appears to be doing exactly that: each tunnel-client forwarding generates an unintended bus echo.
There seems to be some other reported issues that look like being the same problem with LogicMachine:
1 LogicMachine forum tid=5341: When two LogicMachine devices were connected simultaneously (one TP-UART, one IP tunnel to the first), ETS programming failed. Removing the second device fixed it. Same pattern as our issue.
2 Multiple sources confirm that having other tunnel clients connected (e.g. Home Assistant) while ETS programs through a LogicMachine tunnel causes failures. The documented workaround is to disconnect other tunnel clients before ETS programming.
3 LogicMachine has prior KNXnet/IP bugs: invalid status codes (tid=707), broken long frame support (tid=3179), missing KNX Secure APDU handling (tid=4668). So firmware-level tunnelling bugs are not unprecedented.
4 knxd had the exact same class of bug (GitHub #16): TPUART echoed back packets while sending, and the backend incorrectly treated echoes as incoming packets, causing duplicates.
I'm fairly sure that if the switch was echoing those packets then we would have had this ETS problem reported by customers using other routers/interfaces.
Our analysis is pointing to it being a LogicMachine router issue:
With 3 tunnel clients (ETS + 2 switches):
- Gateway receives ETS's frame from the TP bus
- Forwards to switch A's tunnel → switch A's gateway-side processing generates an L_Data.ind on the bus
- Forwards to switch B's tunnel → same thing
- Does NOT forward back to ETS's tunnel
The two L_Data.ind echoes that ETS sees are the gateway putting the frame back on the TP bus once per forwarded tunnel client. The gateway is treating tunnel-forwarded frames as if they need a bus confirmation back to the originator.
So it looks like a gateway bug — it's generating spurious L_Data.ind on the bus for frames it forwards to tunnel clients. With 0 switches connected, 0 echoes. With 2 switches, 2 echoes. The KNX spec does say a tunnelling server should forward bus telegrams to all connected tunnel clients — but it should NOT generate spurious L_Data.ind frames on the TP bus as a side effect of that forwarding. The LogicMachine appears to be doing exactly that: each tunnel-client forwarding generates an unintended bus echo.
There seems to be some other reported issues that look like being the same problem with LogicMachine:
1 LogicMachine forum tid=5341: When two LogicMachine devices were connected simultaneously (one TP-UART, one IP tunnel to the first), ETS programming failed. Removing the second device fixed it. Same pattern as our issue.
2 Multiple sources confirm that having other tunnel clients connected (e.g. Home Assistant) while ETS programs through a LogicMachine tunnel causes failures. The documented workaround is to disconnect other tunnel clients before ETS programming.
3 LogicMachine has prior KNXnet/IP bugs: invalid status codes (tid=707), broken long frame support (tid=3179), missing KNX Secure APDU handling (tid=4668). So firmware-level tunnelling bugs are not unprecedented.
4 knxd had the exact same class of bug (GitHub #16): TPUART echoed back packets while sending, and the backend incorrectly treated echoes as incoming packets, causing duplicates.
I'm fairly sure that if the switch was echoing those packets then we would have had this ETS problem reported by customers using other routers/interfaces.