j1939 ACL

j1939 ACL

[Oleksij Rempel]

Hi all,

what is the proper or expected way for j1939 ACL (address claiming)?

Should it be done by automatically by kernel? Are there any existing
examples?

Is this a correct ACL message?
source address: for example 0x80
PGN: 0xee00
DATA: NAME

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: j1939 ACL

[Rémy Dziemiaszko]

> Hi all,
Hi Oleksij,
> what is the proper or expected way for j1939 ACL (address claiming)?
>
> Should it be done by automatically by kernel? Are there any existing
> examples?
The address claiming is not under the responsibility of the kernel but 
under responsibility of user space.
You should have a look and play with the jacd daemon that implements the 
Address Claiming procedure for you (see [1]).
> Is this a correct ACL message?
> source address: for example 0x80
> PGN: 0xee00
> DATA: NAME
Yes that is correct but do not forget to set the destination adresse to 
"everybody" (0xFF)

Here is an example of Address Claim sequence where device 
AAAAAAAAAAAAAAAA enters the network and device BBBBBBBBBBBBBBBB already 
have address 0xAA:

(1516110467.317706) can0 18EAFFFE#00EE00 ------------> Device 
AAAAAAAAAAAAAAAA asks for addresses of all other devices on the network
(1516110467.329943) can0 18EEFFAA#BBBBBBBBBBBBBBBB --> Device 
BBBBBBBBBBBBBBBB says it has address 0xAA
(1516110468.568107) can0 18EEFFAA#AAAAAAAAAAAAAAAA --> Device 
AAAAAAAAAAAAAAAA claims address 0xAA. That is allowed because his device 
name has an higher priority.
(1516110468.576132) can0 18EEFFAB#BBBBBBBBBBBBBBBB --> Device 
BBBBBBBBBBBBBBBB claims another address.

Regards

Rémy

[1] https://github.com/kurt-vd/can-utils/blob/j1939-v6/jacd.c

Re: j1939 ACL

[Patrick Menschel]

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


> Here is an example of Address Claim sequence where device
> AAAAAAAAAAAAAAAA enters the network and device BBBBBBBBBBBBBBBB
> already have address 0xAA:
>
> (1516110467.317706) can0 18EAFFFE#00EE00 ------------> Device
> AAAAAAAAAAAAAAAA asks for addresses of all other devices on the network
> (1516110467.329943) can0 18EEFFAA#BBBBBBBBBBBBBBBB --> Device
> BBBBBBBBBBBBBBBB says it has address 0xAA
> (1516110468.568107) can0 18EEFFAA#AAAAAAAAAAAAAAAA --> Device
> AAAAAAAAAAAAAAAA claims address 0xAA. That is allowed because his
> device name has an higher priority.
> (1516110468.576132) can0 18EEFFAB#BBBBBBBBBBBBBBBB --> Device
> BBBBBBBBBBBBBBBB claims another address.
>
Hi,

it should be pointed out that address claiming has some caveats.

Like with the CAN ID the NAME with more leading zeros wins thus
"BBBBBBBBBBBBBBBB" looses to "AAAAAAAAAAAAAAAA" but there is also the
"arbitrary_address_capable" flag (the last bit) and "AAAAAAAAAAAAAAAA"
does not have that flag set.

Thus "AAAAAAAAAAAAAAAA" would claim the source address 0xAA regardless
of NAME priority.
"BBBBBBBBBBBBBBBB" has the "arbitrary_address_capable" flag set und can
solve the source address conflict by moving on to another source address.

IMHO in case you have a NAME with lower priority but without
"arbitrary_address_capable" flag, it would actually win against a higher
priority NAME that has the "arbitrary_address_capable" flag set.

Regards,
Patrick



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

Re: j1939 ACL

[Oleksij Rempel]

Hi

thank you all!

after playing with jacd i have a bit more questions:
- do any one already using kernel j1939? any suggestions or request for
changes?
- is jacd used for productions systems? is it enough to have it in the
usersapce? timing issues?
- how address and naming are synced between applications?

