Re: [can-utils] J1939 v6 (#7)

Re: [can-utils] J1939 v6 (#7)

[Marc Kleine-Budde]

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

Hello Mikey and Kurt,

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

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [can-utils] J1939 v6 (#7)

[Kurt Van Dijck]

> Hello Mikey and Kurt,
> 
> 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
> > 
> > 
> >         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?

Cool!

The userspace API/ABI is IMO stable. I had a lot of feedback from Oliver
on this, and I stripped everything I could.
The semantics underneath (in kernel space) are almost stable.

The biggest thing is that the struct sockaddr_can is enlarged by j1939,
and this got never accepted.
The current kernel patches do change the other CAN sockets' behaviour to
test not on exact size of the 'struct sockaddr', but to test a 'minimal
required size'.

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.

Kurt

> 
> Marc
> 
> -- 
> 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   |
> 

Re: [can-utils] J1939 v6 (#7)

[Aaron Clarke]

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.

> 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.

Best regards,

Aaron

Re: [can-utils] J1939 v6 (#7)

[Kurt Van Dijck]

--- Original message ---
> Date:	Wed, 30 Sep 2015 15:26:40 +0000 (UTC)
> From: Aaron Clarke <ac@aaronclarke.com>
> To: linux-can@vger.kernel.org
> Subject: Re: [can-utils] J1939 v6 (#7)
> User-Agent: Loom/3.14 (http://gmane.org/)
> 
> 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.
> 
> > 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.

The 3.12 branch is stable.

Kind regards,
Kurt

Re: [can-utils] J1939 v6 (#7)

[Marc Kleine-Budde]

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

On 09/29/2015 08:34 PM, Oliver Hartkopp wrote:
> 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.

Marc


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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

can-j1939 API

[Kurt Van Dijck]

> Can we switch to the mailinglist for the discussion.
Yes

> On 09/29/2015 08:34 PM, Oliver Hartkopp wrote:
> > Hi Kurt,
> > 
> > I'm sorry but I still think that your implementation and configuration
> > is way to complex and not intuitive.

Marc,
This means that the API is not yet agreed on :-)

I believe this is the point where a userbase should decide
what is feasible and what not.
Up to now, the discussion was between Oliver & I, and Oliver
was/is not familiar with j1939 use.

Since Oliver listed his mains concerns here, I'll address them
with my arguments so noone needs to read old discussions.

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

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

> > $ modprobe can-j1939

This is a systemwide action, as opposed to

> > $ 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.

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

Adding addressing to j1939 networks is one of the core principles of
j1939, whether we like it or not.
Unlike raw CAN or CANopen where each datagram gets a unique id in the
network, J1939 implements a hierarchy where 8 bits indicate the source,
and another 18bits indicate the datagrams unique id.

I don't claim that this is good design.
I do claim that this design fits real close to the addressing
used in BSD sockets, and therefore any alternative is useless new API.

As stated above, this is not the case for most other CAN protocols.

> > 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.

> > 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.

because j1939 lives on top of af_can, the sockaddr_can extension affects
the ABI of other can protocols too. The minimal change to support the
old ABI is essential.

> > 
> > 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.

> > 
> > 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 :-).

Kind regards,
Kurt

Re: can-j1939 API

[Austin Schuh]

On Tue, Sep 29, 2015 at 12:49 PM Kurt Van Dijck
<dev.kurt@vandijck-laurijssen.be> wrote:
> I would like to challenge other j1939 (not necessarily socketcan+can-j1939)
> users to share their opinions.
>
> > > If you look at http://elinux.org/J1939
>
> > > $ modprobe can-j1939
>
> This is a systemwide action, as opposed to
>
> > > $ 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.

I've been implementing J1939 in userspace with socketcan, and have
worked with a number of different vehicle types, each with their
quirks.  I haven't looked at Kurt's implementation, so take my
thoughts with a grain of salt.

J1939 allocates _most_ of the 29 bit can IDs.  The EDP bit in the
can_id signals that the message should be ignored, and any 11 bit CAN
IDs should also be ignored.  I've seen vehicles with both types of
messages on the J1939 CAN bus that I've had to work around (formats A
and B).  11 bit message IDs tend to be when system diagnostics are
happening (debugging brake ECUs, etc), though not always.  In the real
world, you won't find CAN busses which only have J1939 traffic on
them.  For the most part, you will be able to ignore the other
traffic, but not always.  The standard specifies (I can't quote
sections for you right now) that other traffic should be ignored.

Austin

Re: can-j1939 API

[Alex Layton]

On Tue, Sep 29, 2015 at 3:49 PM, Kurt Van Dijck
<dev.kurt@vandijck-laurijssen.be> wrote:
> 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.

> > > If you look at http://elinux.org/J1939
>
> > > $ modprobe can-j1939
>
> This is a systemwide action, as opposed to
>
> > > $ 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.

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.

> > > 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.

> > > 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.

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

Re: can-j1939 API

[Patrick Menschel]

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

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:
> On Tue, Sep 29, 2015 at 3:49 PM, Kurt Van Dijck
> <dev.kurt@vandijck-laurijssen.be> wrote:
>> 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.
> 
>>>> If you look at http://elinux.org/J1939
>>
>>>> $ modprobe can-j1939
>>
>> This is a systemwide action, as opposed to
>>
>>>> $ 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.
> 
> 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.
> 
>>>> 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.
> 
>>>> 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.
> 
>>>> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3709 bytes --]

Re: can-j1939 API

[Kurt Van Dijck]

--- Original message ---
> Date:	Fri, 16 Oct 2015 21:36:52 +0200
> From: Patrick Menschel <menschel.p@posteo.de>
> To: linux-can <linux-can@vger.kernel.org>
> 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.

What exactly do you mean with 'view'?

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

> 
> 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.

> 
> Regards,
> Patrick

Kind regards,
Kurt
> 
> 
> Am 16.10.2015 um 00:04 schrieb Alex Layton:
> > On Tue, Sep 29, 2015 at 3:49 PM, Kurt Van Dijck
> > <dev.kurt@vandijck-laurijssen.be> wrote:
> >> 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.
> > 
> >>>> If you look at http://elinux.org/J1939
> >>
> >>>> $ modprobe can-j1939
> >>
> >> This is a systemwide action, as opposed to
> >>
> >>>> $ 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.
> > 
> > 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.
> > 
> >>>> 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.
> > 
> >>>> 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.
> > 
> >>>> 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 majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> 
> 

Re: can-j1939 API

[Patrick Menschel]

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

Am 18.10.2015 um 04:42 schrieb Kurt Van Dijck:
> 
> --- Original message ---
>> Date:	Fri, 16 Oct 2015 21:36:52 +0200
>> From: Patrick Menschel <menschel.p@posteo.de>
>> To: linux-can <linux-can@vger.kernel.org>
>> 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.
> 
> 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.

>> 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?
> 
>>
>> 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.
> 
If the device running socketcan+j1939 can only have one SA, it would not
allow such multi-role implementations.
>>
>> Regards,
>> Patrick
> 
> Kind regards,
> Kurt
>>
>>
>> Am 16.10.2015 um 00:04 schrieb Alex Layton:
>>> On Tue, Sep 29, 2015 at 3:49 PM, Kurt Van Dijck
>>> <dev.kurt@vandijck-laurijssen.be> wrote:
>>>> 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.
>>>
>>>>>> If you look at http://elinux.org/J1939
>>>>
>>>>>> $ modprobe can-j1939
>>>>
>>>> This is a systemwide action, as opposed to
>>>>
>>>>>> $ 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.
>>>
>>> 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.
>>>
>>>>>> 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.
>>>
>>>>>> 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.
>>>
>>>>>> 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 majordomo@vger.kernel.org
>>> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3709 bytes --]

Re: can-j1939 API

[Oliver Hartkopp]

Hi all,

On 19.10.2015 05:41, Patrick Menschel wrote:
> Am 18.10.2015 um 04:42 schrieb Kurt Van Dijck:
>>>
>>> 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.

>>> 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?
>>
>>>
>>> 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.
>>
> 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 and impact to the 
existing af_can infrastructure - it also implements the multi-role concept in 
a slim way the experienced CAN programmer would expect.

Or did I miss anything vital?

Best regards,
Oliver

Re: can-j1939 API

[Kurt Van Dijck]

I feel it's time to explain some things

--- Original message ---
> Date:	Mon, 19 Oct 2015 08:07:31 +0200
> From: Oliver Hartkopp <socketcan@hartkopp.net>
> To: Patrick Menschel <menschel.p@posteo.de>, linux-can
>  <linux-can@vger.kernel.org>, Alex Layton <alex@layton.in>, Kurt Van Dijck
>  <dev.kurt@vandijck-laurijssen.be>
> 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,
> 
> On 19.10.2015 05:41, Patrick Menschel wrote:
> >Am 18.10.2015 um 04:42 schrieb Kurt Van Dijck:
> >>>
> >>>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.

> 
> I also have problems to understand the concept for a while now.
> 
> >>>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?
> >>
> >>>
> >>>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.
> >>
> >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.

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

> 
> 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 :-)

> 
> 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.

> - 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.

> 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.

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

I agree

> 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.

Kind regards,
Kurt

Re: can-j1939 API

[Alex Layton]

On Mon, Oct 19, 2015 at 5:52 AM, Kurt Van Dijck
<dev.kurt@vandijck-laurijssen.be> wrote:
> I feel it's time to explain some things
>
> --- Original message ---
>> Date: Mon, 19 Oct 2015 08:07:31 +0200
>> From: Oliver Hartkopp <socketcan@hartkopp.net>
>> To: Patrick Menschel <menschel.p@posteo.de>, linux-can
>>  <linux-can@vger.kernel.org>, Alex Layton <alex@layton.in>, Kurt Van Dijck
>>  <dev.kurt@vandijck-laurijssen.be>
>> 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,
>>
>> On 19.10.2015 05:41, Patrick Menschel wrote:
>> >Am 18.10.2015 um 04:42 schrieb Kurt Van Dijck:
>> >>>
>> >>>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.
>
>>
>> I also have problems to understand the concept for a while now.
>>
>> >>>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?
>> >>
>> >>>
>> >>>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.
>> >>
>> >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.
>
>>
>> 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.

>> 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 :-)
>
>>
>> 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.
>
>> - 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.
>
>> 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.
>
>> We should try to move as much functionality as possible out of the kernel.
>
> I agree
>
>> 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.

> 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.

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.


Alex

Re: can-j1939 API

[Kurt Van Dijck]

--- Original message ---
> Date:	Mon, 19 Oct 2015 12:53:54 -0400
> From: Alex Layton <alex@layton.in>
> To: Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be>, Oliver Hartkopp
>  <socketcan@hartkopp.net>, Patrick Menschel <menschel.p@posteo.de>,
>  linux-can <linux-can@vger.kernel.org>
> Subject: Re: can-j1939 API
> 
> On Mon, Oct 19, 2015 at 5:52 AM, Kurt Van Dijck
> <dev.kurt@vandijck-laurijssen.be> wrote:
> > I feel it's time to explain some things
> >
> > --- Original message ---
> >> Date: Mon, 19 Oct 2015 08:07:31 +0200
> >> From: Oliver Hartkopp <socketcan@hartkopp.net>
> >> To: Patrick Menschel <menschel.p@posteo.de>, linux-can
> >>  <linux-can@vger.kernel.org>, Alex Layton <alex@layton.in>, Kurt Van Dijck
> >>  <dev.kurt@vandijck-laurijssen.be>
> >> 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,
> >>
> >> On 19.10.2015 05:41, Patrick Menschel wrote:
> >> >Am 18.10.2015 um 04:42 schrieb Kurt Van Dijck:
> >> >>>
> >> >>>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.
> >
> >>
> >> I also have problems to understand the concept for a while now.
> >>
> >> >>>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?
> >> >>
> >> >>>
> >> >>>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.
> >> >>
> >> >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.
> >
> >>
> >> 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.
> 
> >> 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 :-)
> >
> >>
> >> 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.
> >
> >> - 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.
> >
> >> 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.
> >
> >> We should try to move as much functionality as possible out of the kernel.
> >
> > I agree
> >
> >> 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.
> 
> > 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.
> 
> 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.

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

