RFC: Add basic support for local and remote CAN

[stoupa-cz]

Description

This is a draft of basic CAN support. It is in RFC, as there are open questions, missing docs and tests, and moreover, it needs more testing. We plan to use it to remotely access the satellite's telemetry buses during development.

Local and remote CAN resources are added. Additionally, a simple CAN driver is added. The driver has very limited capabilities. For local use, it can set up the interface and tell you the interface name. For remote use, it establishes a transparent tunnel using cannelloni. With it, you can use the local virtual CAN interface. All the traffic is routed to the real interface on the other end.

Be aware, as cannelloni states in its doc:

cannelloni is not suited for production deployments. Use it only in environments where packet loss is tolerable. There is no guarantee that CAN frames will reach their destination at all and/or in the right order.

I tested in the lab only. We will test it in production during September/October.

I see the main blocker: it requires root privileges on both sides (exporter and client; even for local use). What is the preferred way to handle privileged access? May we use labgrid-raw-interface?

Checklist

• Solve the need for root privileges
• More robust handling of cannelloni processes
• Rebase on master
• Documentation
  • The arguments and description in doc/configuration.rst have been updated
  • Add a section on how to use the feature to doc/usage.rst
  • Man pages have been regenerated
• Write tests
• Test in production

Reference issues: #1287 and #1289

This is a part of my work at VZLU AEROSPACE.

[hundeboll]

Hi @stoupa-cz

Thanks for working on this. I've been experimenting with [socketcand](https://github.com/linux-can/socketcand). It has the same limitation as cannelloni (root on both ends for vcan setup), but the protocol is pretty simple, so the client side can be implemented as python functions in the labgrid driver. This should be enough for tests with limited CAN traffic.

[stoupa-cz]

Hi @stoupa-cz

Thanks for working on this. I've been experimenting with [socketcand](https://github.com/linux-can/socketcand). It has the same limitation as cannelloni (root on both ends for vcan setup), but the protocol is pretty simple, so the client side can be implemented as python functions in the labgrid driver. This should be enough for tests with limited CAN traffic.

Hi @hundeboll ,

Thanks a lot for the information. This is a clever way. We are using the cannelloni. Root privileges are manageable on exporters; however, handling them on clients (e.g., developers' computers) is cumbersome.

I'm currently trying a helper like labgrid-raw-interface. I will push it when ready.

Anyway, as pointed out in #1289, we may support both backends (you can see that issue for more information about SW selection).

BTW, is your experiment available anywhere?

[hundeboll]

Hi @stoupa-cz
Thanks for working on this. I've been experimenting with [socketcand](https://github.com/linux-can/socketcand). It has the same limitation as cannelloni (root on both ends for vcan setup), but the protocol is pretty simple, so the client side can be implemented as python functions in the labgrid driver. This should be enough for tests with limited CAN traffic.

Hi @hundeboll ,

Thanks a lot for the information. This is a clever way. We are using the cannelloni. Root privileges are manageable on exporters; however, handling them on clients (e.g., developers' computers) is cumbersome.

I'm currently trying a helper like labgrid-raw-interface. I will push it when ready.

I see. I think the cannelloni protocol would be just as easy to implement in python though.

Just like you've done, my plan was to create a resource similar to SerialPortExport, which would start socketcand on a NetworkInterface resource (i.e. can0).

The driver could then connect to the resource similar to SerialDriver. Or do regular socket operations on local interfaces instead of socketcand procotol communication. This still doesn't solve the root requirement for configuration of local interfaces, but as a start we could leave that to the administrator (e.g. using systemd.network(5) configuration).

Anyway, as pointed out in #1289, we may support both backends (you can see that issue for more information about SW selection).

BTW, is your experiment available anywhere?

It still resides in our internal repository, but I've attached it here. It uses SSH forward to talk with socketcand on the target though, as it is just used for communicating with a CAN based service in our bootstrap rootfs, but that's easy to change.