COVESA/dlt-daemon

When running dlt-receive with the -r option (reconnect interval), the tool is expected to reconnect automatically after the connection to the DLT daemon/server is lost. In practice, -r does not work reliably if the server-side socket is not closed properly (e.g., server crash, network disruption, or any failure mode where the TCP connection does not transition cleanly to a closed/error state from the client perspective). In these scenarios, the client socket can remain in a “connected” state and socket reads can block indefinitely. Because dlt-receive does not configure any socket read timeout (and also does not appear to rely on TCP keepalive probing / dead peer detection), the receive loop can hang forever waiting for data. As a result, the code path that triggers reconnect is never reached, and dlt-receive never reconnects. - Expected behavior If the server becomes unreachable or unresponsive (including cases where the server does not close the socket properly), dlt-receive shou

I am using the dlt-daemon 2.18.10. The dlt-daemon operating on the QNX target and two gateways configures theusing AUTOSAR based ECU node and another Android dlt-daemon. Below the configuration configured in QNX [PassiveNode1] -> Android DLT gateway configuration IPaddress=x.x.x.x Port=3490 EcuID=ANDR Connect=OnStartup Timeout=10 SendControl=0x03,0x04,0x13 SendSerialHeader=0 SendPeriodicControl=0x03:5,0x13:1 [PassiveNode2] -> Autosar DLT gateway configuration IPaddress=x.x.x.x Port=3490 EcuID=ECUA Connect=OnStartup Timeout=10 SendControl=0x03,0x04,0x13 SendSerialHeader=0 SendPeriodicControl=0x03:5,0x13:1 Problem: Any request to the dlt-control command line example adjusting the log level to all the passive node messages is going through segmentation (Header + Payload), and Autosar is not supporting TCP segmentation. If we control from the DLT-viewer, the DLT-gateway daemon sends the to all PassiveNode message, which is going through segmentation (Header + Payload). Note: I observed