RFC: can-j1939

RFC: can-j1939

[Kurt Van Dijck]

Hey,

Last November, we had some discussion on how to improve the can-j1939
API in order to suit more users.
I had some delays for finding stupid bugs (@Laurent, I backporte to an iMX6
with v3.10 kernel with can-j1939 for finding some of them), now it's
ready to share.

I had assembled a quick starter guide long time ago already in markdown.
I didn't feel like translating it to elinux.org's mediawiki, so I put it
https://github.com/kurt-vd/test-can-j1939/blob/master/can-j1939-kickstart.md

During my development, I tested can-j1939 on 3 linux kernel versions:
v3.10, v3.15 and v4.3. I later found that the small changes for v4.3
actually were introduced in v4.1, so I backported j1939d-v4.3 to
j1939d-v4.1.

On https://github.com/kurt-vd/linux, you will find 4 additional
branches: j1939d-v3.10, j1939d-v3.15, ...
The 'd' suffix as distinction, means 'direct', however that is less important.

I will in short highlight some aspects of the new stack, most of which
were raised in past discussions on this list:

* it is stable, works with the latest kernels.
* does not need or use netlink. You don't need a modified iproute2 anymore
* when a can-j1939 socket binds to an interface, can-j1939 starts
  processing on this interface: address claim tracking + transport
  protocol assembly.
  when the last such socket closes, can-j1939 stops for that interface.
  This also means that a transport protocol session that _started_ before
  the first socket opens will not be seen by can-j1939. This conforms to
  datagram communication.
* when a socket binds to an address or name, the kernel starts treating
  that address/name as a local one.
* The new stack takes less measures to detect address collisions
  for static addresses, and keeps more responsibility to the user.
* non-root users can start can-j1939 on an interface, add addresses, ...
* a list of current local addresses is available in /proc
* add transport protocol parameter, to control outgoing inter-packet delays.
* add parameter to pad all packets to 8 bytes.

I hope you will find time to take a look at it.
We could possibly agree on the API?

Kind regards,
Kurt

Re: RFC: can-j1939

[Yang Wang]

On Mon, Feb 22, 2016 at 12:22 AM, Kurt Van Dijck
<dev.kurt@vandijck-laurijssen.be> wrote:

> * it is stable, works with the latest kernels.
> * does not need or use netlink. You don't need a modified iproute2 anymore
> * when a can-j1939 socket binds to an interface, can-j1939 starts
>   processing on this interface: address claim tracking + transport
>   protocol assembly.
>   when the last such socket closes, can-j1939 stops for that interface.
>   This also means that a transport protocol session that _started_ before
>   the first socket opens will not be seen by can-j1939. This conforms to
>   datagram communication.
> * when a socket binds to an address or name, the kernel starts treating
>   that address/name as a local one.
> * The new stack takes less measures to detect address collisions
>   for static addresses, and keeps more responsibility to the user.
> * non-root users can start can-j1939 on an interface, add addresses, ...
> * a list of current local addresses is available in /proc
> * add transport protocol parameter, to control outgoing inter-packet delays.
> * add parameter to pad all packets to 8 bytes.

Kurt,

It looks great. Dropping the usage of iproute2 simplifies a lot of
things for me. I'll test the v3.15 branch since I've been using it.

Thank you for the work.

Regards,
Yang

RE: RFC can-j1939

[R U Local]

Dear Kurt,
Thanks for your great work.
I'm just bringing up the J1939 stack on a TI OMAP4 based system.
I'm locked to a custom kernel 3.19 due to media drivers and codecs.
I followed your guide and pulled code from 4.1 and 3.15 branches.
I also patched and built can-utils and iproute2.
I can't get the Transport Protocol to work send only sends the first packet and receive hangs on reception of the first packet.

It may be that mixing iproute2 and mixing branches has broken the TP.
Which branch should I use as a reference? I'll re-patch and re-test with unpatched iproute2.

As far as your RFC your implementation looks to be ideal for our applications.
For user space applications where should the headers (<linux/can/can.h> & <linux/can/j1939/j1939.h>) be taken from or provided by?

Cheers Mike.

-----Original Message-----
From: linux-can-owner@vger.kernel.org [mailto:linux-can-owner@vger.kernel.org] On Behalf Of Kurt Van Dijck
Sent: Monday, 22 February 2016 18:23
To: Yang Wang <wang701@purdue.edu>; Alex Layton <alex@layton.in>; David Jander <david@protonic.nl>; laurent vaudoit <laurent.vaudoit@gmail.com>; Oliver Hartkopp <socketcan@hartkopp.net>
Cc: linux-can <linux-can@vger.kernel.org>
Subject: RFC: can-j1939

Hey,

Last November, we had some discussion on how to improve the can-j1939 API in order to suit more users.
I had some delays for finding stupid bugs (@Laurent, I backporte to an iMX6 with v3.10 kernel with can-j1939 for finding some of them), now it's ready to share.

I had assembled a quick starter guide long time ago already in markdown.
I didn't feel like translating it to elinux.org's mediawiki, so I put it https://github.com/kurt-vd/test-can-j1939/blob/master/can-j1939-kickstart.md

