J1939 v6 (#7)

You can view, comment on, or merge this pull request online at:

https://github.com/linux-can/can-utils/pull/7

Commit Summary

* can-j1939: add libj1939.a
* can-j1939: add jspy 'sniffer' program
* can-j1939: add jsr program
* can-j1939: update headers with j1939
* can-j1939: add jacd address claim daemon

Hello Mikey and Kurt,

Quoted 5 lines · On 09/24/2015 09:33 PM, mikey32905 wrote:

You can view, comment on, or merge this pull request online at:

https://github.com/linux-can/can-utils/pull/7

Quoted 7 lines

Commit Summary

* can-j1939: add libj1939.a
* can-j1939: add jspy 'sniffer' program
* can-j1939: add jsr program
* can-j1939: update headers with j1939
* can-j1939: add jacd address claim daemon

Kurt, I got this pull request of the j1939 tools from Mikey. What's the status of the j1939, can we add it to the can-utils? Is the userspace API stable?

Marc

Signature · 4 lines

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

Hi Kurt,

I'm sorry but I still think that your implementation and configuration is way to complex and not intuitive.
If you look at http://elinux.org/J1939

$ modprobe can-j1939
$ ip link set can0 j1939 on
still looks weird. Adding addresses to CAN interfaces is not common -
and if you think about this kind of assignment, it should be implemented
inside the j1939 stuff and not in af_can.c. The can-gw routing netlink
API was integrated in gw.c too. IMO the sockaddr_can extension would be
ok - but the other implementation should be made without af_can.[ch]
changes.

I remember our discussion about the address claiming but I wonder if we really follow the requirement to only put functionality into the kernel that really has to be implemented there.

Did you take a look at https://github.com/ISOBlue/isoblue-software - which is far simpler - whether it can fulfill the basic functionalities (segmentation, etc.) to enable j1939 for Linux?

Can we switch to the mailinglist for the discussion.

Quoted 4 lines

Hi Kurt,

I'm sorry but I still think that your implementation and configuration is way to complex and not intuitive.

Quoted 3 lines

If you look at http://elinux.org/J1939

$ modprobe can-j1939

Quoted 1 line

$ ip link set can0 j1939 on

Quoted 1 line

still looks weird. Adding addresses to CAN interfaces is not common -

Quoted 2 lines

and if you think about this kind of assignment, it should be implemented inside the j1939 stuff and not in af_can.c. The can-gw routing netlink

Quoted 3 lines

API was integrated in gw.c too. IMO the sockaddr_can extension would be ok - but the other implementation should be made without af_can.[ch] changes.

Quoted 4 lines

I remember our discussion about the address claiming but I wonder if we really follow the requirement to only put functionality into the kernel that really has to be implemented there.

Quoted 4 lines

Did you take a look at https://github.com/ISOBlue/isoblue-software - which is far simpler - whether it can fulfill the basic functionalities (segmentation, etc.) to enable j1939 for Linux?

I would like to challenge other j1939 (not necessarily socketcan+can-j1939) users to share their opinions.

Quoted 3 lines

Quoted 3 lines

If you look at http://elinux.org/J1939

$ modprobe can-j1939

This is a systemwide action, as opposed to

Quoted 1 line

Quoted 1 line

$ ip link set can0 j1939 on

which is an interface-wide action.

Due to the nature of CAN, the kernel should not/cannot decide if CAN traffic is J1939 or not.
Unlike other CAN protocols (RAW, BCM, ISOTP), J1939 allocates the whole CAN id range for its use, and using CAN ids incompatible with j1939 is regarded illegal.

So this must become a switch.

The modprobe is necessary for the same reason that the sequence

$ modprobe vcan
$ ip link add vcan0 type vcan

requires a modprobe too.
I do see the weirdness of it, although this is not new.

The lack of extensive userbase made all arguments void.
In between, the userbase may have grown?
Given that the pull request is coming from Mikey, the need is growing and this may be a proper time to decide on this

Any decision implies that some porting to 4.2 kernel needs to be done anyway. The latest patches I have for 3.15 are not stable yet. j1939 is stable up to 3.12 only.

Date: Wed, 30 Sep 2015 15:26:40 +0000 (UTC)
From: Aaron Clarke <[email protected]>
To: [email protected]
Subject: Re: [can-utils] J1939 v6 (#7)
User-Agent: Loom/3.14 (http://gmane.org/)

Quoted 4 lines · Kurt Van Dijck <dev.kurt <at> vandijck-laurijssen.be> writes:

The lack of extensive userbase made all arguments void.
In between, the userbase may have grown?
Given that the pull request is coming from Mikey, the need is growing and this may be a proper time to decide on this

I am working on a j1939 project that could use this and appreciate any development. We need a stable solution as soon as possible.

Quoted 3 lines

Any decision implies that some porting to 4.2 kernel needs to be done anyway. The latest patches I have for 3.15 are not stable yet. j1939 is stable up to 3.12 only.

I ported the 3.15 branch to a 4.1 kernel (patched for beaglebone black) but it crashes on multi-packet sends. Is this a know issue with the 3.15 branch? In any case, I will try the 3.12 kernel branch instead if that is more stable.

I would like to challenge other j1939 (not necessarily socketcan+can-j1939) users to share their opinions.

Quoted 3 lines

Quoted 3 lines

If you look at http://elinux.org/J1939

$ modprobe can-j1939

This is a systemwide action, as opposed to

Quoted 1 line

Quoted 1 line

$ ip link set can0 j1939 on

which is an interface-wide action.

Due to the nature of CAN, the kernel should not/cannot decide if CAN traffic is J1939 or not.
Unlike other CAN protocols (RAW, BCM, ISOTP), J1939 allocates the whole CAN id range for its use, and using CAN ids incompatible with j1939 is regarded illegal.

So this must become a switch.

Quoted 2 lines

Quoted 2 lines

and if you think about this kind of assignment, it should be implemented inside the j1939 stuff and not in af_can.c. The can-gw routing netlink

j1939 touches af_can because address configuration via netlink is absent in af_can. j1939 adds (with seperate patches) the ability to add addressess for CAN sockets, but only for those CAN protocols that support it.
I see no decent way to bypass af_can, except for creating af_j1939.

Quoted 3 lines

Quoted 3 lines

I remember our discussion about the address claiming but I wonder if we really follow the requirement to only put functionality into the kernel that really has to be implemented there.

The kernel tracks and validates J1939 traffic. Any userspace application can track, but none can validate & reject without duplicating effort.

Quoted 3 lines

Quoted 3 lines

Did you take a look at https://github.com/ISOBlue/isoblue-software - which is far simpler - whether it can fulfill the basic functionalities (segmentation, etc.) to enable j1939 for Linux?

I took a quick look. It appears that they only put the address claiming in the kernel. I understand that this is exactly your concern in my implementation :-).

Quoted 2 lines · Kurt Van Dijck

I would like to challenge other j1939 (not necessarily socketcan+can-j1939) users to share their opinions.

Hello, I am the author of https://github.com/ISOBlue/isoblue-software,
finally getting around to participating in this list.

Quoted 10 lines

Quoted 3 lines

Quoted 3 lines

If you look at http://elinux.org/J1939

$ modprobe can-j1939

This is a systemwide action, as opposed to

Quoted 1 line

Quoted 1 line

$ ip link set can0 j1939 on

which is an interface-wide action.

Quoted 7 lines

Due to the nature of CAN, the kernel should not/cannot decide if CAN traffic is J1939 or not.
Unlike other CAN protocols (RAW, BCM, ISOTP), J1939 allocates the whole CAN id range for its use, and using CAN ids incompatible with j1939 is regarded illegal.

So this must become a switch.

I disagree with this, like Austin Schuh did. In my experience there is almost always other non-J1939 CAN traffic present and it must be possible to use both. The module should just ignore any CAN that does not look right to it, and there needs to still be a way to get at the other CAN on the bus through a CAN_RAW socket or something.

Quoted 8 lines

Quoted 2 lines

Quoted 2 lines

and if you think about this kind of assignment, it should be implemented inside the j1939 stuff and not in af_can.c. The can-gw routing netlink

j1939 touches af_can because address configuration via netlink is absent in af_can. j1939 adds (with seperate patches) the ability to add addressess for CAN sockets, but only for those CAN protocols that support it.
I see no decent way to bypass af_can, except for creating af_j1939.

Sorry if this is a stupid question, but what is the point of adding addresses to a CAN interface with ip? Doesn't the code creating the socket set what its address and/or NAME is? My implementation does not modify af_can, though it is admittedly much more simplistic than Kurt's.

Quoted 6 lines

Quoted 3 lines

Quoted 3 lines

I remember our discussion about the address claiming but I wonder if we really follow the requirement to only put functionality into the kernel that really has to be implemented there.

The kernel tracks and validates J1939 traffic. Any userspace application can track, but none can validate & reject without duplicating effort.

I too think at least part of the address handling needs to be in the kernel module.

Quoted 7 lines

Quoted 3 lines

Quoted 3 lines

Did you take a look at https://github.com/ISOBlue/isoblue-software - which is far simpler - whether it can fulfill the basic functionalities (segmentation, etc.) to enable j1939 for Linux?

I took a quick look. It appears that they only put the address claiming in the kernel. I understand that this is exactly your concern in my implementation :-).

Yes, my implementation does address claiming in the module. From what I understand, mine does even more of the process than Kurt's does (my module actually sends the address claim messages). However, my module does not deal with NAMEs, only the addresses.

Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-can" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Date: Thu, 15 Oct 2015 18:04:58 -0400
From: Alex Layton <[email protected]>
To: linux-can <[email protected]>
Subject: Re: can-j1939 API

Quoted 2 lines · Kurt Van Dijck

I would like to challenge other j1939 (not necessarily socketcan+can-j1939) users to share their opinions.

Hello, I am the author of https://github.com/ISOBlue/isoblue-software,
finally getting around to participating in this list.

Quoted 16 lines

Quoted 3 lines

Quoted 3 lines

If you look at http://elinux.org/J1939

$ modprobe can-j1939

This is a systemwide action, as opposed to

Quoted 1 line

Quoted 1 line

$ ip link set can0 j1939 on

which is an interface-wide action.

Due to the nature of CAN, the kernel should not/cannot decide if CAN traffic is J1939 or not.
Unlike other CAN protocols (RAW, BCM, ISOTP), J1939 allocates the whole CAN id range for its use, and using CAN ids incompatible with j1939 is regarded illegal.

Quoted 1 line

So this must become a switch.

I disagree with this, like Austin Schuh did. In my experience there is almost always other non-J1939 CAN traffic present and it must be possible to use both. The module should just ignore any CAN that does not look right to it, and there needs to still be a way to get at the other CAN on the bus through a CAN_RAW socket or something.

Quoted 9 lines

Quoted 3 lines

Quoted 3 lines

and if you think about this kind of assignment, it should be implemented inside the j1939 stuff and not in af_can.c. The can-gw routing netlink

j1939 touches af_can because address configuration via netlink is absent in af_can. j1939 adds (with seperate patches) the ability to add addressess for CAN sockets, but only for those CAN protocols that support it.
I see no decent way to bypass af_can, except for creating af_j1939.

Sorry if this is a stupid question, but what is the point of adding addresses to a CAN interface with ip? Doesn't the code creating the socket set what its address and/or NAME is? My implementation does not modify af_can, though it is admittedly much more simplistic than Kurt's.

Quoted 7 lines

Quoted 4 lines

Quoted 4 lines

I remember our discussion about the address claiming but I wonder if we really follow the requirement to only put functionality into the kernel that really has to be implemented there.

The kernel tracks and validates J1939 traffic. Any userspace application can track, but none can validate & reject without duplicating effort.

I too think at least part of the address handling needs to be in the kernel module.

Quoted 4 lines

Quoted 3 lines

Quoted 3 lines

Did you take a look at https://github.com/ISOBlue/isoblue-software - which is far simpler - whether it can fulfill the basic functionalities (segmentation, etc.) to enable j1939 for Linux?

Quoted 3 lines

I took a quick look. It appears that they only put the address claiming in the kernel. I understand that this is exactly your concern in my implementation :-).