ISOBUS is also my primary goal.

> 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.

Kind regards,
Kurt

Re: can-j1939 API

[Kurt Van Dijck]

> > >>
> > >> 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.
> > 

We (in my company) typically have the hot-path in plain-C simple
programs, close to the kernel. These programs translate the parameters
like engine RPM etc. into floating point and distribute it across the
linux box. This can then be re-used by error-logging processes,
failure detection processes, and of course the GUI which is written
in ... systems like Qt with painfull interaction with non-ethernet
networks.
On the other hand, some low-bandwith communication is better dealt with
directly from the GUI. Things like remote error log visualing, or
some machine calibration routines.
While technically possible to allocate an address per function, it's not
feasible.

Kurt

Re: can-j1939 API

[Alex Layton]

> --- Original message ---
>> Date: Mon, 19 Oct 2015 12:53:54 -0400
>> From: Alex Layton <alex@layton.in>
>> To: Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be>, Oliver Hartkopp
>>  <socketcan@hartkopp.net>, Patrick Menschel <menschel.p@posteo.de>,
>>  linux-can <linux-can@vger.kernel.org>
>> Subject: Re: can-j1939 API
>>
>> On Mon, Oct 19, 2015 at 5:52 AM, Kurt Van Dijck
>> <dev.kurt@vandijck-laurijssen.be> wrote:
>> > I feel it's time to explain some things
>> >
>> > --- Original message ---
>> >> Date: Mon, 19 Oct 2015 08:07:31 +0200
>> >> From: Oliver Hartkopp <socketcan@hartkopp.net>
>> >> To: Patrick Menschel <menschel.p@posteo.de>, linux-can
>> >>  <linux-can@vger.kernel.org>, Alex Layton <alex@layton.in>, Kurt Van Dijck
>> >>  <dev.kurt@vandijck-laurijssen.be>
>> >> 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,
>> >>
>> >> On 19.10.2015 05:41, Patrick Menschel wrote:
>> >> >Am 18.10.2015 um 04:42 schrieb Kurt Van Dijck:
>> >> >>>
>> >> >>>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.
>> >
>> >>
>> >> I also have problems to understand the concept for a while now.
>> >>
>> >> >>>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?
>> >> >>
>> >> >>>
>> >> >>>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.
>> >> >>
>> >> >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.
>> >
>> >>
>> >> 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.
>>
>> >> 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 :-)
>> >
>> >>
>> >> 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.
>> >
>> >> - 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.
>> >
>> >> 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.
>> >
>> >> We should try to move as much functionality as possible out of the kernel.
>> >
>> > I agree
>> >
>> >> 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.
>>
>> > 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.
>>
>> 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.

