CAN test interface support

[hhenry01]

Description

• Resolves CAN Interface Support #52

Creates a vcan interface inside the docker container so we can test programs that utilize CAN without physical hardware.

Verification

• Commands work in dev container
• Commands work in deployment container
• Commands work on RPi

[hhenry01]

@patrick-5546 when you review this, can you do the following?

1. Pull and rebuild the container.
2. In one terminal, enter candump vcan0
3. Open a new terminal, enter cansend 012#12.34
4. Make sure that the first terminal where you ran candump updates after executing the command in the second terminal.
   The online sources I read mentioned needing to enable the vcan driver locally with sudo modprobe vcan before it will work. I unloaded the driver and it still worked which is not consistent with what the online resources said, so I might not have done it properly. If it works then it should work fine with WSL setups. No clue whether it will work on Mac or Arch though.

[patrick-5546]

• Will review once Overhaul dev container #61 is merged in
  • When testing I will merge with main

[patrick-5546]

• Merge with main again once Fix build dev image wokflow #77 is merged in
  • Will fix failing CI

[patrick-5546]

@patrick-5546 when you review this, can you do the following?

This is what I get running the commands on WSL:

ros@docker-desktop:/workspaces/sailbot_workspace$ candump vcan0
socket: Address family not supported by protocol
ros@docker-desktop:/workspaces/sailbot_workspace$ sudo modprobe vcan
sudo: modprobe: command not found
ros@docker-desktop:/workspaces/sailbot_workspace$ cansend 012#12.34
cansend - send CAN-frames via CAN_RAW sockets.

Usage: cansend <device> <can_frame>.

<can_frame>:
 <can_id>#{data}          for 'classic' CAN 2.0 data frames
 <can_id>#R{len}          for 'classic' CAN 2.0 data frames
 <can_id>##<flags>{data}  for CAN FD frames

<can_id>:
 3 (SFF) or 8 (EFF) hex chars
{data}:
 0..8 (0..64 CAN FD) ASCII hex-values (optionally separated by '.')
{len}:
 an optional 0..8 value as RTR frames can contain a valid dlc field
<flags>:
 a single ASCII Hex value (0 .. F) which defines canfd_frame.flags

Examples:
  5A1#11.2233.44556677.88 / 123#DEADBEEF / 5AA# / 123##1 / 213##311223344 /
  1F334455#1122334455667788 / 123#R / 00000123#R3

Are the commands supposed to be run inside or outside the dev container?

[patrick-5546]

To get vcan running on WSL: linux-can/can-utils#46 (comment)

[patrick-5546]

To get vcan running on WSL: linux-can/can-utils#46 (comment)

Wasn't able to get this working, plus it seems like a pain to compile a custom kernel. Can you take a look at this? https://github.com/wsovalle/docker-vxcan

[patrick-5546]

Is this still valid?

[hhenry01]

Reworked the PR based on recent container changes. If a vcan0 or can0 device is setup on the host then the start_container.sh script will set it up within the docker container. I could only test with vcan0 because we don't have a physical hardware setup atm.

[patrick-5546]

This is the output of the script the first time I run it, is this what is intended?

Error response from daemon: No such container: sailbot
Error: No such container: sailbot
Running: docker run -it --name sailbot -v /home/pcrei/git/tmp/sailbot_workspace/.devcontainer/deployment/../..:/workspaces/sailbot_workspace -w /workspaces/sailbot_workspace --cap-add=SYS_PTRACE --cap-add=NET_ADMIN --network=host --security-opt=seccomp:unconfined --security-opt=apparmor:unconfined --pull always ghcr.io/ubcsailbot/sailbot_workspace/base:can_support /bin/bash
./start_container.sh: line 44: ifconfig: command not found
./start_container.sh: line 48: ifconfig: command not found
can_support: Pulling from ubcsailbot/sailbot_workspace/base
Digest: sha256:2e2d4f79735a2f8293a2b582d04ff3970238732972eb0384db3c34201477bf10
Status: Image is up to date for ghcr.io/ubcsailbot/sailbot_workspace/base:can_support
root@docker-desktop:/workspaces/sailbot_workspace#

