Closed jthomas-geotab closed 6 months ago
I gather this is CONFIG_CAN_RAW et al.
Yes, I think this is the minimum useful set: CONFIG_CAN CONFIG_CAN_RAW CONFIG_CAN_BCM CONFIG_CAN_VCAN CONFIG_CAN_SLCAN CONFIG_CAN_DEV CONFIG_CAN_CALC_BITTIMING
Would also be good to get support for some CAN USB adapters. I am using CONFIG_CAN_PEAK_USB
In the interim between now and when those configs hypothetically became enabled in a stock release, you can try rolling your own kernel and see if it is viable.
Would also be good to get support for some CAN USB adapters
USB passthrough at the kernel level would be another kettle of fish.
Oh cool, I didn't know you could run your own custom kernel with WSL 2!
You can also compile just the modules and insmod
them, which is sometimes a safer approach because you are less likely to "break something else" in the process. YRMV caveats apply; custom kernels isn't really a supported scenario (if there is such a thing) but people have had some luck.
For anyone trying this, these were my steps:
$ git clone https://github.com/microsoft/WSL2-Linux-Kernel
$ cd WSL2-Linux-Kernel
$ git checkout `uname -r`
$ cat /proc/config.gz | gunzip > .config
$ make prepare modules_prepare
$ make menuconfig # select vcan and can here
$ make modules
# make modules_install
# modprobe vcan
# ip link add dev vcan0 type vcan
# ip link set up vcan0
# apt install can-utils
So far so good, however, candump does not cooperate: socket: Address family not supported by protocol
This is an interesting effect:
# modprobe can_raw --> wsl dies
Update: building your own kernel for WSL works! You can enable CONFIG_CAN_VCAN=y
and use it.
I opened a proposal here:
https://github.com/microsoft/WSL2-Linux-Kernel/pull/242/files
git checkout `uname -r`
Did not work for my current kernel (
5.4.72-microsoft-standard-WSL2
), but found the correct branch here: https://github.com/microsoft/WSL2-Linux-Kernel/releases/tag/linux-msft-5.4.72
linux-msft-5.4.72
but unfortunately, I did not get it installed with your steps, still getting:
$ modprobe vcan
modprobe: FATAL: Module vcan not found in directory /lib/modules/5.4.72-microsoft-standard-WSL2
maybe I have other issues with my install?
$ ll /lib/modules
total 44
drwxr-xr-x 11 root root 4096 Mar 20 09:32 ./
drwxr-xr-x 21 root root 4096 Dec 23 21:53 ../
drwxr-xr-x 2 root root 4096 Sep 4 2020 4.15.0-106-generic/
drwxr-xr-x 2 root root 4096 Sep 4 2020 4.15.0-112-generic/
drwxr-xr-x 2 root root 4096 Sep 4 2020 4.15.0-115-generic/
drwxr-xr-x 2 root root 4096 Sep 28 08:36 4.15.0-117-generic/
drwxr-xr-x 2 root root 4096 Sep 28 11:58 4.15.0-118-generic/
drwxr-xr-x 2 root root 4096 Nov 24 23:43 4.15.0-124-generic/
drwxr-xr-x 3 root root 4096 Mar 9 22:24 4.15.0-136-generic/
drwxr-xr-x 3 root root 4096 Mar 20 09:14 4.15.0-139-generic/
drwxr-xr-x 3 root root 4096 Mar 20 09:35 5.4.72-microsoft-standard-WSL2+/
The problem is in the +
. After mv 5.4.72-microsoft-standard-WSL2+ 5.4.72-microsoft-standard-WSL2
I ran into the next problem:
# modprobe vcan
modprobe: ERROR: could not insert 'vcan': Invalid argument
$ dmesg | tail
[649362.799943] vcan: disagrees about version of symbol kfree_skb
[649362.799944] vcan: Unknown symbol kfree_skb (err -22)
... # and many more
# modprobe --dump-modversions 5.4.72-microsoft-standard-WSL2/kernel/drivers/net/can/vcan.ko
0x61040109 module_layout
...
0xf8604075 kfree_skb
...
I do not know what to compare it against, but I guess there are differences in the binary layout between the tagged and released version.
I should probably walk back the "sometimes a safer approach" comment in the sense it does introduce the potential for a symbol version conflict. There was no conflict last I tried checking out the correct linux-msft-[45].x.y
, but can't strictly confirm or deny linux-msft-5.4.72
results in a conflict either, because I haven't tried. If in doubt, compile the modules you want in-kernel with =y
.
I left the modules as =m
, put +
back in place in lib/modules/5.4.72-microsoft-standard-WSL2+
and compiled/set up the kernel with:
$ make -j8 # quick after modules are compiled
$ cp vmlinux /mnt/c/Users/<me>/
rem Windows: create C:\Users\<me>\.wslconfig:
[wsl2]
kernel=C:\\Users\\<me>\\vmlinux
cmd> wsl --shutdown
cmd> wsl
$ uname -r
5.4.72-microsoft-standard-WSL2+
# modprobe vcan # works!
@microsoft can we get this as a default feature?
+1, my organization also develops embedded Linux projects and would benefit greatly from this feature as a default!
+1, my organization also develops embedded Linux projects
+1, my organization also develops embedded Linux projects and work from WSL2 when developing. I Would love this.
Thanks for all the information! Yes, I was able to follow the instructions and compile the vcan kernel module and also start the new kernel. But still when I execute candump I get the following error:
$ candump vcan0
socket: Address family not supported by protocol
What am I missing?
Please add can support !
Thanks for all the information! Yes, I was able to follow the instructions and compile the vcan kernel module and also start the new kernel. But still when I execute candump I get the following error:
$ candump vcan0 socket: Address family not supported by protocol
What am I missing?
Hi Deakon997,
This message appears in case you didn't load can
and can-raw
modules from SocketCAN:
sudo modprobe can
sudo modprobe can-raw
sudo modprobe vcan
This way you should be able to load vcan without any complaints.
To end up with success, I had to recompile also the kernel itself and swap the stock WSL2 kernel with the newly compiled one to get rid of the following message:
modprobe vcan
modprobe: ERROR: could not insert 'vcan': Invalid argument
So the additional steps to windelbouwman's guide are:
$ make -j $(nproc)
$ sudo make install
Then copy the kernel to Windows:
cp vmlinux /mnt/c/Users/<yourwindowsloginname>/
Create .wslconfig file:
vim /mnt/c/Users/<yourwindowsloginname>/.wslconfig
with the content:
[wsl2] kernel=C:\\Users\\<yourwindowsloginname>\\vmlinux
and finally restart your WSL:
exit
wsl --shutdown
wsl
This way I finally added SocketCAN support to WSL.
@ak-aptiv 🥇 Hello ak-aptiv
Hi Deakon997, This message appears in case you didn't load
can
andcan-raw
modules from SocketCAN:sudo modprobe can sudo modprobe can-raw sudo modprobe vcan
Thank you very much! That made my day! Partey! vcan support is now working for me!
@jiayali-ms closed https://github.com/microsoft/WSL2-Linux-Kernel/pull/242 indicating that pull requests are not accepted there, and to file issues here - but we can't issue a PR against a kernel config here?
Per discussion on that PR - even though WSL2 has no hardware support, enabling the vcan (virtual CAN) support and its dependencies at a minimum allows for things such as: Local testing of socketCAN software talking over vcan only Communicating with real hardware using socketCAN tunnelling solutions such as: Cannelloni - https://github.com/mguentner/cannelloni socketcand - https://github.com/linux-can/socketcand
But these userspace solutions can't be used without kernel support for vcan at a minimum
@Entropy512 VCAN support in WSL would be a great addition.
+1 for default support for vcan in WSL2, would love to be able to locally develop/test on a virtual CAN network
Oof, not having SocketCAN is kind of a deal breaker for me.
If you're on Win10, you need to recompile the kernel anyway to support USB devices.
Since the last discussion on this topic, much of the rationale for not supporting SocketCAN support (no support for external hardware) in the WSL2 kernel has become invalid: https://docs.microsoft.com/en-us/windows/wsl/connect-usb
WSL2 now supports USB devices. CAN support should be enabled as part of this effort. (I'll be testing an EMS CPC-USB later today with a custom kernel)
No SocketCAN => bye-bye Windows
+1 I need socketCAN with usb2can too!
A little update compared to my previous post: EMS CPC-USB converters don't play nice with usbip Devices that use the gs_usb driver work quite well though
I try to add gs_usb can device kernel module and it works fine. But I cant find any can network in docker container even with --network=host (it works fine in raw ubuntu). It seems like there is something still missing. Anybody knows why?
CAN and docker is a whole other can of worms likely unrelated to WSL. https://github.com/wsovalle/docker-vxcan may be useful, I've been looking into it but haven't had an opportunity to actually try it out.
@windelbouwman instruction worked perfectly, even got it to work with kvaser usb-device using wsl uspipd.
Thanks for all the help. I got socketcan to work in WSL after recompiling the kernel.
For any of you that need to access socketcan from the windows host (or the other way around), I made a simple gateway to do so. Run socketcand on the WSL side, and pycangw.py on Windows: https://github.com/faisal-shah/python-can-gateway This uses python-can package - so any adapter that is supported by it should work in theory.
I've found this setup to be particularly useful where a software in the loop simulation running in WSL requires (virtual) CAN bus connectivity with some software running in Windows.
For anyone trying this, these were my steps:
$ git clone https://github.com/microsoft/WSL2-Linux-Kernel $ cd WSL2-Linux-Kernel $ git checkout `uname -r` $ cat /proc/config.gz | gunzip > .config $ make prepare modules_prepare $ make menuconfig # select vcan and can here $ make modules # make modules_install # modprobe vcan # ip link add dev vcan0 type vcan # ip link set up vcan0 # apt install can-utils
Thanks @windelbouwman for sharing those steps on https://github.com/microsoft/WSL/issues/5533#issuecomment-786534957.
Unfortunately, step 3, git checkout
uname -r` is not working because there are no matching branches (microsoft might have pruned them?)... if one uses the closest similar branch, i.e:
linux-msft-wsl-5.15.y
<--- repo branch name
5.15.90.1-microsoft-standard-WSL2
<--- uname -r
on my WSL2 system
It eventually leads to failures trying to load modules with modprobe vcan
and similar commands (insmod).
On top of that, applying followup comments such as https://github.com/microsoft/WSL/issues/5533#issuecomment-942180408 by @ak-aptiv ends up yielding more errors anyway:
modprobe: ERROR: could not insert 'can': Exec format error
... as if it was compiling it for ARM or any other architecture, when I'm actually running on x86_64 (Intel gen 12 processor).
Those modules should be compiled by default, @microsoft :/
This issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request.
Thank you!
My company is working on several embedded Linux projects and we would like to switch from running Ubuntu under VirtualBox to WSL. However, we need SocketCAN support along with the Virtual CAN (vcan) driver. Can you please add these to the WSL kernel?