Yes, my implementation does address claiming in the module. From what I understand, mine does even more of the process than Kurt's does (my module actually sends the address claim messages). However, my module does not deal with NAMEs, only the addresses.

Date: Fri, 16 Oct 2015 21:36:52 +0200
From: Patrick Menschel <[email protected]>
To: linux-can <[email protected]>
Subject: Re: can-j1939 API
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
Thunderbird/38.3.0

Hi,

1. concerning J1939, I think it would be best to implement it is a "view" on can0 without changing can0 itself.

As it's already been mentioned, j1939 may share the physical layer with other protocols, i.e. CanOpen on diesel powered railway equipment or proprietary protocols of some OEMs for construction machinery. If there is tester or application equipment installed, CCP is usually also present.

2. concerning address claiming and address collision handling via the NAME property, I think it should be handled in user space, not within the module as you may have multiple source addresses on the same device. For example Engine ECU SA 0x00 and Emission Controller SA 0x3D usually are one and the same physical device.

Regards,
Patrick

Am 16.10.2015 um 00:04 schrieb Alex Layton:

Quoted 77 lines

Quoted 2 lines · Kurt Van Dijck

I would like to challenge other j1939 (not necessarily socketcan+can-j1939) users to share their opinions.

Hello, I am the author of https://github.com/ISOBlue/isoblue-software,
finally getting around to participating in this list.

Quoted 10 lines

Quoted 3 lines

Quoted 3 lines

If you look at http://elinux.org/J1939

$ modprobe can-j1939

This is a systemwide action, as opposed to

Quoted 1 line

Quoted 1 line

$ ip link set can0 j1939 on

which is an interface-wide action.

Quoted 7 lines

Due to the nature of CAN, the kernel should not/cannot decide if CAN traffic is J1939 or not.
Unlike other CAN protocols (RAW, BCM, ISOTP), J1939 allocates the whole CAN id range for its use, and using CAN ids incompatible with j1939 is regarded illegal.

So this must become a switch.

I disagree with this, like Austin Schuh did. In my experience there is almost always other non-J1939 CAN traffic present and it must be possible to use both. The module should just ignore any CAN that does not look right to it, and there needs to still be a way to get at the other CAN on the bus through a CAN_RAW socket or something.

Quoted 8 lines

Quoted 2 lines

Quoted 2 lines

and if you think about this kind of assignment, it should be implemented inside the j1939 stuff and not in af_can.c. The can-gw routing netlink

j1939 touches af_can because address configuration via netlink is absent in af_can. j1939 adds (with seperate patches) the ability to add addressess for CAN sockets, but only for those CAN protocols that support it.
I see no decent way to bypass af_can, except for creating af_j1939.

Sorry if this is a stupid question, but what is the point of adding addresses to a CAN interface with ip? Doesn't the code creating the socket set what its address and/or NAME is? My implementation does not modify af_can, though it is admittedly much more simplistic than Kurt's.

Quoted 6 lines

Quoted 3 lines

Quoted 3 lines

I remember our discussion about the address claiming but I wonder if we really follow the requirement to only put functionality into the kernel that really has to be implemented there.

The kernel tracks and validates J1939 traffic. Any userspace application can track, but none can validate & reject without duplicating effort.

I too think at least part of the address handling needs to be in the kernel module.

Quoted 7 lines

Quoted 3 lines

Quoted 3 lines

Did you take a look at https://github.com/ISOBlue/isoblue-software - which is far simpler - whether it can fulfill the basic functionalities (segmentation, etc.) to enable j1939 for Linux?

I took a quick look. It appears that they only put the address claiming in the kernel. I understand that this is exactly your concern in my implementation :-).

Yes, my implementation does address claiming in the module. From what I understand, mine does even more of the process than Kurt's does (my module actually sends the address claim messages). However, my module does not deal with NAMEs, only the addresses.

Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-can" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

--- Original message ---

Quoted 7 lines

Date: Fri, 16 Oct 2015 21:36:52 +0200
From: Patrick Menschel <[email protected]>
To: linux-can <[email protected]>
Subject: Re: can-j1939 API
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
Thunderbird/38.3.0

Quoted 4 lines

Hi,

1. concerning J1939, I think it would be best to implement it is a "view" on can0 without changing can0 itself.

What exactly do you mean with 'view'?

Quoted 5 lines

As it's already been mentioned, j1939 may share the physical layer with other protocols, i.e. CanOpen on diesel powered railway equipment or proprietary protocols of some OEMs for construction machinery. If there is tester or application equipment installed, CCP is usually also present.

Thanks for the example.
IMHO, CanOpen uses only 11bit CANids, so theres no collision in the CAN id space. Does anyone ever encountered CAN protrocols that have collisions in the CANid space with can-j1939?

Quoted 6 lines

2. concerning address claiming and address collision handling via the NAME property, I think it should be handled in user space, not within the module as you may have multiple source addresses on the same device. For example Engine ECU SA 0x00 and Emission Controller SA 0x3D usually are one and the same physical device.

I think I partly share your conclusion,
I do not understand how multiple addresses on an ECU are an argument for handling address claiming in userspace.

Quoted 3 lines

Regards,
Patrick

Kind regards,
Kurt

Quoted 82 lines

Am 16.10.2015 um 00:04 schrieb Alex Layton:

Quoted 77 lines

Quoted 2 lines · Kurt Van Dijck

I would like to challenge other j1939 (not necessarily socketcan+can-j1939) users to share their opinions.

Hello, I am the author of https://github.com/ISOBlue/isoblue-software,
finally getting around to participating in this list.

Quoted 10 lines

Quoted 3 lines

Quoted 3 lines

If you look at http://elinux.org/J1939

$ modprobe can-j1939

This is a systemwide action, as opposed to

Quoted 1 line