Also can you update the deployment README with the CAN stuff?

[hhenry01]

This is the output of the script the first time I run it, is this what is intended?

Error response from daemon: No such container: sailbot
Error: No such container: sailbot
Running: docker run -it --name sailbot -v /home/pcrei/git/tmp/sailbot_workspace/.devcontainer/deployment/../..:/workspaces/sailbot_workspace -w /workspaces/sailbot_workspace --cap-add=SYS_PTRACE --cap-add=NET_ADMIN --network=host --security-opt=seccomp:unconfined --security-opt=apparmor:unconfined --pull always ghcr.io/ubcsailbot/sailbot_workspace/base:can_support /bin/bash
./start_container.sh: line 44: ifconfig: command not found
./start_container.sh: line 48: ifconfig: command not found
can_support: Pulling from ubcsailbot/sailbot_workspace/base
Digest: sha256:2e2d4f79735a2f8293a2b582d04ff3970238732972eb0384db3c34201477bf10
Status: Image is up to date for ghcr.io/ubcsailbot/sailbot_workspace/base:can_support
root@docker-desktop:/workspaces/sailbot_workspace#

Also can you update the deployment README with the CAN stuff?

Not expected. I forgot that pulling the docker container can take a while, so the hacky 1 second delay to setup CAN won't work. Will need to rethink how to do it.

Also, what OS are you running that doesn't have ifconfig?

[patrick-5546]

Also, what OS are you running that doesn't have ifconfig?

ifconfig is deprecated, so it is not included in Ubuntu 22.04. Can use ip instead or sudo apt install net-tools -y to get it.

[hhenry01]

Updated the script and README. Uses ip a instead of ifconfig now. Instead of a set delay it now waits for the container to be in the "running" state before setting up CAN. And if for whatever reason the parent run container process dies unexpectedly then it can detect it, stop polling, and exit.

[hhenry01]

So I messed up and wasted a bunch of my time with that forking stuff. So long as --network=host is set and --cap-add=NET_ADMIN is set then any CAN device setup on the host will automatically be accessible.

[patrick-5546]

@patrick-5546 when you review this, can you do the following?

1. Pull and rebuild the container.
2. In one terminal, enter candump vcan0
3. Open a new terminal, enter cansend 012#12.34
4. Make sure that the first terminal where you ran candump updates after executing the command in the second terminal.
   The online sources I read mentioned needing to enable the vcan driver locally with sudo modprobe vcan before it will work. I unloaded the driver and it still worked which is not consistent with what the online resources said, so I might not have done it properly. If it works then it should work fine with WSL setups. No clue whether it will work on Mac or Arch though.

I forgot, are these commands supposed to be run inside our outside the container?

[hhenry01]

@patrick-5546 when you review this, can you do the following?

1. Pull and rebuild the container.
2. In one terminal, enter candump vcan0
3. Open a new terminal, enter cansend 012#12.34
4. Make sure that the first terminal where you ran candump updates after executing the command in the second terminal.
   The online sources I read mentioned needing to enable the vcan driver locally with sudo modprobe vcan before it will work. I unloaded the driver and it still worked which is not consistent with what the online resources said, so I might not have done it properly. If it works then it should work fine with WSL setups. No clue whether it will work on Mac or Arch though.

I forgot, are these commands supposed to be run inside our outside the container?

Inside the container. Since opening multiple terminals inside the container is a bit annoying, run candump vcan0 & instead so you don't have to open a new terminal. You must have vcan0 setup on your host computer for this to work.

[hhenry01]

Tested on the Rpi and it works. I also added setup_boot.sh which I intend to use to configure any scripts/programs that need to run on boot. Doing it this way is way easier to manage than how I did services with Raye.