On 18.01.2018 12:49, Rémy Dziemiaszko wrote:
> Le 18/01/2018 à 10:40, Oleksij Rempel a écrit :
>> Hi all,
> Hi Oleksij,
>> what is the proper or expected way for j1939 ACL (address claiming)?
>>
>> Should it be done by automatically by kernel? Are there any existing
>> examples?
> The address claiming is not under the responsibility of the kernel but
> under responsibility of user space.
> You should have a look and play with the jacd daemon that implements the
> Address Claiming procedure for you (see [1]).
>> Is this a correct ACL message?
>> source address: for example 0x80
>> PGN: 0xee00
>> DATA: NAME
> Yes that is correct but do not forget to set the destination adresse to
> "everybody" (0xFF)
> 
> Here is an example of Address Claim sequence where device
> AAAAAAAAAAAAAAAA enters the network and device BBBBBBBBBBBBBBBB already
> have address 0xAA:
> 
> (1516110467.317706) can0 18EAFFFE#00EE00 ------------> Device
> AAAAAAAAAAAAAAAA asks for addresses of all other devices on the network
> (1516110467.329943) can0 18EEFFAA#BBBBBBBBBBBBBBBB --> Device
> BBBBBBBBBBBBBBBB says it has address 0xAA
> (1516110468.568107) can0 18EEFFAA#AAAAAAAAAAAAAAAA --> Device
> AAAAAAAAAAAAAAAA claims address 0xAA. That is allowed because his device
> name has an higher priority.   
> (1516110468.576132) can0 18EEFFAB#BBBBBBBBBBBBBBBB --> Device
> BBBBBBBBBBBBBBBB claims another address.
> 
> Regards
> 
> Rémy
> 
> [1] https://github.com/kurt-vd/can-utils/blob/j1939-v6/jacd.c
> 

Re: j1939 ACL

[Austin Schuh]

On Fri, Jan 19, 2018 at 3:14 AM, Oleksij Rempel <o.rempel@pengutronix.de> wrote:
> Hi
>
> thank you all!
>
> after playing with jacd i have a bit more questions:
> - do any one already using kernel j1939? any suggestions or request for
> changes?

We've got a userspace version which predates the kernel version.  At
this point, it's too hard for us to change.

> - is jacd used for productions systems? is it enough to have it in the
> usersapce? timing issues?

It's been a couple years since I read the relevant parts of the
standard in detail, but IIRC, you are supposed to send out a RQST for
the ACL to the source address you are trying to claim.  You then wait
1.25 seconds and send out your ACL.  You then have the address if
nobody sends back an ACL within 0.25 seconds.

Those timeouts are very long.  Userspace can hit them without any issue.

Austin

Re: j1939 ACL

[Kurt Van Dijck]

> 
> > Here is an example of Address Claim sequence where device
> > AAAAAAAAAAAAAAAA enters the network and device BBBBBBBBBBBBBBBB
> > already have address 0xAA:
> >
> > (1516110467.317706) can0 18EAFFFE#00EE00 ------------> Device
> > AAAAAAAAAAAAAAAA asks for addresses of all other devices on the network
> > (1516110467.329943) can0 18EEFFAA#BBBBBBBBBBBBBBBB --> Device
> > BBBBBBBBBBBBBBBB says it has address 0xAA
> > (1516110468.568107) can0 18EEFFAA#AAAAAAAAAAAAAAAA --> Device
> > AAAAAAAAAAAAAAAA claims address 0xAA. That is allowed because his
> > device name has an higher priority.
> > (1516110468.576132) can0 18EEFFAB#BBBBBBBBBBBBBBBB --> Device
> > BBBBBBBBBBBBBBBB claims another address.
> >
> Hi,
> 
> it should be pointed out that address claiming has some caveats.
> 
> Like with the CAN ID the NAME with more leading zeros wins thus
> "BBBBBBBBBBBBBBBB" looses to "AAAAAAAAAAAAAAAA" but there is also the
> "arbitrary_address_capable" flag (the last bit) and "AAAAAAAAAAAAAAAA"
> does not have that flag set.
> 
> Thus "AAAAAAAAAAAAAAAA" would claim the source address 0xAA regardless
> of NAME priority.
> "BBBBBBBBBBBBBBBB" has the "arbitrary_address_capable" flag set und can
> solve the source address conflict by moving on to another source address.
> 
> IMHO in case you have a NAME with lower priority but without
> "arbitrary_address_capable" flag, it would actually win against a higher
> priority NAME that has the "arbitrary_address_capable" flag set.

If I'm not mistaken, the 'arbitrary_address_capable' flag is the most
significant bit. Do note that j1939 is written as a little-endian
system. the 64bit NAME should be read little-endian too!

Kurt

Re: j1939 ACL

[Kurt Van Dijck]