Quoted 1 line

$ ip link set can0 j1939 on

which is an interface-wide action.

Quoted 7 lines

Due to the nature of CAN, the kernel should not/cannot decide if CAN traffic is J1939 or not.
Unlike other CAN protocols (RAW, BCM, ISOTP), J1939 allocates the whole CAN id range for its use, and using CAN ids incompatible with j1939 is regarded illegal.

So this must become a switch.

I disagree with this, like Austin Schuh did. In my experience there is almost always other non-J1939 CAN traffic present and it must be possible to use both. The module should just ignore any CAN that does not look right to it, and there needs to still be a way to get at the other CAN on the bus through a CAN_RAW socket or something.

Quoted 8 lines

Quoted 2 lines

Quoted 2 lines

and if you think about this kind of assignment, it should be implemented inside the j1939 stuff and not in af_can.c. The can-gw routing netlink

j1939 touches af_can because address configuration via netlink is absent in af_can. j1939 adds (with seperate patches) the ability to add addressess for CAN sockets, but only for those CAN protocols that support it.
I see no decent way to bypass af_can, except for creating af_j1939.

Sorry if this is a stupid question, but what is the point of adding addresses to a CAN interface with ip? Doesn't the code creating the socket set what its address and/or NAME is? My implementation does not modify af_can, though it is admittedly much more simplistic than Kurt's.

Quoted 6 lines

Quoted 3 lines

Quoted 3 lines

I remember our discussion about the address claiming but I wonder if we really follow the requirement to only put functionality into the kernel that really has to be implemented there.

The kernel tracks and validates J1939 traffic. Any userspace application can track, but none can validate & reject without duplicating effort.

I too think at least part of the address handling needs to be in the kernel module.

Quoted 7 lines

Quoted 3 lines

Quoted 3 lines

Did you take a look at https://github.com/ISOBlue/isoblue-software - which is far simpler - whether it can fulfill the basic functionalities (segmentation, etc.) to enable j1939 for Linux?

I took a quick look. It appears that they only put the address claiming in the kernel. I understand that this is exactly your concern in my implementation :-).

Yes, my implementation does address claiming in the module. From what I understand, mine does even more of the process than Kurt's does (my module actually sends the address claim messages). However, my module does not deal with NAMEs, only the addresses.

Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-can" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-can" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Am 18.10.2015 um 04:42 schrieb Kurt Van Dijck:

Quoted 4 lines

Quoted 3 lines

1. concerning J1939, I think it would be best to implement it is a "view" on can0 without changing can0 itself.

Quoted 2 lines

What exactly do you mean with 'view'?

Basically leave the can0 functionality as it is and add another interface such as J1939_0 or whatever. That way other applications may still use normal can0. But maybe I just misunderstood your concept, sorry if that's the case.

Quoted 18 lines

Quoted 5 lines

As it's already been mentioned, j1939 may share the physical layer with other protocols, i.e. CanOpen on diesel powered railway equipment or proprietary protocols of some OEMs for construction machinery. If there is tester or application equipment installed, CCP is usually also present.

Thanks for the example.
IMHO, CanOpen uses only 11bit CANids, so theres no collision in the CAN id space. Does anyone ever encountered CAN protrocols that have collisions in the CANid space with can-j1939?

Quoted 6 lines

2. concerning address claiming and address collision handling via the NAME property, I think it should be handled in user space, not within the module as you may have multiple source addresses on the same device. For example Engine ECU SA 0x00 and Emission Controller SA 0x3D usually are one and the same physical device.

Quoted 4 lines

I think I partly share your conclusion,
I do not understand how multiple addresses on an ECU are an argument for handling address claiming in userspace.

If the device running socketcan+j1939 can only have one SA, it would not allow such multi-role implementations.

Date: Mon, 19 Oct 2015 08:07:31 +0200
From: Oliver Hartkopp <[email protected]>
To: Patrick Menschel <[email protected]>, linux-can
<[email protected]>, Alex Layton <[email protected]>, Kurt Van Dijck <[email protected]>
Subject: Re: can-j1939 API
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101
Icedove/31.8.0

Hi all,

Quoted 12 lines · Patrick Menschel

Am 18.10.2015 um 04:42 schrieb Kurt Van Dijck:

Quoted 6 lines

Quoted 3 lines

1. concerning J1939, I think it would be best to implement it is a "view" on can0 without changing can0 itself.

What exactly do you mean with 'view'?

Basically leave the can0 functionality as it is and add another interface such as J1939_0 or whatever. That way other applications may still use normal can0. But maybe I just misunderstood your concept, sorry if that's the case.

I also have problems to understand the concept for a while now.

Quoted 24 lines

Quoted 18 lines

Quoted 5 lines

As it's already been mentioned, j1939 may share the physical layer with other protocols, i.e. CanOpen on diesel powered railway equipment or proprietary protocols of some OEMs for construction machinery. If there is tester or application equipment installed, CCP is usually also present.

Thanks for the example.
IMHO, CanOpen uses only 11bit CANids, so theres no collision in the CAN id space. Does anyone ever encountered CAN protrocols that have collisions in the CANid space with can-j1939?

Quoted 6 lines

2. concerning address claiming and address collision handling via the NAME property, I think it should be handled in user space, not within the module as you may have multiple source addresses on the same device. For example Engine ECU SA 0x00 and Emission Controller SA 0x3D usually are one and the same physical device.

Quoted 4 lines

I think I partly share your conclusion,
I do not understand how multiple addresses on an ECU are an argument for handling address claiming in userspace.

If the device running socketcan+j1939 can only have one SA, it would not allow such multi-role implementations.

I would definitely demand multi-role implementations as this is one of the main SocketCAN goals to have the entire networking setup running on one host or on different hosts without changing the application.

See:

https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/Documentation/networking/can.txt?h=linux-4.2.y#n185

If I understood the concepts correctly:

Kurts implementation:
- grabs the entire interface (the entire Linux box?!)

- binds node addresses to the interface (Linux box?!)
- socket addressing matches the function

Alexs implementation:
- socket addressing matches the node address

Both implement address claiming (AC) in Kernel space - which would only fit

the SocketCAN idea of multi-role implementations, when the AC is per-socket in Alexs concept.

We should try to move as much functionality as possible out of the kernel.

When address claiming makes sense there it should stay there.

IMO Alexs concept is not only much smaller in code size ...

--- Original message ---

Quoted 29 lines

Date: Thu, 15 Oct 2015 18:04:58 -0400
From: Alex Layton <[email protected]>
To: linux-can <[email protected]>
Subject: Re: can-j1939 API

Quoted 2 lines · Kurt Van Dijck

I would like to challenge other j1939 (not necessarily socketcan+can-j1939) users to share their opinions.

Hello, I am the author of https://github.com/ISOBlue/isoblue-software,
finally getting around to participating in this list.

Quoted 16 lines

Quoted 3 lines

Quoted 3 lines

If you look at http://elinux.org/J1939

$ modprobe can-j1939

This is a systemwide action, as opposed to

Quoted 1 line

Quoted 1 line

$ ip link set can0 j1939 on

which is an interface-wide action.

Due to the nature of CAN, the kernel should not/cannot decide if CAN traffic is J1939 or not.
Unlike other CAN protocols (RAW, BCM, ISOTP), J1939 allocates the whole CAN id range for its use, and using CAN ids incompatible with j1939 is regarded illegal.

Quoted 7 lines

Quoted 1 line

So this must become a switch.

I disagree with this, like Austin Schuh did. In my experience there is almost always other non-J1939 CAN traffic present and it must be possible to use both. The module should just ignore any CAN that does not look right to it, and there needs to still be a way to get at the other CAN on the bus through a CAN_RAW socket or something.

The 'switch' is to turn can-j1939 on/off on a specific interface. The condition that I'd like to solve is where you end up having a j1939 bus can0, obviously with 29bit CAN id's, and another bus, can1, that is NOT j1939 compliant while using 29bit identifiers.

I'd prefer to disable can-j1939 processing on can1 in that case, before reporting any obvious protocol violations in the log.

Quoted 9 lines

Quoted 8 lines

Quoted 2 lines

Quoted 2 lines

and if you think about this kind of assignment, it should be implemented inside the j1939 stuff and not in af_can.c. The can-gw routing netlink

j1939 touches af_can because address configuration via netlink is absent in af_can. j1939 adds (with seperate patches) the ability to add addressess for CAN sockets, but only for those CAN protocols that support it.
I see no decent way to bypass af_can, except for creating af_j1939.

Quoted 5 lines

Sorry if this is a stupid question, but what is the point of adding addresses to a CAN interface with ip? Doesn't the code creating the socket set what its address and/or NAME is? My implementation does not modify af_can, though it is admittedly much more simplistic than Kurt's.

I offloaded the (static) addressing onto the kernel, so I needs to know its address, much like any other address-capable protocol like e.g. ipv4. Its obviously that not every ipv4 capable application needs to know it local ip address. I made can-j1939 likewise multi-user ready.

