containers / containers/netavark
[RFE] handling of CAN networks
- Dominant language
- Rust
- Stars
- 794
- Forks
- 161
- Avg merge
- 8d 17h
- Merged PRs (30d)
- 3
Description
Hi. This is a bit peculiar so feel free to convert this to a discussion, but I feel like issues would get more visibility if someone looks for this in the future, as I think it'll take a while to get something out of this (I won't have time to contribute much short term)
## Background
On embedded devices with CAN networks, there is no way to pass a can interface to a container without using network=host.
It'd be great to have a way of doing something with it.
This can be tested with the vcan module that allows creating virtual CAN interfaces without hardware:
```
# ip link add dev vcan0 type vcan
# ip link set vcan0 up
(in one shell, commands from can-utils package)
# candump vcan0
vcan0 123 [4] DE AD BE EF
(in another shell)
# cansend vcan0 123#DEADBEEF
```
## Possible solutions
### Just move the interface
The simplest way I could work around the issue is just to pass the vcan interface to a container; that's quite crippling:
- cannot share between multiple containers (this might actually be for the best?)
- if the container stops when the interface is in the network namespace, that interface is lost forever? I found not way of recreating a can interface for real hardware..
This has the advantage of being scriptable out of netavark somewhat realistically for the time being
```
# ip netns list
netns-55c02473-599c-9671-d5b9-1f0619e1ff8b (id: 0)
# ip link set vcan0 up
# ip link set vcan0 netns netns-55c02473-599c-9671-d5b9-1f0619e1ff8b
```
### vxcan tunnels
I think it'd make more sense to use vxcan tunnels which are basically like veth for can: it creates a pair of interfaces that communicate with each other accross namespaces
```
# ip link add vxcan-container netns netns-55c02473-599c-9671-d5b9-1f0619e1ff8b type vxcan peer name vxcan-host
```
One can then use CAN_GW to forward traffic from vxcan-host to the real can interface, as described in this talk:
https://wiki.automotivelinux.org/_media/agl-distro/agl2018-socketcan.pdf
Ideally we could create a podman network type with a can interface as parent and have netavark create vxcan interfaces and handle the can_gw config when containers are created; but that'll take a bit of work.
## tl;dr
There's probably quite a lot of work to do and I don't have time to help much short term, but I'm opening this to track any future work about it, and if stars align I might contribute later if there's an agreement on the way forward.
Contributor guide
Assessment
This issue has not been assessed yet.