State of ISO-TP in SocketCAN?

State of ISO-TP in SocketCAN?

[Tobias Schmitt]

Hi

I work on a project using a beaglebone black and it's CAN interface via SocketCAN. At first I want to thank you all for this, it's working incredibly stable! Since our payload of data will be much higher soon (about 50-100 bytes in one package) we want to use ISO-TP. The thing is, that the information about the state of the ISO-TP implementation of SocketCAN is very rare and provides some contrary information. I hope this mailinglist can bring some clarity to my confused mind.

At first my target device where I try to run can-isotp:
Beaglebone Black Rev B / C
Beaglebone Ubuntu 14.04.02 image from http://elinux.org/BeagleBoardUbuntu
uname: Linux bone 3.8.13-bone63 #1 SMP Mon Aug 11 23:03:02 UTC 2014 armv7l armv7l armv7l GNU/Linux

What I have done:
0: lots of internet searches

1: read Documentation/networking/can.txt:
It says that one just has to use the ISOTP protocol when initializing the socket.
I downloaded the can-utils repo and tried to use isotpsend for testing purposes. the isotp programs exit with "socket: protocol not supported".

2: Then I found an old post by Oliver Hartkopp on this mailinglist (http://comments.gmane.org/gmane.linux.can/2135) which says that one has to use kernelmodule can-isotp instead of can-raw. I also cannot find any option for compiling a can-isotp module on the 3.8 kernel in 'make menuconfig'. Then I found the can-isotp-modules repo in Oliver Hartkopps github account (http://github.com/hartkopp/can-isotp-modules) which I cannot build because of missing definitions (NETIF_F_NO_CSUM in net/can/slcan.c). Since the repos description says that this Repo is obsolete and there's a Alpha-Warning in the README.isotp file, i assume this is not the right repository to use anyway.

And now I'm very confused and maybe on a complete wrong track. Is there a official and stable way to use ISOTP as a protocol in SocketCAN, and where can I find it? Is it still in development and can I help with it somehow?

Best regards
Tobias

PS: I hope this mail provides enough information and is not too text heavy, since it's my first question on a official mailinglist. If not, I apologize!

Re: State of ISO-TP in SocketCAN?

[Oliver Hartkopp]

On 22.07.2015 11:45, Tobias Schmitt wrote:

> And now I'm very confused and maybe on a complete wrong track.

No, you aren't :-)

> Is there a official and stable way to use ISOTP as a protocol in SocketCAN, and where can I find it?

https://github.com/hartkopp/can-isotp-modules

> Is it still in development and can I help with it somehow?

Yes. It is still under development. Not that much - but it is.

After clonig the above git repo just do

cd can-isotp-modules/net/can
./make_isotp.sh

and then as user 'root'

modprobe can
insmod ./can-isotp.ko

Or you might copy can-isotp.ko to your local modules tree

cp can-isotp.ko /lib/modules/`uname -r`/kernel/net/can/
depmod -A


Please remember to take care of the tx-queue-len referenced in README.isotp

Regarding the state of the ISO-TP implementation:

The implementation is somehow stable. The latest changes were added to 
implement the ISO15765-2:2015 protocol which can use CAN FD frames.
The ISO-TP (segmentation) protocol itself is working properly.

The reason why isotp.c is not is mainline Linux is that I'm unsure with the 
final socket API and probably some transmission control to make the hack with 
the tx-queue-len obsolete.

With ISO-TP for CAN FD the PDU size is not limited to 4095 byte but you can 
specify PDUs up to 4GB (2^32-1). Currently you can read write a complete PDU 
buffer - but when having e.g. a 128 kbyte PDU creating a buffer of such size 
in kernel looks wrong. So maybe some improved buffering as to be implemented 
or some throttling/control when reading/writing the PDU from/to the socket.

So if you have ideas about how to solve these final issues I definitely would 
appreciate to discuss them here :-)

Best regards,
Oliver

Re: State of ISO-TP in SocketCAN?

[Tobias Schmitt]

> After clonig the above git repo just do
> 
> [...]

I completely missed the additional makefiles in subfolders. Thank you! Everything works fine now!

> 
> [...]
> The ISO-TP (segmentation) protocol itself is working properly.

Perfect. ISO-TP itself is the main point for us since we do not use CAN FD.

But I have one more question: I tested a lot with socketcand and the isotp utilities in can-utils today. In all of the programs you have to define the source and destination IDs on the can bus very static.
In our application we use extended adressing, the master device on CAN has a specific id (0x00) and has to listen to the slave devices (which need to have different IDs for adressing).

So I either need to open a socket for every slave device, or in case of possible wildcards the program call could be:

./isotprecv -s * -d 0 -x 0:**

Is there any possibility to use the SocketCAN isotp protocol the "wildcard"-way I intend? I could also pass the information about the sender device into the payload of the isotp message. But why is there extended adressing then?

> So if you have ideas about how to solve these final issues I definitely would appreciate to discuss them here :-)