During my development, I tested can-j1939 on 3 linux kernel versions:
v3.10, v3.15 and v4.3. I later found that the small changes for v4.3 actually were introduced in v4.1, so I backported j1939d-v4.3 to j1939d-v4.1.

On https://github.com/kurt-vd/linux, you will find 4 additional
branches: j1939d-v3.10, j1939d-v3.15, ...
The 'd' suffix as distinction, means 'direct', however that is less important.

I will in short highlight some aspects of the new stack, most of which were raised in past discussions on this list:

* it is stable, works with the latest kernels.
* does not need or use netlink. You don't need a modified iproute2 anymore
* when a can-j1939 socket binds to an interface, can-j1939 starts
  processing on this interface: address claim tracking + transport
  protocol assembly.
  when the last such socket closes, can-j1939 stops for that interface.
  This also means that a transport protocol session that _started_ before
  the first socket opens will not be seen by can-j1939. This conforms to
  datagram communication.
* when a socket binds to an address or name, the kernel starts treating
  that address/name as a local one.
* The new stack takes less measures to detect address collisions
  for static addresses, and keeps more responsibility to the user.
* non-root users can start can-j1939 on an interface, add addresses, ...
* a list of current local addresses is available in /proc
* add transport protocol parameter, to control outgoing inter-packet delays.
* add parameter to pad all packets to 8 bytes.

I hope you will find time to take a look at it.
We could possibly agree on the API?

Kind regards,
Kurt
--
To unsubscribe from this list: send the line "unsubscribe linux-can" in the body of a message to majordomo@vger.kernel.org More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RFC can-j1939

[Kurt Van Dijck]

> 
> Dear Kurt,
> Thanks for your great work.
> I'm just bringing up the J1939 stack on a TI OMAP4 based system.
> I'm locked to a custom kernel 3.19 due to media drivers and codecs.
> I followed your guide and pulled code from 4.1 and 3.15 branches.

I guessed you just merge the j1939d-3.15 branch, noth the 4.1.

> I also patched and built can-utils and iproute2.

iproute2 must not be patched anymore.

> I can't get the Transport Protocol to work send only sends the first packet and receive hangs on reception of the first packet.

I walked through my quick starter guide and i realised I had not updated
it for dealing with the j1939 socket closing before the transport
protocol is ready.

I just now updated my quick start guide. Can you try that, and tell
where exactly it goes wrong in your opinion.

> As far as your RFC your implementation looks to be ideal for our applications.
> For user space applications where should the headers (<linux/can/can.h> & <linux/can/j1939/j1939.h>) be taken from or provided by?

Ideally, this becomes mainline and then you will sooner or later find
the header in linux/can/j1939.h. Up to then, you will need to fix your
toolchain manually by copying j1939.h there yourself.
Do not forget that linux/can.h needs patching too.

Kurt

RE: RFC can-j1939

[R U Local]

>> 
>> Dear Kurt,
>> Thanks for your great work.
>> I'm just bringing up the J1939 stack on a TI OMAP4 based system.
>> I'm locked to a custom kernel 3.19 due to media drivers and codecs.
>> I followed your guide and pulled code from 4.1 and 3.15 branches.

> I guessed you just merge the j1939d-3.15 branch, noth the 4.1.
Modified files in my kernel are now the same as your j1939d-v3.15 branch but using memcpy_{from,to}_msg API.

>> I also patched and built can-utils and iproute2.

> iproute2 must not be patched anymore.
Back to standard iproute2

>> I can't get the Transport Protocol to work send only sends the first packet and receive hangs on reception of the first packet.

> I walked through my quick starter guide and i realised I had not updated it for dealing with the j1939 socket closing before the transport protocol is ready.

> I just now updated my quick start guide. Can you try that, and tell where exactly it goes wrong in your opinion.
Thanks for the update/information.
My test unit has two interfaces (can0 & can1) which I have connected to the same bus. I have two terminals in separate sessions one for sending and one for receiving.
testj1939  -w1.0 -s20 can0:0x80 :,0x12300 now emits all frames when using as seen with 'candump can1'.
testj1939 can1 -r shows no response from the above command.
testj1939 -w1.0 -s can0:0x80 :0x90,0x12300 only emits the first frame as seen with 'candump can1'.
testj1939  can1:0x90 -r outputs the first frame (80 12300: 01 23 45 67 89 ab cd ef) when the above is issued

I've rebuilt the kernel with CAN_J1939_DEBUG configured but don’t have any additional messages.
I'll look a bit deeper tomorrow, any suggestions or hints would be welcomed.

>> As far as your RFC your implementation looks to be ideal for our applications.
>> For user space applications where should the headers (<linux/can/can.h> & <linux/can/j1939/j1939.h>) be taken from or provided by?

> Ideally, this becomes mainline and then you will sooner or later find the header in linux/can/j1939.h. Up to then, you will need to fix your toolchain manually by copying j1939.h there yourself.
That’s what I was thinking, I've updated my toolchain in the meantime.
> Do not forget that linux/can.h needs patching too.
That’s done.

> Kurt
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-can" in the body of a message to majordomo@vger.kernel.org More majordomo info at  http://vger.kernel.org/majordomo-info.html