You are probably right that Fast Packet does not need to be in the kernel.

>> This one is used frequently on the ISOBUS networks of agricultural
>> equipment (my primary use case for SocketCAN).
>
> ISOBUS is also my primary goal.
>
>> 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.

That sounds like the kind of thing I had intended to do when I got to it.

You are probably right again about Fast Packet. The application is the
only thing that can know when a PGN is using Fast Packet anyways.


Alex

Re: can-j1939 API

[Kurt Van Dijck]

--- Original message ---
> Date:	Thu, 15 Oct 2015 18:04:58 -0400
> From: Alex Layton <alex@layton.in>
> To: linux-can <linux-can@vger.kernel.org>
> Subject: Re: can-j1939 API
> 
> On Tue, Sep 29, 2015 at 3:49 PM, Kurt Van Dijck
> <dev.kurt@vandijck-laurijssen.be> wrote:
> > 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.
> 
> > > > If you look at http://elinux.org/J1939
> >
> > > > $ modprobe can-j1939
> >
> > This is a systemwide action, as opposed to
> >
> > > > $ 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.
> 
> 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.

> 
> > > > 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.

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 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.
> 
> > > > 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.

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?

Kurt

Re: can-j1939 API

[Alex Layton]

On Sat, Oct 17, 2015 at 10:32 PM, Kurt Van Dijck
<dev.kurt@vandijck-laurijssen.be> wrote:
>
> --- Original message ---
>> Date: Thu, 15 Oct 2015 18:04:58 -0400
>> From: Alex Layton <alex@layton.in>
>> To: linux-can <linux-can@vger.kernel.org>
>> Subject: Re: can-j1939 API
>>
>> On Tue, Sep 29, 2015 at 3:49 PM, Kurt Van Dijck
>> <dev.kurt@vandijck-laurijssen.be> wrote:
>> > 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.
>>
>> > > > If you look at http://elinux.org/J1939
>> >
>> > > > $ modprobe can-j1939
>> >
>> > This is a systemwide action, as opposed to
>> >
>> > > > $ 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.
>>
>> 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.

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