> Hi
> 
> thank you all!
> 
> after playing with jacd i have a bit more questions:
> - do any one already using kernel j1939? any suggestions or request for
> changes?

A linux 3.10 version runs in production. Since then, a few changes were
requested and implemented.
Recently, the stack had some serious retesting, you will find the
latest state in my github (only a few minor commits from Marc's
version).

> - is jacd used for productions systems? is it enough to have it in the
> usersapce? timing issues?

Equally yes. Timing, as already said, isn't very critical.

> - how address and naming are synced between applications?

The kernel does not decide on claiming addresses, but tracks whatever
happens on the bus.
A node (source or destination) is identified by either a static address
or a 64bit NAME. In case of the static address, there is no need to
sync. In case of using the NAME, only the kernel needs the actual
address, hence the tracking of the bus.
For received packets, the kernel adds the actual address in the struct
sockaddr(_can).
For sent packets, the kernel avoids the need to sync addresses by using
NAME's and filling in the actual address just-in-time, right before the
CAN frame is sent, without the application (who is interested in the
NAME only) needing to know the latest state.

> On 18.01.2018 12:49, Rémy Dziemiaszko wrote:
> > Le 18/01/2018 à 10:40, Oleksij Rempel a écrit :
> >> Hi all,
> > Hi Oleksij,
> >> what is the proper or expected way for j1939 ACL (address claiming)?
> >>
> >> Should it be done by automatically by kernel? Are there any existing
> >> examples?
> > The address claiming is not under the responsibility of the kernel but
> > under responsibility of user space.
> > You should have a look and play with the jacd daemon that implements the
> > Address Claiming procedure for you (see [1]).
> >> Is this a correct ACL message?
> >> source address: for example 0x80
> >> PGN: 0xee00
> >> DATA: NAME
> > Yes that is correct but do not forget to set the destination adresse to
> > "everybody" (0xFF)
> > 

Kurt

Re: j1939 ACL

[Marc Kleine-Budde]

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

On 01/20/2018 10:28 PM, Kurt Van Dijck wrote:
>> after playing with jacd i have a bit more questions:
>> - do any one already using kernel j1939? any suggestions or request for
>> changes?
> 
> A linux 3.10 version runs in production. Since then, a few changes were
> requested and implemented.
> Recently, the stack had some serious retesting, you will find the
> latest state in my github (only a few minor commits from Marc's
> version).

Oleksij and Basti are now working on the j1939 kernel and userspace. I'd
like to have top of development on the linux-can-next/j1939 branch.
Which branch in your linux repo is the newest one?

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: 488 bytes --]

Re: j1939 ACL

[Kurt Van Dijck]

> On 01/20/2018 10:28 PM, Kurt Van Dijck wrote:
> >> after playing with jacd i have a bit more questions:
> >> - do any one already using kernel j1939? any suggestions or request for
> >> changes?
> > 
> > A linux 3.10 version runs in production. Since then, a few changes were
> > requested and implemented.
> > Recently, the stack had some serious retesting, you will find the
> > latest state in my github (only a few minor commits from Marc's
> > version).
> 
> Oleksij and Basti are now working on the j1939 kernel and userspace. I'd
> like to have top of development on the linux-can-next/j1939 branch.
> Which branch in your linux repo is the newest one?

can-next-j1939

It builds upon your can-next/j1939, so I invested into that.

> 
> 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: j1939 ACL

[Marc Kleine-Budde]

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

On 01/22/2018 07:26 PM, Kurt Van Dijck wrote:
>> On 01/20/2018 10:28 PM, Kurt Van Dijck wrote:
>>>> after playing with jacd i have a bit more questions:
>>>> - do any one already using kernel j1939? any suggestions or request for
>>>> changes?
>>>
>>> A linux 3.10 version runs in production. Since then, a few changes were
>>> requested and implemented.
>>> Recently, the stack had some serious retesting, you will find the
>>> latest state in my github (only a few minor commits from Marc's
>>> version).
>>
>> Oleksij and Basti are now working on the j1939 kernel and userspace. I'd
>> like to have top of development on the linux-can-next/j1939 branch.
>> Which branch in your linux repo is the newest one?
> 
> can-next-j1939
> 
> It builds upon your can-next/j1939, so I invested into that.

I've collected all patches up to

> a9ca675d555d (people/kurt-vd/can-next-j1939) can-j1939: fix foreign transport protocol sessions

regards,
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: 488 bytes --]