You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Goal:
I am trying to run signalk-server in a Docker container with normal brigded networking in order to preserve isolation. In order to use NMEA2000 via native socketcan, the can interface(s) need to be routed via virtual vxcan kernel module and can-gw (see https://www.lagerdata.com/articles/forwarding-can-bus-traffic-to-a-docker-container-using-vxcan-on-raspberry-pi). Can interfaces are basically network interfaces which aren't published to containers running in bridge networking mode.
Problem:
Virtual CAN interface needs to be moved to the network namespace of the running container, which means that the container must be running before the can interface can be made available within the container runtime. Currently, signalk-server only loads the connections when starting the server, so there's currently no easy way to reinitialize connections once the can interface has been brought up.
Suggestion:
Introduce automatic (perhaps configurable) retry for establishing can connections.
The text was updated successfully, but these errors were encountered:
Goal:
I am trying to run signalk-server in a Docker container with normal brigded networking in order to preserve isolation. In order to use NMEA2000 via native socketcan, the can interface(s) need to be routed via virtual vxcan kernel module and can-gw (see https://www.lagerdata.com/articles/forwarding-can-bus-traffic-to-a-docker-container-using-vxcan-on-raspberry-pi). Can interfaces are basically network interfaces which aren't published to containers running in bridge networking mode.
Problem:
Virtual CAN interface needs to be moved to the network namespace of the running container, which means that the container must be running before the can interface can be made available within the container runtime. Currently, signalk-server only loads the connections when starting the server, so there's currently no easy way to reinitialize connections once the can interface has been brought up.
Suggestion:
Introduce automatic (perhaps configurable) retry for establishing can connections.
The text was updated successfully, but these errors were encountered: