Re: [PATCH] Fix J1939 implementation not handling holds correctly

[Alexander Hölzl]

Hi thank you for your review!
I've sent another patch addressing all the points related to the first 
version of the patch.

On 5/6/26 15:21, Oleksij Rempel wrote:
> On Tue, May 05, 2026 at 12:18:33AM +0200, Alexander Hölzl wrote:
> > The J1939 protocol allows the receiver of directed segemented messages
> > to hold the data transfer. The kernel implementation did not handle hold
> > messages correctly was not able to resume from a hold.
> > Additionally the incorrect timeout for a held open connection was
> > changed to 1050ms.
> > Some simple tests for the general protocol behavior have been added.
> >
> > This is just an initial draft I'm just looking for some feedback
> > if the general setup is acceptable.
> >
> > Also I still have some points I'm not sure about.
> > 1. There is no check for the reception of a CTS during an ongoing data
> >     transfer. According to the standard it is illegal, but I dont think
> >     the implementation cares about it. J1939_XTP_ABORT_GENERIC is never
> >     referenced and the previous check I removed only really prevented
> >     consecutive CTS which are legal if they are holds. Should I add a
> >     check for this? This seems to be a slightly different problem so I
> >     did not address it.
>
> Current I do not have opinion about this. As long as it is in a separate
> patch with enough explanation and tests - I'm OK.
Ok, I'll think about it and send a patch.>
> > 2. Should userspace be notified about holds? I don't think the standard
> >     gives a maximum 'hold open time' so in theory it could be held
> >     indefinetly. This might be a situation a user could be intrested in
> >     even though it is rather theoretical.
>
> Yes, it will be good to have a user space feedback. But, it would block
> resources. Will we get difference scenarios where we still have an open
> session which is blocking other transfers?
Hm I'm not quite sure if I understand your question, but a J1939 session 
is identified by source and destination address. A hold is only relevant 
for a single unicast session, so receiving hols will only block this 
specific session. As the kernel will never send holds itself this is 
only relevant for tx-sessions. So the only thing which could happen, is 
that a receiver prevents a unicast tx-session from completing by sending 
nonstop holds.
This should not impact other sessions but it will prevent this specific 
session from completing and therefore restarting another tx RTS/CTS 
session to the same destination.

The other points I addressed in the v2 patch.

...

> Best Regards,
> Oleksij

Best Regards and have a nice weekend!

Alexander