Quoted 14 lines

Quoted 6 lines

Quoted 3 lines

Quoted 3 lines

I remember our discussion about the address claiming but I wonder if we really follow the requirement to only put functionality into the kernel that really has to be implemented there.

The kernel tracks and validates J1939 traffic. Any userspace application can track, but none can validate & reject without duplicating effort.

I too think at least part of the address handling needs to be in the kernel module.

Quoted 4 lines

Quoted 3 lines

Quoted 3 lines

Did you take a look at https://github.com/ISOBlue/isoblue-software - which is far simpler - whether it can fulfill the basic functionalities (segmentation, etc.) to enable j1939 for Linux?

Quoted 8 lines

Quoted 3 lines

I took a quick look. It appears that they only put the address claiming in the kernel. I understand that this is exactly your concern in my implementation :-).

Yes, my implementation does address claiming in the module. From what I understand, mine does even more of the process than Kurt's does (my module actually sends the address claim messages). However, my module does not deal with NAMEs, only the addresses.

I'd like to know your idea:
Is it possible with isoblue to have multiple sockets using the same source address?
How does an application needs to deal with address changes? Does every application just receives the address claims without asking?

I feel it's time to explain some things

--- Original message ---

Quoted 9 lines

Date: Mon, 19 Oct 2015 08:07:31 +0200
From: Oliver Hartkopp <[email protected]>
To: Patrick Menschel <[email protected]>, linux-can
<[email protected]>, Alex Layton <[email protected]>, Kurt Van Dijck <[email protected]>
Subject: Re: can-j1939 API
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101
Icedove/31.8.0

Quoted 15 lines

Hi all,

Quoted 12 lines · Patrick Menschel

Am 18.10.2015 um 04:42 schrieb Kurt Van Dijck:

Quoted 6 lines

Quoted 3 lines

1. concerning J1939, I think it would be best to implement it is a "view" on can0 without changing can0 itself.

What exactly do you mean with 'view'?

Basically leave the can0 functionality as it is and add another interface such as J1939_0 or whatever. That way other applications may still use normal can0. But maybe I just misunderstood your concept, sorry if that's the case.

while using can-j1939, can0 (or any other iface) is still available for can_raw etc. I would not even think of touching that.

Quoted 27 lines

I also have problems to understand the concept for a while now.

Quoted 24 lines

Quoted 18 lines

Quoted 5 lines

As it's already been mentioned, j1939 may share the physical layer with other protocols, i.e. CanOpen on diesel powered railway equipment or proprietary protocols of some OEMs for construction machinery. If there is tester or application equipment installed, CCP is usually also present.

Thanks for the example.
IMHO, CanOpen uses only 11bit CANids, so theres no collision in the CAN id space. Does anyone ever encountered CAN protrocols that have collisions in the CANid space with can-j1939?

Quoted 6 lines

2. concerning address claiming and address collision handling via the NAME property, I think it should be handled in user space, not within the module as you may have multiple source addresses on the same device. For example Engine ECU SA 0x00 and Emission Controller SA 0x3D usually are one and the same physical device.

Quoted 4 lines

I think I partly share your conclusion,
I do not understand how multiple addresses on an ECU are an argument for handling address claiming in userspace.

If the device running socketcan+j1939 can only have one SA, it would not allow such multi-role implementations.

can-j1939 allows for multiple SA, and allows multi-role implementations. Moreover, the system adminstrator has control over the SA's used by the box.

This is independant from the address claiming in userspace vs. kernel space.

Quoted 1 line

Quoted 3 lines

I would definitely demand multi-role implementations as this is one of the main SocketCAN goals to have the entire networking setup running on one host or on different hosts without changing the application.

I see 2 distinct requirements for multi-role implementations:
a) 1 can-interface may have different addresses
b) different applications/sockets may use the same address

Quoted 5 lines

See:

https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/Documentation/networking/can.txt?h=linux-4.2.y#n185

If I understood the concepts correctly:

I believe you didn't understood all the concepts correctly. Your excused by not being an everyday j1939 user :-)

Quoted 3 lines

Kurts implementation:
- grabs the entire interface (the entire Linux box?!)

I don't grab the entire interface.
I process _all_ 29bit CAN frames because J1939, as already mentioned before, allocates the entire 29bit CANid space.

I know you have a problem with the administrator needing to switch can-j1939 'on', but can-j1939 is very different from CANopen on CANid allocation.

Quoted 7 lines

- binds node addresses to the interface (Linux box?!)
- socket addressing matches the function

Alexs implementation:
- socket addressing matches the node address

Both implement address claiming (AC) in Kernel space - which would only fit

I need to correct you.
My can-j1939 kernel space honor the AC in kernel space, as it is part of the protocol, but it leaves all decisions (the actual claiming) to userspace.

Quoted 2 lines

the SocketCAN idea of multi-role implementations, when the AC is per-socket in Alexs concept.

You need to explain a bit more in-depth what exactly it is you meant here.

Quoted 1 line

We should try to move as much functionality as possible out of the kernel.

I agree

Quoted 3 lines

When address claiming makes sense there it should stay there.

IMO Alexs concept is not only much smaller in code size ...

The smaller code size is due to the transport protocol not being handled.

J1939 wants to eliminate the edge of 8 byte per CAN frame by transparently using transport protocol.

Leaving this to userspace compromises real multi-role functionality, as it becomes hard when 2 applications share an address and both receive transport protocol sessions.

This is where problems arise.
So I'm very interested in how Alex solved this and what the impact on userspace is.

Oliver, for your information, on J1939, reserved J1939 "PGN"s are used to deliver any other PGN when it exceeds 8bytes.
So if 2 distinct applications (sharing the address) both want to send distinct PGNs >8bytes, they will both use those reserved J1939 PGNs instead of using the actual PGN. The actual PGN information is then packed inside the databytes, rather than the CANid.

Date: Mon, 19 Oct 2015 12:53:50 -0400
From: Alex Layton <[email protected]>
To: Kurt Van Dijck <[email protected]>, linux-can
<[email protected]>
Subject: Re: can-j1939 API

Quoted 44 lines · Kurt Van Dijck

--- Original message ---

Quoted 29 lines

Date: Thu, 15 Oct 2015 18:04:58 -0400
From: Alex Layton <[email protected]>
To: linux-can <[email protected]>
Subject: Re: can-j1939 API

Quoted 2 lines · Kurt Van Dijck

I would like to challenge other j1939 (not necessarily socketcan+can-j1939) users to share their opinions.

Hello, I am the author of https://github.com/ISOBlue/isoblue-software,
finally getting around to participating in this list.

Quoted 16 lines

Quoted 3 lines

Quoted 3 lines

If you look at http://elinux.org/J1939

$ modprobe can-j1939

This is a systemwide action, as opposed to

Quoted 1 line

Quoted 1 line

$ ip link set can0 j1939 on

which is an interface-wide action.

Due to the nature of CAN, the kernel should not/cannot decide if CAN traffic is J1939 or not.
Unlike other CAN protocols (RAW, BCM, ISOTP), J1939 allocates the whole CAN id range for its use, and using CAN ids incompatible with j1939 is regarded illegal.

Quoted 7 lines

Quoted 1 line

So this must become a switch.

I disagree with this, like Austin Schuh did. In my experience there is almost always other non-J1939 CAN traffic present and it must be possible to use both. The module should just ignore any CAN that does not look right to it, and there needs to still be a way to get at the other CAN on the bus through a CAN_RAW socket or something.

The 'switch' is to turn can-j1939 on/off on a specific interface. The condition that I'd like to solve is where you end up having a j1939 bus can0, obviously with 29bit CAN id's, and another bus, can1, that is NOT j1939 compliant while using 29bit identifiers.

Quoted 2 lines

I'd prefer to disable can-j1939 processing on can1 in that case, before reporting any obvious protocol violations in the log.

I can understand that. Can you not have you module only listen on interfaces where J1939 sockets have been opened?

Quoted 16 lines

Quoted 10 lines

Quoted 9 lines

Quoted 3 lines

Quoted 3 lines

and if you think about this kind of assignment, it should be implemented inside the j1939 stuff and not in af_can.c. The can-gw routing netlink

j1939 touches af_can because address configuration via netlink is absent in af_can. j1939 adds (with seperate patches) the ability to add addressess for CAN sockets, but only for those CAN protocols that support it.
I see no decent way to bypass af_can, except for creating af_j1939.

Quoted 5 lines

Sorry if this is a stupid question, but what is the point of adding addresses to a CAN interface with ip? Doesn't the code creating the socket set what its address and/or NAME is? My implementation does not modify af_can, though it is admittedly much more simplistic than Kurt's.

Quoted 4 lines

I offloaded the (static) addressing onto the kernel, so I needs to know its address, much like any other address-capable protocol like e.g. ipv4. Its obviously that not every ipv4 capable application needs to know it local ip address. I made can-j1939 likewise multi-user ready.

