Am 17.10.22 um 16:55 schrieb Sebastien FABRE:
Hello, I am working on 5.4 kernel, and I have the same behavior with 5.10 kernel version. I reproduce the behavior with a custom application. A j1939 socket is created with SO_BROADCAST and SO_J1939_PROMISC options and is binded. The application sends a claim message then 50 broadcast messages in loop (without waiting) with size greater than 8 bytes (50). Every sendto methods return success directly and sessions are stored in sk_session_queue. If the can is 'on' but nobody acknowledges, after some times, trames are no longer sent (ENOBUFS) but the application does not have this information (sendto returned success). Moreover, txqueuelen does not have impact to this behavior (queue size seems to be infinite). To finish, closing socket will take a long time depending on sk_session_queue size because of J1939_XTP_TX_RETRY_LIMIT: kernel seems to try to send every message 100 times if ENOBUFS is received. Is it the expected behavior? How can the application know that messages are no longer sent?
Hello,I haven't done J1939 for a while but the typical scenario is that you set up a Can Raw Socket with some filters and timeout socket option to receive your own messages in application. You drop everything until that socket timeout happens which is the trigger to stop unconditional sending in application until something is received again.
Actually I would be interested if there are better ways to do this. -- Patrick
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