>> > > > 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.
>
> 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.

>> > > > 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.
>>
>> > > > 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.
>
> 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.


Alex

Re: can-j1939 API

[Kurt Van Dijck]

--- Original message ---
> Date:	Mon, 19 Oct 2015 12:53:50 -0400
> From: Alex Layton <alex@layton.in>
> To: Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be>, linux-can
>  <linux-can@vger.kernel.org>
> Subject: Re: can-j1939 API
> 
> On Sat, Oct 17, 2015 at 10:32 PM, Kurt Van Dijck
> <dev.kurt@vandijck-laurijssen.be> wrote:
> >
> > --- Original message ---
> >> Date: Thu, 15 Oct 2015 18:04:58 -0400
> >> From: Alex Layton <alex@layton.in>
> >> To: linux-can <linux-can@vger.kernel.org>
> >> Subject: Re: can-j1939 API
> >>
> >> On Tue, Sep 29, 2015 at 3:49 PM, Kurt Van Dijck
> >> <dev.kurt@vandijck-laurijssen.be> wrote:
> >> > 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.
> >>
> >> > > > If you look at http://elinux.org/J1939
> >> >
> >> > > > $ modprobe can-j1939
> >> >
> >> > This is a systemwide action, as opposed to
> >> >
> >> > > > $ 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.
> >>
> >> 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.
> 
> 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.