I don't really think of there being a "localhost" type thing in J1939. The address go with specific function, not devices, Often one physical device claims multiple addresses on the network, one for each thing that device does. For my module, when the program opening the socket does not know or care about which address to use, I simply claim an address for it that is unused and in the self-configurable range.

Quoted 24 lines

Quoted 15 lines

Quoted 7 lines

Quoted 4 lines

Quoted 4 lines

I remember our discussion about the address claiming but I wonder if we really follow the requirement to only put functionality into the kernel that really has to be implemented there.

The kernel tracks and validates J1939 traffic. Any userspace application can track, but none can validate & reject without duplicating effort.

I too think at least part of the address handling needs to be in the kernel module.

Quoted 4 lines

Quoted 3 lines

Quoted 3 lines

Did you take a look at https://github.com/ISOBlue/isoblue-software - which is far simpler - whether it can fulfill the basic functionalities (segmentation, etc.) to enable j1939 for Linux?

Quoted 8 lines

Quoted 3 lines

I took a quick look. It appears that they only put the address claiming in the kernel. I understand that this is exactly your concern in my implementation :-).

Yes, my implementation does address claiming in the module. From what I understand, mine does even more of the process than Kurt's does (my module actually sends the address claim messages). However, my module does not deal with NAMEs, only the addresses.

Quoted 5 lines

I'd like to know your idea:
Is it possible with isoblue to have multiple sockets using the same source address?
How does an application needs to deal with address changes? Does every application just receives the address claims without asking?

No, my module does not allow multiple sockets with the same address. My module takes the view that address go to functions, not devices, and assumes one socket per function.

If a socket loses its address, that socket returns -EADDRINUSE the next time a function is called on it (e.g., recvmesg). When that happens, the program must use bind again to get a new address. I had hoped to one day implement transparently claiming another address if the socket was set as self-configurable.

My module has support for filtering which PGNs a socket actually receives. If the filters on the socket allow address claim messages through, the socket will see them.

Date: Mon, 19 Oct 2015 12:53:54 -0400
From: Alex Layton <[email protected]>
To: Kurt Van Dijck <[email protected]>, Oliver Hartkopp
<[email protected]>, Patrick Menschel <[email protected]>, linux-can <[email protected]>
Subject: Re: can-j1939 API

Quoted 67 lines · Kurt Van Dijck

I feel it's time to explain some things

--- Original message ---

Quoted 9 lines

Date: Mon, 19 Oct 2015 08:07:31 +0200
From: Oliver Hartkopp <[email protected]>
To: Patrick Menschel <[email protected]>, linux-can
<[email protected]>, Alex Layton <[email protected]>, Kurt Van Dijck <[email protected]>
Subject: Re: can-j1939 API
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101
Icedove/31.8.0

Quoted 15 lines

Hi all,

Quoted 12 lines · Patrick Menschel

Am 18.10.2015 um 04:42 schrieb Kurt Van Dijck:

Quoted 6 lines

Quoted 3 lines

1. concerning J1939, I think it would be best to implement it is a "view" on can0 without changing can0 itself.

What exactly do you mean with 'view'?

Basically leave the can0 functionality as it is and add another interface such as J1939_0 or whatever. That way other applications may still use normal can0. But maybe I just misunderstood your concept, sorry if that's the case.

while using can-j1939, can0 (or any other iface) is still available for can_raw etc. I would not even think of touching that.

Quoted 27 lines

I also have problems to understand the concept for a while now.

Quoted 24 lines

Quoted 18 lines

Quoted 5 lines

As it's already been mentioned, j1939 may share the physical layer with other protocols, i.e. CanOpen on diesel powered railway equipment or proprietary protocols of some OEMs for construction machinery. If there is tester or application equipment installed, CCP is usually also present.

Thanks for the example.
IMHO, CanOpen uses only 11bit CANids, so theres no collision in the CAN id space. Does anyone ever encountered CAN protrocols that have collisions in the CANid space with can-j1939?

Quoted 6 lines

2. concerning address claiming and address collision handling via the NAME property, I think it should be handled in user space, not within the module as you may have multiple source addresses on the same device. For example Engine ECU SA 0x00 and Emission Controller SA 0x3D usually are one and the same physical device.

Quoted 4 lines

I think I partly share your conclusion,
I do not understand how multiple addresses on an ECU are an argument for handling address claiming in userspace.

If the device running socketcan+j1939 can only have one SA, it would not allow such multi-role implementations.

can-j1939 allows for multiple SA, and allows multi-role implementations. Moreover, the system adminstrator has control over the SA's used by the box.

This is independant from the address claiming in userspace vs. kernel space.

Quoted 1 line

Quoted 7 lines

Quoted 3 lines

I would definitely demand multi-role implementations as this is one of the main SocketCAN goals to have the entire networking setup running on one host or on different hosts without changing the application.

I see 2 distinct requirements for multi-role implementations:
a) 1 can-interface may have different addresses
b) different applications/sockets may use the same address

I definitely have encountered needing requirement a), but as far as I know b) is not so important. However, I could be mistaken on that.

Quoted 41 lines

Quoted 5 lines

See:

https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/Documentation/networking/can.txt?h=linux-4.2.y#n185

If I understood the concepts correctly:

I believe you didn't understood all the concepts correctly. Your excused by not being an everyday j1939 user :-)

Quoted 3 lines

Kurts implementation:
- grabs the entire interface (the entire Linux box?!)

I don't grab the entire interface.
I process _all_ 29bit CAN frames because J1939, as already mentioned before, allocates the entire 29bit CANid space.

I know you have a problem with the administrator needing to switch can-j1939 'on', but can-j1939 is very different from CANopen on CANid allocation.

Quoted 7 lines

- binds node addresses to the interface (Linux box?!)
- socket addressing matches the function

Alexs implementation:
- socket addressing matches the node address

Both implement address claiming (AC) in Kernel space - which would only fit

I need to correct you.
My can-j1939 kernel space honor the AC in kernel space, as it is part of the protocol, but it leaves all decisions (the actual claiming) to userspace.

Quoted 2 lines

the SocketCAN idea of multi-role implementations, when the AC is per-socket in Alexs concept.

You need to explain a bit more in-depth what exactly it is you meant here.

Quoted 1 line

We should try to move as much functionality as possible out of the kernel.

Quoted 8 lines

I agree

Quoted 3 lines

When address claiming makes sense there it should stay there.

IMO Alexs concept is not only much smaller in code size ...

The smaller code size is due to the transport protocol not being handled.

This is correct. My module does not implement any of the transport protocols, though I had hoped to add them one day.

Quoted 11 lines

J1939 wants to eliminate the edge of 8 byte per CAN frame by transparently using transport protocol.

Leaving this to userspace compromises real multi-role functionality, as it becomes hard when 2 applications share an address and both receive transport protocol sessions.

This is where problems arise.
So I'm very interested in how Alex solved this and what the impact on userspace is.

Quoted 6 lines

Oliver, for your information, on J1939, reserved J1939 "PGN"s are used to deliver any other PGN when it exceeds 8bytes.
So if 2 distinct applications (sharing the address) both want to send distinct PGNs >8bytes, they will both use those reserved J1939 PGNs instead of using the actual PGN. The actual PGN information is then packed inside the databytes, rather than the CANid.

This is how some (most?) of the J1939 family transport protocols work. However, this is also NMEA 200 Fast Packet, where the original PGN is still used as the PGN instead including it in the transported data.

This one is used frequently on the ISOBUS networks of agricultural equipment (my primary use case for SocketCAN).

I wanted to support
this one in my module as well as the more typical ones (.e.g., TP, ETP), but there is no good way to detect when a PGN is using it.

Quoted 5 lines

Quoted 5 lines

Quoted 4 lines

I would definitely demand multi-role implementations as this is one of the main SocketCAN goals to have the entire networking setup running on one host or on different hosts without changing the application.

Quoted 7 lines

Quoted 3 lines

I see 2 distinct requirements for multi-role implementations:
a) 1 can-interface may have different addresses
b) different applications/sockets may use the same address

I definitely have encountered needing requirement a), but as far as I know b) is not so important. However, I could be mistaken on that.

--- Original message ---

Quoted 55 lines

Date: Mon, 19 Oct 2015 12:53:50 -0400
From: Alex Layton <[email protected]>
To: Kurt Van Dijck <[email protected]>, linux-can
<[email protected]>
Subject: Re: can-j1939 API

Quoted 46 lines · Kurt Van Dijck

--- Original message ---

Quoted 29 lines

Date: Thu, 15 Oct 2015 18:04:58 -0400
From: Alex Layton <[email protected]>
To: linux-can <[email protected]>
Subject: Re: can-j1939 API

Quoted 2 lines · Kurt Van Dijck

I would like to challenge other j1939 (not necessarily socketcan+can-j1939) users to share their opinions.

Hello, I am the author of https://github.com/ISOBlue/isoblue-software,
finally getting around to participating in this list.

Quoted 16 lines

Quoted 3 lines

