[RFC] A CAN Bus (SocketCAN-like) networking stack for FreeBSD

Hello,
This is an update to my initial proposal regarding a CAN Bus stack for FreeBSD. I'm happy to report that we now have a working proof-of-concept implementation.
For context, this project—tentatively named "NetCAN"—provides kernel-level support for the Controller Area Network protocol, modeled after the widely adopted Linux SocketCAN framework. It introduces the PF_CAN protocol family, allowing userland applications to interact with CAN bus hardware through a standard socket API.
The stack is designed to be modular, with a clear separation between the protocol implementation, the generic network interface layer (can_if), and hardware-specific device drivers.
So far, the project is composed of:
Kernel Modules

  *   can.ko: Core module registering the PF_CAN protocol family and the CAN netisr.
  *   can_raw.ko: CAN_RAW protocol implementation for SOCK_RAW sockets.
  *   vcan.ko: Virtual CAN loopback driver (vcanX), which is CAN FD capable.
User-space Tools

  *   canconfig: Utility for configuring CAN interfaces (bitrate, mode, etc.).
  *   canutils (candump, cansend): A port of the essential Linux can-utils.

________________________________
Stack Architecture Overview
The architecture is designed to align with standard FreeBSD networking practices.
can.c (Core Domain): Registers the PF_CAN/AF_CAN domain.
can_raw.c (Raw Socket): Manages the CAN_RAW protocol, socket lifecycle, send/write operations, setsockopt, and packet delivery from the netisr to sockets via software filters.
can_if.c (Generic Interface Layer): Provides the ifnet abstraction (canX) for all hardware drivers. It handles the if_transmit entry point, software loopback, and exposes service routines for drivers to report bus state and errors.
struct can_softc (Driver Contract): The contract a hardware driver must fulfill, providing function pointers for hardware-specific operations (transmit, set bitrate, etc.).
________________________________

We are already planning to use it in our own FreeBSD-based products, which ensures we have a strong commitment to its long-term maintenance.
Our goal would be to contribute this stack to the FreeBSD base system.
Before preparing a formal submission, I am seeking feedback from the community, specifically on:

  1.  The overall architecture and API design.
  2.  Real-world use cases or specific hardware (CAN adapters) that you believe are critical to support.
  3.  Any obvious design patterns that feel more aligned with Linux than FreeBSD and could be improved.
Any and all feedback is welcome.
Thank you,
Jérémie




From: Jérémie JOURDIN <jeremie.jourdin@advens.fr>
Date: Monday, 23 June 2025 at 08:57
To: Tomek CEDRO <tomek@cedro.info>
Cc: freebsd-hackers@freebsd.org <freebsd-hackers@freebsd.org>
Subject: Re: FreeBSD-native CAN Stack and AF_CAN Protocol Family
Theoretically, yes, the CAN stack is intended to be hardware-independent.
I suppose there will also be drivers to create or modify, but that shouldn’t be the most complicated part.


De : Tomek CEDRO <tomek@cedro.info>
Date : vendredi, 20 juin 2025 à 20:29
À : Jérémie JOURDIN <jeremie.jourdin@advens.fr>
Cc : freebsd-hackers@freebsd.org <freebsd-hackers@freebsd.org>
Objet : Re: FreeBSD-native CAN Stack and AF_CAN Protocol Family
CAUTION: External Sender. This email originated from outside of ADVENS. Do not click on links or open attachments from senders you do not trust.



On Fri, Jun 20, 2025, 14:52 Jérémie JOURDIN <jeremie.jourdin@advens.fr<mailto:jeremie.jourdin@advens.fr>> wrote:
Hello all,
I am working on a system (15-current) that requires interaction with a CAN network.
So far, I have developped a driver for my controller, able to send and receive CAN frames to and from connected devices.
I’d like to implement a FreeBSD-native CAN network stack that is API-compatible with Linux’s Netlink CAN (netcan).
This would allow us to recompile and use existing Linux userland tools with minimal changes.
If you believe this development could benefit the community, I would be happy to submit a set of patches (driver + netcan support).
We’re considering defining a new Protocol Family, AF_CAN, for this purpose.
Would it be acceptable to use the first available « AF_VENDORXX » from sys/socket.h ?
I would appreciate your thoughts, advice, and any recommendations you may have on this matter.
-- Jérémie

Hello Jeremie, sounds great! :-) Would that work with simple USB-UART-CAN adapters? :-)

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info<http://www.tomek.cedro.info/>