> 
> >> > > > 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.
> >
> > 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.

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.

> 
> >> > > > 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.
> >>
> >> > > > 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.
> >
> > 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.

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.

> 
> 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.

Kind regards,
Kurt

Re: can-j1939 API

[Alex Layton]

> --- Original message ---
>> Date: Mon, 19 Oct 2015 12:53:50 -0400
>> From: Alex Layton <alex@layton.in>
>> To: Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be>, linux-can
>>  <linux-can@vger.kernel.org>
>> Subject: Re: can-j1939 API
>>
>> On Sat, Oct 17, 2015 at 10:32 PM, Kurt Van Dijck
>> <dev.kurt@vandijck-laurijssen.be> wrote:
>> >
>> > --- Original message ---
>> >> Date: Thu, 15 Oct 2015 18:04:58 -0400
>> >> From: Alex Layton <alex@layton.in>
>> >> To: linux-can <linux-can@vger.kernel.org>
>> >> Subject: Re: can-j1939 API
>> >>
>> >> On Tue, Sep 29, 2015 at 3:49 PM, Kurt Van Dijck
>> >> <dev.kurt@vandijck-laurijssen.be> wrote:
>> >> > 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.
>> >>
>> >> > > > If you look at http://elinux.org/J1939
>> >> >
>> >> > > > $ modprobe can-j1939
>> >> >
>> >> > This is a systemwide action, as opposed to
>> >> >
>> >> > > > $ 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.
>> >>
>> >> 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.
>>
>> 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.

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.

>> >> > > > 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.
>> >
>> > 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.
>
> 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.
>
>>
>> >> > > > 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.
>> >>
>> >> > > > 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.
>> >
>> > 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.
>
> 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.

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.

>> 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.

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.


Alex

Re: can-j1939 API

[Kurt Van Dijck]

> >> ...
> >> 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.

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.

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

Due to re-using addresses (or NAMES in this case) across different
sockets, I simply offloaded the actual address claiming, including all
decision policies, into another process.
"jacd" does the job.
So, no code repetition is required, but if you like, you can write
another program that does the job differently.

This illustrates my view on a J1939 node on linux: a set of different
programs, each doing their part of the node.
This approach should protect applications from requiring complexity.

> 
> 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.
> 
> >> 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.
> 
> 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.

Since J1939 is a datagram network, I compare with UDP.
UDP port numbers are very equivalent to PGN numbers, while addresses
IMHO compare to IP addresses.

This view of mine does not imply wether or not non-root users can
manipulate this. Altough, on IP networks, non-root users cannot
manipulate things, I now doubt the benefit of this restriction,
especially on J1939.
As mentioned above, I'll address this too.

> 
> 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.

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.

Kurt

Re: can-j1939 API

[Oliver Hartkopp]

Hi Kurt,

On 10/23/2015 01:14 PM, Kurt Van Dijck wrote:
>>>> ...
>>>> 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.
> 
> 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?

Regards,
Oliver

Re: can-j1939 API

[Kurt Van Dijck]

--- Original message ---
> Date: Thu, 29 Oct 2015 20:33:38 +0100
> From: Oliver Hartkopp <socketcan@hartkopp.net>
> To: Alex Layton <alex@layton.in>, Kurt Van Dijck
>  <dev.kurt@vandijck-laurijssen.be>
> CC: linux-can <linux-can@vger.kernel.org>
> 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,
> 
> On 10/23/2015 01:14 PM, Kurt Van Dijck wrote:
> >>>> ...
> >>>> 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.
> > 
> > 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/

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