Quoted 3 lines

If you look at http://elinux.org/J1939

$ modprobe can-j1939

This is a systemwide action, as opposed to

Quoted 1 line

Quoted 1 line

$ ip link set can0 j1939 on

which is an interface-wide action.

Due to the nature of CAN, the kernel should not/cannot decide if CAN traffic is J1939 or not.
Unlike other CAN protocols (RAW, BCM, ISOTP), J1939 allocates the whole CAN id range for its use, and using CAN ids incompatible with j1939 is regarded illegal.

Quoted 7 lines

Quoted 1 line

So this must become a switch.

I disagree with this, like Austin Schuh did. In my experience there is almost always other non-J1939 CAN traffic present and it must be possible to use both. The module should just ignore any CAN that does not look right to it, and there needs to still be a way to get at the other CAN on the bus through a CAN_RAW socket or something.

The 'switch' is to turn can-j1939 on/off on a specific interface. The condition that I'd like to solve is where you end up having a j1939 bus can0, obviously with 29bit CAN id's, and another bus, can1, that is NOT j1939 compliant while using 29bit identifiers.

I'd prefer to disable can-j1939 processing on can1 in that case, before reporting any obvious protocol violations in the log.

Quoted 2 lines

I can understand that. Can you not have you module only listen on interfaces where J1939 sockets have been opened?

That sounds like a fine idea!
It would behave slightly different during booting, but given the critics on the switch, this will probably the best thing to do.
This implies that a non-root user decides to turn on can-j1939 processing on an interface, which I found a hard nut to crack.

Quoted 20 lines

Quoted 15 lines

Quoted 9 lines

Quoted 8 lines

Quoted 2 lines

Quoted 2 lines

and if you think about this kind of assignment, it should be implemented inside the j1939 stuff and not in af_can.c. The can-gw routing netlink

j1939 touches af_can because address configuration via netlink is absent in af_can. j1939 adds (with seperate patches) the ability to add addressess for CAN sockets, but only for those CAN protocols that support it.
I see no decent way to bypass af_can, except for creating af_j1939.

Quoted 5 lines

Sorry if this is a stupid question, but what is the point of adding addresses to a CAN interface with ip? Doesn't the code creating the socket set what its address and/or NAME is? My implementation does not modify af_can, though it is admittedly much more simplistic than Kurt's.

Quoted 4 lines

I offloaded the (static) addressing onto the kernel, so I needs to know its address, much like any other address-capable protocol like e.g. ipv4. Its obviously that not every ipv4 capable application needs to know it local ip address. I made can-j1939 likewise multi-user ready.

Quoted 6 lines

I don't really think of there being a "localhost" type thing in J1939. The address go with specific function, not devices, Often one physical device claims multiple addresses on the network, one for each thing that device does. For my module, when the program opening the socket does not know or care about which address to use, I simply claim an address for it that is unused and in the self-configurable range.

This sounds like a usage policy enforced by the kernel API semantics. At least, I understand the background a bit more.
More on this below.

Quoted 30 lines

Quoted 24 lines

Quoted 15 lines

Quoted 7 lines

Quoted 4 lines

Quoted 4 lines

I remember our discussion about the address claiming but I wonder if we really follow the requirement to only put functionality into the kernel that really has to be implemented there.

The kernel tracks and validates J1939 traffic. Any userspace application can track, but none can validate & reject without duplicating effort.

I too think at least part of the address handling needs to be in the kernel module.

Quoted 4 lines

Quoted 3 lines

Quoted 3 lines

Did you take a look at https://github.com/ISOBlue/isoblue-software - which is far simpler - whether it can fulfill the basic functionalities (segmentation, etc.) to enable j1939 for Linux?

Quoted 8 lines

Quoted 3 lines

I took a quick look. It appears that they only put the address claiming in the kernel. I understand that this is exactly your concern in my implementation :-).

Yes, my implementation does address claiming in the module. From what I understand, mine does even more of the process than Kurt's does (my module actually sends the address claim messages). However, my module does not deal with NAMEs, only the addresses.

Quoted 5 lines

I'd like to know your idea:
Is it possible with isoblue to have multiple sockets using the same source address?
How does an application needs to deal with address changes? Does every application just receives the address claims without asking?

Quoted 3 lines

No, my module does not allow multiple sockets with the same address. My module takes the view that address go to functions, not devices, and assumes one socket per function.

So a single application deals with the entire source address. It seems that quite a lot of code gets duplicated, especially the diagnostics interfaces.
I tend to look at a linux box as having different functions/addresses, and moreover, I look to a single address as being handled by different processes, of which most are generic processes with different parameters.

Things like ECU version information (I lost the precise PGN now), DM1, DM2 & DM3 handling, ... all seem very generic processes to me that all process a well-defined distinct set of PGN's, and can be reused easily. The easier each single application becomes, the quicker it can become stable, so I avoided the all-in-one approach.

Quoted 9 lines

If a socket loses its address, that socket returns -EADDRINUSE the next time a function is called on it (e.g., recvmesg). When that happens, the program must use bind again to get a new address. I had hoped to one day implement transparently claiming another address if the socket was set as self-configurable.

My module has support for filtering which PGNs a socket actually receives. If the filters on the socket allow address claim messages through, the socket will see them.

Given my major remark above, I can understand these API choices :-)

One of the differences between our approaches is that you implicitely assign addresses to the interface on kernel level by opening sockets. As with your proposal above, this allows a non-root user to add addresses.
I'm considering such approach. Would it make the difference?
I would then drop the netlink interface, and add some summary
in /proc for diagnose of the actual used source addresses.

--- Original message ---

Quoted 158 lines

Date: Mon, 19 Oct 2015 12:53:54 -0400
From: Alex Layton <[email protected]>
To: Kurt Van Dijck <[email protected]>, Oliver Hartkopp
<[email protected]>, Patrick Menschel <[email protected]>, linux-can <[email protected]>
Subject: Re: can-j1939 API

Quoted 67 lines · Kurt Van Dijck

I feel it's time to explain some things

--- Original message ---

Quoted 9 lines

Date: Mon, 19 Oct 2015 08:07:31 +0200
From: Oliver Hartkopp <[email protected]>
To: Patrick Menschel <[email protected]>, linux-can
<[email protected]>, Alex Layton <[email protected]>, Kurt Van Dijck <[email protected]>
Subject: Re: can-j1939 API
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101
Icedove/31.8.0

Quoted 15 lines

Hi all,

Quoted 12 lines · Patrick Menschel

Am 18.10.2015 um 04:42 schrieb Kurt Van Dijck:

Quoted 6 lines

Quoted 3 lines

1. concerning J1939, I think it would be best to implement it is a "view" on can0 without changing can0 itself.

What exactly do you mean with 'view'?

Basically leave the can0 functionality as it is and add another interface such as J1939_0 or whatever. That way other applications may still use normal can0. But maybe I just misunderstood your concept, sorry if that's the case.

while using can-j1939, can0 (or any other iface) is still available for can_raw etc. I would not even think of touching that.

Quoted 27 lines

I also have problems to understand the concept for a while now.

Quoted 24 lines

Quoted 18 lines

Quoted 5 lines

As it's already been mentioned, j1939 may share the physical layer with other protocols, i.e. CanOpen on diesel powered railway equipment or proprietary protocols of some OEMs for construction machinery. If there is tester or application equipment installed, CCP is usually also present.

Thanks for the example.
IMHO, CanOpen uses only 11bit CANids, so theres no collision in the CAN id space. Does anyone ever encountered CAN protrocols that have collisions in the CANid space with can-j1939?

Quoted 6 lines

2. concerning address claiming and address collision handling via the NAME property, I think it should be handled in user space, not within the module as you may have multiple source addresses on the same device. For example Engine ECU SA 0x00 and Emission Controller SA 0x3D usually are one and the same physical device.

Quoted 4 lines

I think I partly share your conclusion,
I do not understand how multiple addresses on an ECU are an argument for handling address claiming in userspace.

If the device running socketcan+j1939 can only have one SA, it would not allow such multi-role implementations.

can-j1939 allows for multiple SA, and allows multi-role implementations. Moreover, the system adminstrator has control over the SA's used by the box.

This is independant from the address claiming in userspace vs. kernel space.

Quoted 1 line

Quoted 7 lines

Quoted 3 lines

I would definitely demand multi-role implementations as this is one of the main SocketCAN goals to have the entire networking setup running on one host or on different hosts without changing the application.

I see 2 distinct requirements for multi-role implementations:
a) 1 can-interface may have different addresses
b) different applications/sockets may use the same address

I definitely have encountered needing requirement a), but as far as I know b) is not so important. However, I could be mistaken on that.

Quoted 41 lines

Quoted 5 lines

See:

https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/Documentation/networking/can.txt?h=linux-4.2.y#n185

If I understood the concepts correctly:

I believe you didn't understood all the concepts correctly. Your excused by not being an everyday j1939 user :-)

Quoted 3 lines

