J1939: Send messages without acknowledging

J1939: Send messages without acknowledging

[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? 

Best regards,
Sébastien Fabre 

Re: J1939: Send messages without acknowledging

[Patrick Menschel]

[-- Attachment #1.1: Type: text/plain, Size: 1539 bytes --]

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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: J1939: Send messages without acknowledging

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 1588 bytes --]

On 17.10.2022 14:55:58, Sebastien FABRE wrote:
> 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?

It's sort of expected....I think we haven't thought of that corner case.
There is the socket TX timeout option, seems we have to implement this
for j1939.

regards,
Marc

-- 
Pengutronix e.K.                 | Marc Kleine-Budde           |
Embedded Linux                   | https://www.pengutronix.de  |
Vertretung West/Dortmund         | Phone: +49-231-2826-924     |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-5555 |

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

RE: J1939: Send messages without acknowledging

[Sebastien FABRE]

> On 17.10.2022 14:55:58, Sebastien FABRE wrote:
> > 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?
> 
> It's sort of expected....I think we haven't thought of that corner case.
> There is the socket TX timeout option, seems we have to implement this for
> j1939.
> 

I reproduced the same behaviour with updated testj1939 (so no claim message) to be able to send multiple messages.
The tests have been done with peak can or flexcan.
Should we limit the sk_session_queue size to not be able to have too many messages in this queue ? In this case, sendto will return an error (and not success) when it is full.

Regards,
Sébastien Fabre

Re: J1939: Send messages without acknowledging

[Oleksij Rempel]

Hi Sebastien,

On Thu, Oct 20, 2022 at 01:17:36PM +0000, Sebastien FABRE wrote:
> > On 17.10.2022 14:55:58, Sebastien FABRE wrote:
> > > 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?
> > 
> > It's sort of expected....I think we haven't thought of that corner case.
> > There is the socket TX timeout option, seems we have to implement this for
> > j1939.
> > 
> 
> I reproduced the same behaviour with updated testj1939 (so no claim message) to be able to send multiple messages.
> The tests have been done with peak can or flexcan.
> Should we limit the sk_session_queue size to not be able to have too many messages in this queue ? In this case, sendto will return an error (and not success) when it is full.

Can you reproduce same issue with j1939cat in broadcast mode?

The difference between testj1939 and j1939cat is the last one is
designed to get error/completion reports from the kernel J1939 stack.

Regards,
Oleksij

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

RE: J1939: Send messages without acknowledging

[Sebastien FABRE]

Hi Oleksij,

> Hi Sebastien,
> 
> On Thu, Oct 20, 2022 at 01:17:36PM +0000, Sebastien FABRE wrote:
> > > On 17.10.2022 14:55:58, Sebastien FABRE wrote:
> > > > 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?
> > >
> > > It's sort of expected....I think we haven't thought of that corner case.
> > > There is the socket TX timeout option, seems we have to implement this for
> > > j1939.
> > >
> >
> > I reproduced the same behaviour with updated testj1939 (so no claim
> message) to be able to send multiple messages.
> > The tests have been done with peak can or flexcan.
> > Should we limit the sk_session_queue size to not be able to have too many
> messages in this queue ? In this case, sendto will return an error (and not
> success) when it is full.
> 
> Can you reproduce same issue with j1939cat in broadcast mode?
> 
> The difference between testj1939 and j1939cat is the last one is
> designed to get error/completion reports from the kernel J1939 stack.

Indeed, with j1939cat, I have now an error, but it takes a long time to close the socket. It seems to be because recvmsg is called after the last message (so j1939 queue contains a lot of messages) and not after each message send.
So, is it recommended to use j1939cat mechanism (with errqueue)  to send j1939 broadcast messages ?

Regards,
Sébastien Fabre 

Re: J1939: Send messages without acknowledging

[Oleksij Rempel]

Hi Sebastien,

On Mon, Oct 24, 2022 at 04:15:13PM +0000, Sebastien FABRE wrote:
> Hi Oleksij,
> 
> > Hi Sebastien,
> > 
> > On Thu, Oct 20, 2022 at 01:17:36PM +0000, Sebastien FABRE wrote:
> > > > On 17.10.2022 14:55:58, Sebastien FABRE wrote:
> > > > > 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?
> > > >
> > > > It's sort of expected....I think we haven't thought of that corner case.
> > > > There is the socket TX timeout option, seems we have to implement this for
> > > > j1939.
> > > >
> > >
> > > I reproduced the same behaviour with updated testj1939 (so no claim
> > message) to be able to send multiple messages.
> > > The tests have been done with peak can or flexcan.
> > > Should we limit the sk_session_queue size to not be able to have too many
> > messages in this queue ? In this case, sendto will return an error (and not
> > success) when it is full.
> > 
> > Can you reproduce same issue with j1939cat in broadcast mode?
> > 
> > The difference between testj1939 and j1939cat is the last one is
> > designed to get error/completion reports from the kernel J1939 stack.
> 
> Indeed, with j1939cat, I have now an error, but it takes a long time to close the socket. It seems to be because recvmsg is called after the last message (so j1939 queue contains a lot of messages) and not after each message send.
> So, is it recommended to use j1939cat mechanism (with errqueue)  to send j1939 broadcast messages ?

If you need any kind of feedback from the stack, you'll need to use err
queue.
To deal with the big queue of message which can't be send, we need to
extend can frame work with ability to kill pending packets on request.
Currently it is not supported, but it is nice to have.

Regards,
Oleksij
-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |