Ets connection closed by remote device

[admin]

Not possible. Run ETS with and without Rithum connected to LM and provide group monitor log from ETS for both cases.

[gjniewenhuijse]

See attached logs

[admin]

Thanks! There are repeated T_ACK messages during programming when Rithum is connected. These messages have lower hop count (5 instead of 6) meaning that they are most likely sent back by Rithum for some reason.

[gjniewenhuijse]

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.

[admin]

Nice AI report, of course they would blame us

Anyway, tested a similar setup with two LMs:
- LM 1 is connected to TP bus
- LM 2 is connected to LM 1 via IP tunnel
- ETS connected to LM 1 via IP tunnel

IP routing is disabled on both LMs to prevent potential loops. Programming KNX device application works fine, no extra telegrams in ETS group monitor.

[gjniewenhuijse]

Here my knx config for both lm's.

Up Routing is enabled for multicast communication between lm1 and lm2?
Or can i disable ip routing?

[admin]

In this setup only group communication is possible via IP Routing. If "Pass ind. telegrams via IP Routing" is enabled then both LMs must belong to different KNX lines, e.g. 2.1.x and 2.2.x. Same applies to all KNX devices that are connected to each LM.

[gjniewenhuijse]

My setup:

- LM 1 is connected to TP bus line 1 (with 1 connected Rithum Touchscreen)
- LM 2 is connected to another TP bus line 2 (with 2 connected Rithum Touchscreens)
- LM 1 and LM 2 are connected to the same ip network and using Multicast IP for communication
- ETS connected to LM 1 via IP tunnel gives error when programming devices on TP line 1
- ETS connected to LM 2 via IP tunnel gives error when programming devices on TP line 2

IP routing is enabled on both LMs

[gjniewenhuijse]

Pass ind. telegrams via IP Routing is disabled as you can see in the config images

---

Ip routing disabled doesn't solve the problem.