Kurts implementation:
- grabs the entire interface (the entire Linux box?!)

I don't grab the entire interface.
I process _all_ 29bit CAN frames because J1939, as already mentioned before, allocates the entire 29bit CANid space.

I know you have a problem with the administrator needing to switch can-j1939 'on', but can-j1939 is very different from CANopen on CANid allocation.

Quoted 7 lines

- binds node addresses to the interface (Linux box?!)
- socket addressing matches the function

Alexs implementation:
- socket addressing matches the node address

Both implement address claiming (AC) in Kernel space - which would only fit

I need to correct you.
My can-j1939 kernel space honor the AC in kernel space, as it is part of the protocol, but it leaves all decisions (the actual claiming) to userspace.

Quoted 2 lines

the SocketCAN idea of multi-role implementations, when the AC is per-socket in Alexs concept.

You need to explain a bit more in-depth what exactly it is you meant here.

Quoted 1 line

We should try to move as much functionality as possible out of the kernel.

Quoted 8 lines

I agree

Quoted 3 lines

When address claiming makes sense there it should stay there.

IMO Alexs concept is not only much smaller in code size ...

The smaller code size is due to the transport protocol not being handled.

This is correct. My module does not implement any of the transport protocols, though I had hoped to add them one day.

Quoted 17 lines

J1939 wants to eliminate the edge of 8 byte per CAN frame by transparently using transport protocol.

Leaving this to userspace compromises real multi-role functionality, as it becomes hard when 2 applications share an address and both receive transport protocol sessions.

This is where problems arise.
So I'm very interested in how Alex solved this and what the impact on userspace is.

Oliver, for your information, on J1939, reserved J1939 "PGN"s are used to deliver any other PGN when it exceeds 8bytes.
So if 2 distinct applications (sharing the address) both want to send distinct PGNs >8bytes, they will both use those reserved J1939 PGNs instead of using the actual PGN. The actual PGN information is then packed inside the databytes, rather than the CANid.

Quoted 3 lines

This is how some (most?) of the J1939 family transport protocols work. However, this is also NMEA 200 Fast Packet, where the original PGN is still used as the PGN instead including it in the transported data.

I'm aware of the NMEA2000 Fast Packet, and concluded that it is not strictly necessary to add support in the kernel.
It's very similar to ISOTP, where the major reason reason for kernel support is (I think) to allow stricter timing.

Quoted 2 lines

This one is used frequently on the ISOBUS networks of agricultural equipment (my primary use case for SocketCAN).

ISOBUS is also my primary goal.

Quoted 3 lines

I wanted to support
this one in my module as well as the more typical ones (.e.g., TP, ETP), but there is no good way to detect when a PGN is using it.

Well, I claim I solved this :-).
I left the fixed packet size semantics of CAN, in favor of variable size packet semantics of J1939. Together with the addressing, the semantics fit very well onto BSD sockets API.
Depending on the size you provide with sendto(), can-j1939 will switch to TP or even ETP.

FastPacket is an application-level decision, and results in 8byte packets that go out as single frames anyway.
I think this sticks to how J1939 meant to use it.

Quoted 9 lines

Quoted 3 lines

...
Can you not have you module only listen on
interfaces where J1939 sockets have been opened?

That sounds like a fine idea!
It would behave slightly different during booting, but given the critics on the switch, this will probably the best thing to do.
This implies that a non-root user decides to turn on can-j1939 processing on an interface, which I found a hard nut to crack.

I had not really considered the user permissions ramifications of things. You raise a good point here.

Doesn't SocketCAN automatically load the protocol module when you try to open a socket? That means non-root users can already decide to turn on processing on an interface for ISOTP etc. I am good with non-root users being able to enable J1939 like this, especially if the precedent is already set by other protocols.

Quoted 74 lines

Quoted 21 lines

Quoted 16 lines

Quoted 10 lines

Quoted 9 lines

Quoted 3 lines

Quoted 3 lines

and if you think about this kind of assignment, it should be implemented inside the j1939 stuff and not in af_can.c. The can-gw routing netlink

j1939 touches af_can because address configuration via netlink is absent in af_can. j1939 adds (with seperate patches) the ability to add addressess for CAN sockets, but only for those CAN protocols that support it.
I see no decent way to bypass af_can, except for creating af_j1939.

Quoted 5 lines

Sorry if this is a stupid question, but what is the point of adding addresses to a CAN interface with ip? Doesn't the code creating the socket set what its address and/or NAME is? My implementation does not modify af_can, though it is admittedly much more simplistic than Kurt's.

Quoted 4 lines

I offloaded the (static) addressing onto the kernel, so I needs to know its address, much like any other address-capable protocol like e.g. ipv4. Its obviously that not every ipv4 capable application needs to know it local ip address. I made can-j1939 likewise multi-user ready.

Quoted 6 lines

I don't really think of there being a "localhost" type thing in J1939. The address go with specific function, not devices, Often one physical device claims multiple addresses on the network, one for each thing that device does. For my module, when the program opening the socket does not know or care about which address to use, I simply claim an address for it that is unused and in the self-configurable range.

This sounds like a usage policy enforced by the kernel API semantics. At least, I understand the background a bit more.
More on this below.

Quoted 30 lines

Quoted 24 lines

Quoted 15 lines

Quoted 7 lines

Quoted 4 lines

Quoted 4 lines

I remember our discussion about the address claiming but I wonder if we really follow the requirement to only put functionality into the kernel that really has to be implemented there.

The kernel tracks and validates J1939 traffic. Any userspace application can track, but none can validate & reject without duplicating effort.

I too think at least part of the address handling needs to be in the kernel module.

Quoted 4 lines

Quoted 3 lines

Quoted 3 lines

Did you take a look at https://github.com/ISOBlue/isoblue-software - which is far simpler - whether it can fulfill the basic functionalities (segmentation, etc.) to enable j1939 for Linux?

Quoted 8 lines

Quoted 3 lines

I took a quick look. It appears that they only put the address claiming in the kernel. I understand that this is exactly your concern in my implementation :-).

Yes, my implementation does address claiming in the module. From what I understand, mine does even more of the process than Kurt's does (my module actually sends the address claim messages). However, my module does not deal with NAMEs, only the addresses.

Quoted 5 lines

I'd like to know your idea:
Is it possible with isoblue to have multiple sockets using the same source address?
How does an application needs to deal with address changes? Does every application just receives the address claims without asking?

Quoted 3 lines

No, my module does not allow multiple sockets with the same address. My module takes the view that address go to functions, not devices, and assumes one socket per function.

So a single application deals with the entire source address. It seems that quite a lot of code gets duplicated, especially the diagnostics interfaces.
I tend to look at a linux box as having different functions/addresses, and moreover, I look to a single address as being handled by different processes, of which most are generic processes with different parameters.

Quoted 5 lines

Things like ECU version information (I lost the precise PGN now), DM1, DM2 & DM3 handling, ... all seem very generic processes to me that all process a well-defined distinct set of PGN's, and can be reused easily. The easier each single application becomes, the quicker it can become stable, so I avoided the all-in-one approach.

Now I see the value of this use case.

I like the address claiming being in the kernel module. It does have timing requirements to be met, and it's code every application would have to repeat otherwise. Perhaps there could be a socket option telling the kernel module to allow assigning an address already in use by another socket?

That being said, if everyone else wants less (or no) address claiming in the kernel module than my implementation has, I could live with that.

Quoted 12 lines

Quoted 9 lines

If a socket loses its address, that socket returns -EADDRINUSE the next time a function is called on it (e.g., recvmesg). When that happens, the program must use bind again to get a new address. I had hoped to one day implement transparently claiming another address if the socket was set as self-configurable.

My module has support for filtering which PGNs a socket actually receives. If the filters on the socket allow address claim messages through, the socket will see them.

Given my major remark above, I can understand these API choices :-)

Quoted 7 lines

One of the differences between our approaches is that you implicitely assign addresses to the interface on kernel level by opening sockets. As with your proposal above, this allows a non-root user to add addresses.
I'm considering such approach. Would it make the difference?
I would then drop the netlink interface, and add some summary
in /proc for diagnose of the actual used source addresses.

I see J1939 addresses as being closer to TCP/IP ports rather than addresses (the go with functions/applications rather than devices), and non-root users can open new TCP/IP ports. In my opinion this aligns with how existing socket types work and so not an issue, but it is an opinion.

Perhaps we should get opinions on this from Oliver and anyone else who has one?
Personally, I think if you take that approach your implementation would be pretty darn close to what I envisions mine being one day.

Quoted 10 lines

Quoted 9 lines

Quoted 3 lines

...
Can you not have you module only listen on
interfaces where J1939 sockets have been opened?

That sounds like a fine idea!
It would behave slightly different during booting, but given the critics on the switch, this will probably the best thing to do.
This implies that a non-root user decides to turn on can-j1939 processing on an interface, which I found a hard nut to crack.

Quoted 8 lines

I had not really considered the user permissions ramifications of things. You raise a good point here.

