If you get seemingly random errors on the TCP side - I’ve just found a bug. Already reported to support #[SUP-130404] - hopefully will be fixed soon.
In my setup, I’m running a Debian 12 in a VM under XCP-NG, running my own application (written in C, using libmodbus) under it, this application talks over Modbus TCP to the KNOT, then the KNOT talks to a few devices (energy meters, PV inverters etc.) over a common RS485 bus. It works most of the time, except for some seemingly random errors where I suspected (but now ruled out) electrical noise and/or high load on the RS485 bus. To rule out bugs in my application, I have also reproduced the issue using mbpoll as Modbus client (it uses the same libmodbus library). To rule out Modbus slave hardware, tested and reproduced with two different devices too (one which I made myself, and one Growatt PV inverter).
The bug still exists in 7.11.2 as well as 7.12rc1, and is reliably reproducible. When reading two holding registers (quite common operation - many devices return a single floating-point value as two consecutive 16-bit registers), if the last byte of the RTU frame (2nd byte of the CRC) happens to be 0 (it can, 0 in the CRC-16 is as good as any other byte value, so it’s 1/256 of the time on average - only statistically, but could actually be “most of the time” with some bad luck), the TCP response is short by one byte, and this is detected as a timeout by libmodbus (knows the expected response length, times out waiting for that one last byte to arrive on the TCP socket), but the missing byte is wrongly and silently assumed to be 0 by the “CAS Modbus Scanner” (another popular free as-in-beer Modbus test software). Strange, I couldn’t reproduce this when reading other numbers of registers than 2 - so as a temporary workaround, I changed any 2-register reads in my application to read 3 or 4 registers. But there may be other conditions where it can be triggered, that’s just what I found so far.