Missing CAN J1939 support and vcan0 in latest docket image.

[menschel]

Hi,

I recently found that J1939 is not compiled into the latest docker image.

https://gitlab.com/Menschel/socketcan/-/jobs/1315560259

This may be caused by not having

linux/can/j1939.h

available at compile time.

The above mentioned tox tests runs smoothly on a raspberry pi with natively compiled Python 3.9.5.

Last but not least, It would be great if the docker images would have vcan0 enabled by default.
I'm using vcan0 for tests and coverage in pipeline.

Thank you very much.

[tianon]

Can you provide a simple reproducer, perhaps in the form of a single docker run one-liner that imports a module which currently fails but will succeed if we have the appropriate header available during compilation?

[menschel]

Concerning the missing J1939 support:

I don't use docker directly but via gitlab-ci
image: python:latest
Reproducer would be something like this.

python -i
socket.J1939_NO_NAME

which will then raise Attribute Error

Actually it would be this unit test.
The build depends on the specific header file include which ideally should be there after kernel version 5.4 . Raspberry Pi kernel got that header file 4 weeks ago, although on kernel version 5.10 since a few month.

Concerning the vcan0.
It is actually a workaround to test CAN related stuff in an unprivileged mode like the public gitlab runners.
it basically comes down to this.

sudo ip link add type vcan
sudo ip link set vcan0 up

I'm not sure if this really is the philosophers stone. It would just be nice to have.
My prediction is that there will be a lot of python applications targeting CAN bus in the near future because Kernel support is mature on almost every embedded platform and CAN Hardware for Raspberry Pi became dead-cheap lately.

[yosifkit]

It looks like j1939.h doesn't exist until Debian Bullseye which has not migrated to stable yet, so we don't have a python image based on it.

https://packages.debian.org/search?suite=buster&searchon=contents&keywords=j1939.h
https://packages.debian.org/search?suite=bullseye&searchon=contents&keywords=j1939.h

If python were compiled with this support, would it have issues running for users still on kernels earlier than 5.10?

[menschel]

The safe threshold should be >5.4.y . Technically kernel raises an OSError Protocol Not Supported regardless of if the constants are compiled into python or not. It cannot do harm on it's own IMO.

[menschel]

Just checked, I was active in raspbian repo 25 days ago, so I don't understand how this header file did not make it into bullseye while raspbian buster already had it.
raspberrypi/linux#4346

[yosifkit]

Just checked, I was active in raspbian repo 25 days ago, so I don't understand how this header file did not make it into bullseye while raspbian buster already had it.
raspberrypi/linux#4346

It is in Bullseye, but Bullseye is not yet fully released so we haven't made an image based upon it. When it is released, we will add an image.

---

For vcan devices, that is likely just missing capabilities (probably --cap-add NET_ADMIN). But I don't know if things like gitlab runners allow a cap-add. So nothing we can do in the image.

$ docker run -it --rm debian
Unable to find image 'debian:latest' locally
latest: Pulling from library/debian
Digest: sha256:acf7795dc91df17e10effee064bd229580a9c34213b4dba578d64768af5d8c51
Status: Downloaded newer image for debian:latest
root@92473bfa43af:/# ip link add type vcan
RTNETLINK answers: Operation not permitted
root@92473bfa43af:/# 

[menschel]

Ok, thank you for the explanation.
Guess I'll have to set up my own runner after all.

[tianon]

Fixed by #633 👍