Doesn't SocketCAN automatically load the protocol module when you try to open a socket? That means non-root users can already decide to turn on processing on an interface for ISOTP etc. I am good with non-root users being able to enable J1939 like this, especially if the precedent is already set by other protocols.

Yep, I can follow that argument.
When I get to it, I'll change that.
It also implies I can drop iproute2-j1939 branches completely.

Date: Thu, 29 Oct 2015 20:33:38 +0100
From: Oliver Hartkopp <[email protected]>
To: Alex Layton <[email protected]>, Kurt Van Dijck
<[email protected]>
CC: linux-can <[email protected]>
Subject: Re: can-j1939 API
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101
Icedove/31.8.0

Hi Kurt,

Quoted 19 lines · Kurt Van Dijck

Quoted 10 lines

Quoted 9 lines

Quoted 3 lines

...
Can you not have you module only listen on
interfaces where J1939 sockets have been opened?

That sounds like a fine idea!
It would behave slightly different during booting, but given the critics on the switch, this will probably the best thing to do.
This implies that a non-root user decides to turn on can-j1939 processing on an interface, which I found a hard nut to crack.

Quoted 8 lines

I had not really considered the user permissions ramifications of things. You raise a good point here.

Doesn't SocketCAN automatically load the protocol module when you try to open a socket? That means non-root users can already decide to turn on processing on an interface for ISOTP etc. I am good with non-root users being able to enable J1939 like this, especially if the precedent is already set by other protocols.

Quoted 4 lines

Yep, I can follow that argument.
When I get to it, I'll change that.
It also implies I can drop iproute2-j1939 branches completely.

Just to be sure I understood it correctly:

No iproute2-j1939 branch -> no address support for j1939 in iproute -> no address support in af_can.c ?? \o/

So you would automatically take care of SA/Name when a j1939 socket is created with the according address information (== per-socket), right?

Quoted 8 lines

From: Oliver Hartkopp <[email protected]>
To: Alex Layton <[email protected]>, Kurt Van Dijck

Quoted 4 lines

Yep, I can follow that argument.
When I get to it, I'll change that.
It also implies I can drop iproute2-j1939 branches completely.

Quoted 4 lines

Just to be sure I understood it correctly:

No iproute2-j1939 branch -> no address support for j1939 in iproute -> no address support in af_can.c ?? \o/

indeed.
Next to the address support, I also would then drop the link status support (i.e. ip link set can0 j1939 on/off).

Quoted 2 lines

So you would automatically take care of SA/Name when a j1939 socket is created with the according address information (== per-socket), right?

All SA or Name info comes via that way, indeed.
Any can-j1939 socket (regardless the user) could bind to a new SA or Name.

'per socket' is a bit dubious. In contrast to Alex, I would not restrict a specific SA or Name to a single socket for reasons I gave earlier.

Date: Mon, 02 Nov 2015 13:14:58 +0100
From: Oliver Hartkopp <[email protected]>
To: Alex Layton <[email protected]>, linux-can <[email protected]>,
Kurt Van Dijck <[email protected]>
Subject: Re: can-j1939 API
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101
Icedove/31.8.0

Quoted 8 lines · Kurt Van Dijck

Quoted 8 lines

From: Oliver Hartkopp <[email protected]>
To: Alex Layton <[email protected]>, Kurt Van Dijck

Quoted 4 lines

Yep, I can follow that argument.
When I get to it, I'll change that.
It also implies I can drop iproute2-j1939 branches completely.

Quoted 8 lines

Quoted 4 lines

Just to be sure I understood it correctly:

No iproute2-j1939 branch -> no address support for j1939 in iproute -> no address support in af_can.c ?? \o/

indeed.
Next to the address support, I also would then drop the link status support (i.e. ip link set can0 j1939 on/off).

ok

Quoted 5 lines

Quoted 2 lines

So you would automatically take care of SA/Name when a j1939 socket is created with the according address information (== per-socket), right?

All SA or Name info comes via that way, indeed.
Any can-j1939 socket (regardless the user) could bind to a new SA or Name.

This is what I would expect :-)

As Alex is only using SA in his implementation: Is the name still mandatory as j1939 address information?

Quoted 2 lines

'per socket' is a bit dubious. In contrast to Alex, I would not restrict a specific SA or Name to a single socket for reasons I gave earlier.

If I understand you correctly the first socket which is giving his address information enables the j1939 address (claiming) handling inside the Kernel, right?

Btw. is it possible to create two processes on the same Linux box which implement two different j1939 nodes (e.g. engine and trailer) that can communicate with each other both using the *same* CAN interface (can0 or vcan0)??

Regards,
Oliver

Quoted 6 lines

From: Oliver Hartkopp <[email protected]>
To: Alex Layton <[email protected]>, linux-can <[email protected]>,

Quoted 2 lines

'per socket' is a bit dubious. In contrast to Alex, I would not restrict a specific SA or Name to a single socket for reasons I gave earlier.

Quoted 3 lines

If I understand you correctly the first socket which is giving his address information enables the j1939 address (claiming) handling inside the Kernel, right?

That's the plan.
I would keep the address claiming itself as today in userspace.

Quoted 4 lines

Btw. is it possible to create two processes on the same Linux box which implement two different j1939 nodes (e.g. engine and trailer) that can communicate with each other both using the *same* CAN interface (can0 or vcan0)??

Yes.
This kind of transparency was one of my goals.

I'll do the necessary modifications.
This has become a rather low-priority task nowadays, although I think there is a momentum to make progress now.

Date: Tue, 10 Nov 2015 16:58:07 -0500
From: Yang <[email protected]>
To: Alex Layton <[email protected]>, linux-can <[email protected]>
Subject: Re: Re: can-j1939 API
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
Thunderbird/38.3.0

Quoted 3 lines · Kurt Van Dijck

I'll do the necessary modifications.
This has become a rather low-priority task nowadays, although I think there is a momentum to make progress now.

I am working with Alex, the author of
https://github.com/ISOBlue/isoblue-software on a project that uses j1939. With Alex's module, we wrote another program to receive messages and get the PGN out of each message.

After looking through this thread, it seems like your module could do the same thing and it looks promising that your module will be added into the main linux kernel. You mentioned that there are things you need to fix and change. I'm currently looking into writing a JNI wrapper for the j1939 module you have. My question is: as you make modifications to the API, how much will change? I can't/don't want to write the JNI wrapper if the code will keep changing significantly.

Date: Mon, 02 Nov 2015 14:18:25 +0100
From: Oliver Hartkopp <[email protected]>
To: Alex Layton <[email protected]>, linux-can <[email protected]>
Subject: Re: can-j1939 API
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101
Icedove/31.8.0

Quoted 10 lines · Kurt Van Dijck

Quoted 9 lines

From: Oliver Hartkopp <[email protected]>
To: Alex Layton <[email protected]>, linux-can <[email protected]>,

Quoted 2 lines

'per socket' is a bit dubious. In contrast to Alex, I would not restrict a specific SA or Name to a single socket for reasons I gave earlier.

If I understand you correctly the first socket which is giving his address information enables the j1939 address (claiming) handling inside the Kernel, right?

Quoted 2 lines

That's the plan.
I would keep the address claiming itself as today in userspace.

Oh - but what is net/can/j1939/address-claim.c then? Did it become obsolete?

Quoted 8 lines

Quoted 5 lines

Btw. is it possible to create two processes on the same Linux box which implement two different j1939 nodes (e.g. engine and trailer) that can communicate with each other both using the *same* CAN interface (can0 or vcan0)??

Yes.
This kind of transparency was one of my goals.

Great.

Regards,
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-can" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

The fixes I need to do don't affect the API.
The upcoming changes to can-j1939 do not yet affect the socket API, they rather affect how iproute2 is needed (I plan to drop the need for it).

I'm not so familiar with JNI etc. I assume that the whole iproute2 thing would stay out of it alltogether?

Kind regards,
Kurt

Date: Tue, 17 Nov 2015 01:01:10 -0500
From: Yang Wang <[email protected]>
To: [email protected]
Cc: Alex Layton <[email protected]>, linux-can <[email protected]>
Subject: Re: Re: can-j1939 API

Quoted 8 lines · Kurt Van Dijck

The fixes I need to do don't affect the API.
The upcoming changes to can-j1939 do not yet affect the socket API, they rather affect how iproute2 is needed (I plan to drop the need for it).

I'm not so familiar with JNI etc. I assume that the whole iproute2 thing would stay out of it alltogether?

Quoted 2 lines

Kind regards,
Kurt

Yes. I am inclined to use the stock iproute2 if possible.

I did compile your newest branch (j1939-v3.15x) on kernel source tree. After booting into the kernel, it seems like the j1939 switch will not work on a CAN interface unless your version of iproute2 is installed.

I will begin writing the JNI wrapper for j1939 but how soon do you plan on dropping the need on iproute2?

Regards,
Yang
--
To unsubscribe from this list: send the line "unsubscribe linux-can" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html