I have to add that I'm just a cs student in my bachelor internship and might be not the right person to discuss this topics. At the moment I'm studying the Linux Device Drivers 4th Edition book and also the whole SocketCAN project. But maybe in a few weeks I might have an opinion about it :-).

Best regards
Tobias

Re: State of ISO-TP in SocketCAN?

[Oliver Hartkopp]

Hi Tobias,

On 23.07.2015 20:02, Tobias Schmitt wrote:

> But I have one more question: I tested a lot with socketcand and the isotp utilities in can-utils today. In all of the programs you have to define the source and destination IDs on the can bus very static.
> In our application we use extended adressing, the master device on CAN has a specific id (0x00) and has to listen to the slave devices (which need to have different IDs for adressing).
>
> So I either need to open a socket for every slave device, or in case of possible wildcards the program call could be:
>
> ./isotprecv -s * -d 0 -x 0:**
>
> Is there any possibility to use the SocketCAN isotp protocol the "wildcard"-way I intend? I could also pass the information about the sender device into the payload of the isotp message. But why is there extended adressing then?

No, intentionally not.

Whenever you have a transport protocol channel for segmented PDUs you have to 
provide two CAN-IDs to match FF/CF and FC messages on the 'virtual channel' on 
the bus.

The extended addressing is just some kind of 'extension for the CAN-ID'.

E.g. If you would have a wildcard, to what address should you send the FC 
then? You would need to implement some connection tracking - even when you are 
communicating simultaneously to different nodes.

The functional addressing does not need segmentation, so you can create and 
send functional PDUs by 'handmade' ISO-TP CAN frames via CAN_RAW sockets.

When your application needs to 'listen' on several transport channels you may 
create as much sockets as you need and read from them simultaneously e.g. with 
the select() syscall.

Does that help for your use-case? Can you tell about your use-case?

Regards,
Oliver

Re: State of ISO-TP in SocketCAN?

[Tobias Schmitt]

Hi Oliver

> No, intentionally not.
> 
> Whenever you have a transport protocol channel for segmented PDUs you have to provide two CAN-IDs to match FF/CF and FC messages on the 'virtual channel' on the bus.
> 
> The extended addressing is just some kind of 'extension for the CAN-ID'

Okay, I thought it's purpose is to use it like sender and receiver adresses.

> E.g. If you would have a wildcard, to what address should you send the FC then? You would need to implement some connection tracking - even when you are communicating simultaneously to different nodes.

Yes, especially when communication simultaneously. I will try to explain how I implement the ISO-TP extended adressing in our project at the moment (Application Level with can_raw on the Beaglebone Black and AVR-C implementation on AT90CAN). I have to add that we don't use CAN for diagnostics, but for real device-to-device communication on the bus. 

We assume there are 3 Clients on the Bus, 1 Master (Beaglebone) and 2 Slaves (AT90CAN). Every device has one unique ID (Master 0, Slaves 0-245, the rest for special purpose).
can_id = sender_id
data[0] = receiver_id (extended adressing)
data[1] ... ISOTP and Data.

