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

hi! did anyone get back to you about this?

Yes I think CAN support would benefit the community! Please send over some
diffs and we can start reviewing!



-adrian


On Thu, 18 Sept 2025 at 09:58, Jérémie JOURDIN <jeremie.jourdin@advens.fr>
wrote:

> 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>
> 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
>