Configuring Native SocketCAN vcan in WSL2 Kernel 6.6.x

On the terminal, modprobe vcan stops at FATAL: Module not found, and you cannot create vcan0. Start here: the default WSL2 kernel lacks the required CAN support, so repeating the load command will not fix it. Build and boot a WSL2 kernel with CONFIG_CAN, CONFIG_CAN_RAW, and CONFIG_CAN_VCAN, then create the virtual interface.

Read the symptom before changing anything

Treat module loading, interface creation, and CAN application traffic as separate checkpoints. A failure at one layer does not prove that the next layer is broken.

The first check is the active kernel release. The working configuration used 6.6.123.2-microsoft-standard-WSL2+, but matching that exact release is not the objective. Your objective is to confirm that WSL2 booted the kernel you built.

Trace the failure through the CAN stack

SocketCAN places CAN networking inside the Linux kernel. User-space tools create and use a network interface, but they cannot supply a missing kernel protocol family or virtual CAN driver.

• CONFIG_CAN provides the CAN networking core.
• CONFIG_CAN_RAW provides raw CAN sockets used by common CAN applications.
• CONFIG_CAN_VCAN provides the virtual CAN network device.

All three layers matter. Enabling the virtual driver without the CAN core cannot produce a usable device. Omitting raw socket support can leave the interface present while applications that expect raw CAN sockets still fail.

modprobe searches for a loadable module that matches the running kernel. Its failure means that such a module is unavailable; it does not distinguish between an unsupported kernel and a driver compiled directly into the kernel. If VCAN was built in, interface creation is the better functional test because there is no separate module to load.

VCAN stops at the software boundary. It is suitable for application development, protocol tests, message routing, and repeatable simulations. It has no transceiver, connector, arbitration wiring, or physical bus, so it cannot validate electrical behavior, bus termination, adapter firmware, or hardware error handling.

Build and activate the corrected WSL2 kernel

1. Record the running release. Read the kernel release from inside WSL2. This gives you the baseline and later proves whether the replacement kernel actually started.
2. Start from the matching WSL2 kernel configuration. Preserve the WSL-specific options already required by the environment. Replacing the configuration with a generic Linux configuration can trade one missing subsystem for another.
3. Enable the complete path. Select CONFIG_CAN, CONFIG_CAN_RAW, and CONFIG_CAN_VCAN. Decide whether VCAN will be built in or built as a module, then keep that decision in mind during verification.
4. Compile the kernel and any selected modules. Keep the kernel image and its module tree from the same build. A module compiled for another release will not repair the running kernel.
5. Select the custom kernel for WSL2. Use the WSL custom-kernel configuration mechanism on the Windows side, then fully stop and restart WSL2 so it loads the replacement image.
6. Read the active release again. Do not proceed until it identifies your custom build. Compiling successfully while continuing to boot the stock kernel changes nothing.
7. Load VCAN only when modular. Run modprobe vcan if CONFIG_CAN_VCAN was built as a module. If it was built into the kernel, skip the module test and create the interface directly.

Rebuilding repeatedly before checking the active release wastes time. So does copying an unrelated module into the running module directory. Kernel configuration, kernel image, and loadable modules must describe the same build.

Create and raise the virtual interface

1. Create vcan0. Run:

   sudo ip link add dev vcan0 type vcan

2. Set the interface up. Run:

   sudo ip link set up vcan0

3. Check the command results. Both commands should complete cleanly. If creation fails, return to the kernel configuration and active-release checks. If creation succeeds but setting the link up fails, inspect the current link state and privileges before rebuilding.

Do not add UDP tunneling, a separate virtual machine, or a USB-CAN adapter merely to obtain a software-only test bus. Those components solve different problems and add failure points. Native vcan0 needs only the corrected WSL2 kernel and normal Linux link configuration.

Check whether vcan0 already exists before rerunning the creation command. An existing interface is not evidence of a kernel fault; use the existing link or remove and recreate it according to your test setup.

Verify the fix at every layer

1. Verify the kernel. Confirm that the active release is the custom build, such as the working 6.6.123.2-microsoft-standard-WSL2+ build, rather than the previous default kernel.
2. Verify the driver path. For a modular build, modprobe vcan must load the matching module. For a built-in driver, successful interface creation is the valid result.
3. Verify link creation. Create vcan0 and raise it with the two ip link commands. Confirm that the interface is present and up.
4. Verify raw socket operation. Bind a CAN receiver to vcan0 in one process and transmit a test frame from another. The receiver must observe the transmitted identifier and payload without any physical adapter.
5. Verify restart behavior. Restart WSL2, confirm the custom kernel remains active, and recreate vcan0. Add that creation step to your initialization workflow if applications expect the interface after every start.

A successful link command alone proves that the virtual driver exists. A received test frame proves that the CAN core, raw socket protocol, interface, and user-space application path work together.

Avoid the recurring WSL2 CAN traps

• Booting the wrong image: Check the running release immediately after every kernel change.
• Testing only modprobe: A built-in VCAN driver has no separate module to find. Test interface creation.
• Enabling only one option: Configure the CAN core, raw socket layer, and VCAN driver as a complete path.
• Mixing kernel and modules: Build and install them together. A matching filename does not make an incompatible module loadable.
• Confusing VCAN with adapter support: A PCAN adapter requires the applicable PCAN kernel driver plus USB-device sharing into WSL2. Native vcan0 does not provide either one.
• Expecting physical-bus results: VCAN cannot test termination, transceiver faults, connector wiring, or physical arbitration behavior.
• Forgetting runtime state: Recreate virtual interfaces after WSL2 stops or restarts.
• Losing the change after an update: Recheck the active release and all three configuration options whenever the WSL2 kernel selection changes.

FAQ