For example (I'm not at home so maybe there are a few mistakes with data lengths or IDs, but I think the main point is clear):
Master (0x00) sends to slave (0x14)
syntax -> canid - data[0] data[1] ....

Singleframe master to slave:
0x00 - 0x01 0x04 0xDE 0xAD 0xBE 0xEF

ISOTP with FF, CF and FC
<master: send FF to 0x01 with length 12 byte>
0x00 - 0x14 0x10 0x0B 0xDE 0xAD 0xBE 0xEF 0xDE
<slave: FC frame from slave to master>
0x14 - 0x00 0x30 0x09 0x00
<master: CFs... >
0x00 - 0x14 0x21 0xAD 0xBE 0xEF 0xDE 0xAD 0xBE
0x00 - 0x14 0x22 0xEF

This is how I understood extended adressing. On the Linux side I'm implementing a daemon which acts similar to the socketcand and processes isotp on appilcation level and puts the content of the isotp messages on a TCP Port. I have to add, that this "mechanism" of forwarding on a TCP port evolved in my head while I was developing. I didn't know about socketcand at this time.

I think I will finish this daemon in the following week and upload it to github (since it's not critical to our product, my boss is absolutely willing to commit it into OSS community under a free licence - as well as the relevant librarys for at90can devices I wrote).


> The functional addressing does not need segmentation, so you can create and send functional PDUs by 'handmade' ISO-TP CAN frames via CAN_RAW sockets.
> 
> When your application needs to 'listen' on several transport channels you may create as much sockets as you need and read from them simultaneously e.g. with the select() syscall.
> 
> Does that help for your use-case? Can you tell about your use-case?

I must admit that I'm not really sure if I understood everything you wrote. So using the socket-level iso-tp implementation with our project (as I explained above) is not possible? The exact usecase is a system for door accesscontrol with iButtons which is expendable over the CAN bus. This bus exists only inside the fusebox / cabinet and handles the communication between the master server and the slave extensions. Since I'm developing with SHA1 iButtons for higher security a raw can message is not enough anymore and we need a more complex protocol, so my first idea was iso-tp.

best regards,
Tobias

Re: State of ISO-TP in SocketCAN?

[Oliver Hartkopp]

On 25.07.2015 17:11, Tobias Schmitt wrote:

>> Whenever you have a transport protocol channel for segmented PDUs you have to provide two CAN-IDs to match FF/CF and FC messages on the 'virtual channel' on the bus.
>>
>> The extended addressing is just some kind of 'extension for the CAN-ID'
>
> Okay, I thought it's purpose is to use it like sender and receiver adresses.
>

Probably if you compare it to sender/receiver addresses inside a VPN tunnel 
(which is defined by the two CAN-IDs).

>> E.g. If you would have a wildcard, to what address should you send the FC then? You would need to implement some connection tracking - even when you are communicating simultaneously to different nodes.
>
> Yes, especially when communication simultaneously. I will try to explain how I implement the ISO-TP extended adressing in our project at the moment (Application Level with can_raw on the Beaglebone Black and AVR-C implementation on AT90CAN). I have to add that we don't use CAN for diagnostics, but for real device-to-device communication on the bus.
>
> We assume there are 3 Clients on the Bus, 1 Master (Beaglebone) and 2 Slaves (AT90CAN). Every device has one unique ID (Master 0, Slaves 0-245, the rest for special purpose).
> can_id = sender_id
> data[0] = receiver_id (extended adressing)
> data[1] ... ISOTP and Data.
>
> For example (I'm not at home so maybe there are a few mistakes with data lengths or IDs, but I think the main point is clear):
> Master (0x00) sends to slave (0x14)
> syntax -> canid - data[0] data[1] ....
>
> Singleframe master to slave:
> 0x00 - 0x01 0x04 0xDE 0xAD 0xBE 0xEF
>
> ISOTP with FF, CF and FC
> <master: send FF to 0x01 with length 12 byte>
> 0x00 - 0x14 0x10 0x0B 0xDE 0xAD 0xBE 0xEF 0xDE
> <slave: FC frame from slave to master>
> 0x14 - 0x00 0x30 0x09 0x00
> <master: CFs... >
> 0x00 - 0x14 0x21 0xAD 0xBE 0xEF 0xDE 0xAD 0xBE
> 0x00 - 0x14 0x22 0xEF
>
> This is how I understood extended adressing.

No this not extended addressing. You are mixing the addressing defined by the 
(outer) CAN-IDs with the (inner) extended addressing (which needs two fixed 
CAN-IDs).

Your addressing scheme is interesting - but unfortunately it has nothing to do 
with ISO-TP addressing ;-)

> On the Linux side I'm implementing a daemon which acts similar to the socketcand and processes isotp on appilcation level and puts the content of the isotp messages on a TCP Port. I have to add, that this "mechanism" of forwarding on a TCP port evolved in my head while I was developing. I didn't know about socketcand at this time.
>
> I think I will finish this daemon in the following week and upload it to github (since it's not critical to our product, my boss is absolutely willing to commit it into OSS community under a free licence - as well as the relevant librarys for at90can devices I wrote).

Very good attitude - you should spend him a beer for that :-)

>> The functional addressing does not need segmentation, so you can create and send functional PDUs by 'handmade' ISO-TP CAN frames via CAN_RAW sockets.
>>
>> When your application needs to 'listen' on several transport channels you may create as much sockets as you need and read from them simultaneously e.g. with the select() syscall.
>>
>> Does that help for your use-case? Can you tell about your use-case?
>
> I must admit that I'm not really sure if I understood everything you wrote.

Forget about it - now that I know your idea it has no value for you.

> So using the socket-level iso-tp implementation with our project (as I explained above) is not possible?

No - unfortunately not.

Even if you would do some hacking to implement your special addressing scheme 
you would need to have n different sockets (== state machines) on each host to 
talk to the n different nodes with segmented PDUs.

And if you have created n sockets anyway you might think about 29bit CAN-IDs 
where you can encode the master/slave IDs into the CAN-IDs, e.g.

0x00001400 tx_id
0x00000014 rx_id

This would work with the iso-tp implementation then.

> The exact usecase is a system for door accesscontrol with iButtons which is expendable over the CAN bus. This bus exists only inside the fusebox / cabinet and handles the communication between the master server and the slave extensions. Since I'm developing with SHA1 iButtons for higher security a raw can message is not enough anymore and we need a more complex protocol, so my first idea was iso-tp.

If you just need an authentication method for your CAN messages there's the 
MaCAN (Message authenticated CAN) project probably something for you:

https://github.com/CTU-IIG/macan

The idea behind MaCAN is some exchange of session keys between the nodes at 
system startup and then communicate in single CAN frames with a 32/24/16 bit MAC.

https://github.com/CTU-IIG/macan/blob/master/doc/macan.pdf

Best regards,
Oliver