Hello, thanks for the response!
Modbus TCP specifications does not talk about support of multiple request in single TCP/IP packet.
That makes sense, as TCP is stream-based not packet-based (unlike say SCTP). A single request may well arrive as a single TCP/IP packet, or multiple, or as single byte packets due to networking equipment, OS behaviour, etc.
The receiving end has to handle the buffering and reconstruction of requests/messages/units of the application-level protocols as appropriate and necessary. The Modbus TCP specification only describes the application-level protocol and the buffering/reconstruction is implied as it's a necessity for any application protocol built on top of stream-based protocols.
Note the Modbus TCP header includes the length of the packet to make this buffering and reconstruction easier, as is typical for application protocols built on top of stream-based protocols.
Quoting the Modbus TCP specifcation:
When MODBUS is carried over TCP, additional length information is carried in the MBAP header to allow the recipient to recognize message boundaries even if the message has been split into multiple packets for transmission.
This matches what I said above. Many modbus messages may be sent in one TCP/IP packet. Or they might happen to be split up at random places and arrive in multiple separate chunks (albeit in order). It's up to the application implementation to handle this.
Currently sending multiple Modbus ADUs, even if as separate TCP/IP packets (ensured by for example disabling Nagle's algorithm on the sending side), results in the router closing the connection. I believe this goes against the Modbus TCP specification allowing multiple requests in-flight at the same time. Besides, that's the transcation identifier is for.
It seems Teltonika's Modbus TCP implementation assumes an underlying packet-based protocol and doesn't handle incoming data as a stream.
Let me know if you need any further clarifications. I'd be happy to help!