containers / containers/netavark

[RFE] handling of CAN networks

Open
#940 4 comments 0 reactions 0 assignees View on GitHub
RFE
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.