> 
> 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.

Kurt

Re: can-j1939 API

[Oliver Hartkopp]

On 30.10.2015 00:38, Kurt Van Dijck wrote:
>> From: Oliver Hartkopp <socketcan@hartkopp.net>
>> To: Alex Layton <alex@layton.in>, Kurt Van Dijck

>>> 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/
>
> 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

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

> '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

Re: can-j1939 API

[Kurt Van Dijck]

--- Original message ---
> Date: Mon, 02 Nov 2015 13:14:58 +0100
> From: Oliver Hartkopp <socketcan@hartkopp.net>
> To: Alex Layton <alex@layton.in>, linux-can <linux-can@vger.kernel.org>,
>  Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be>
> Subject: Re: can-j1939 API
> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101
>  Icedove/31.8.0
> 
> On 30.10.2015 00:38, Kurt Van Dijck wrote:
> >>From: Oliver Hartkopp <socketcan@hartkopp.net>
> >>To: Alex Layton <alex@layton.in>, Kurt Van Dijck
> 
> >>>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/
> >
> >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
> 
> >>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?
> 
> >'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?

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

> 
> 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.

> 
> Regards,
> Oliver
> 

Re: can-j1939 API

[Oliver Hartkopp]

On 02.11.2015 13:29, Kurt Van Dijck wrote:
>> From: Oliver Hartkopp <socketcan@hartkopp.net>
>> To: Alex Layton <alex@layton.in>, linux-can <linux-can@vger.kernel.org>,

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

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

Re: can-j1939 API

[Kurt Van Dijck]

Oliver,

I must have lost this email ...

--- Original message ---
> Date:	Mon, 02 Nov 2015 14:18:25 +0100
> From: Oliver Hartkopp <socketcan@hartkopp.net>
> To: Alex Layton <alex@layton.in>, linux-can <linux-can@vger.kernel.org>
> Subject: Re: can-j1939 API
> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101
>  Icedove/31.8.0
> 
> On 02.11.2015 13:29, Kurt Van Dijck wrote:
> >>From: Oliver Hartkopp <socketcan@hartkopp.net>
> >>To: Alex Layton <alex@layton.in>, linux-can <linux-can@vger.kernel.org>,
> 
> >>>'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?
> >
> >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?

No, can-j1939 tracks address claims in kernel, or in development terms,
it receives address claims on the bus so the kernel can build a
address<->name table for later use.

The 'active' part of address claiming, or sending address claims, is
for userspace.

> 
> >>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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Re: can-j1939 API

[Yang]

On 10/23/2015 07:14 AM, Kurt Van Dijck wrote:

> 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.

Re: Re: can-j1939 API

[Kurt Van Dijck]

--- Original message ---
> Date:	Tue, 10 Nov 2015 16:58:07 -0500
> From: Yang <wang701@purdue.edu>
> To: Alex Layton <alex@layton.in>, linux-can <linux-can@vger.kernel.org>
> Subject: Re: Re: can-j1939 API
> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
>  Thunderbird/38.3.0
> 
> On 10/23/2015 07:14 AM, Kurt Van Dijck wrote:
> 
> >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.

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

Re: Re: can-j1939 API

[Yang Wang]

On Wed, Nov 11, 2015 at 1:49 PM, Kurt Van Dijck
<dev.kurt@vandijck-laurijssen.be> wrote:
>
> 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

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

Re: Re: can-j1939 API

[Kurt Van Dijck]

--- Original message ---
> Date:	Tue, 17 Nov 2015 01:01:10 -0500
> From: Yang Wang <wang701@purdue.edu>
> To: dev.kurt@vandijck-laurijssen.be
> Cc: Alex Layton <alex@layton.in>, linux-can <linux-can@vger.kernel.org>
> Subject: Re: Re: can-j1939 API
> 
> On Wed, Nov 11, 2015 at 1:49 PM, Kurt Van Dijck
> <dev.kurt@vandijck-laurijssen.be> wrote:
> >
> > 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
> 
> 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.

yes, that's true.

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

Well, I'm 25% now. I plan to finish, let's say, a couple of weeks.

> 
> Regards,
> Yang
> --
> 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