linux-can/can-utils: SocketCAN Utilities for Linux CAN Work

What can-utils solves for SocketCAN users

Linux exposes CAN controllers through the SocketCAN subsystem, so a CAN interface behaves like a network device and frames move over sockets rather than through a proprietary DLL. That model gives you the kernel side, but it gives you no command-line tools. can-utils is the missing userspace layer: a set of C programs that display, record, generate and replay CAN traffic, plus protocol-specific tools for ISO-TP (ISO15765-2:2016) and J1939/ISOBus.

The intended user is an engineer on a Linux host with a CAN adapter already bound to the kernel. The README lists the basic tools first: candump displays, filters and logs CAN data to files; canplayer replays logfiles; cansend sends a single frame; cangen generates random traffic; cansequence sends and checks a sequence of frames with an incrementing payload; cansniffer shows content differences. Everything else in the repository is a specialised extension of that core.

The scope is wider than raw frames. There are tools for IP access to CAN (canlogserver, bcmserver, and links to socketcand and cannelloni), in-kernel gateway configuration via cangw, bus measurement (canbusload, can-calc-bit-timing, canfdtest, canerrsim), ISO-TP, J1939, ISOBus file server tools, log converters (asc2log, log2asc, log2long) and serial line discipline configuration for the slcan driver. If your problem is 'I have a CAN bus and a Linux box', this repository is the standard starting point, and the Debian package description linked from the README is the evidence that distributions carry it as a package.

How the tools sit on top of the kernel

The architecture is deliberately thin. The kernel owns the CAN controller, the bit timing and the socket layer; can-utils programs are ordinary userspace processes that open CAN sockets and read or write frames. There is no daemon required for the basic tools and no configuration file to load. That is why candump can be a small C program and why canplayer can replay a logfile without knowing anything about the hardware.

The shared code lives in lib.c and lib.h, with libj1939.c and libj1939.h for the J1939 tools, and include/ for headers. The repository layout reflects the split: one top-level .c file per command (candump.c, cansend.c, cangen.c, canplayer.c, cansniffer.c, cansequence.c, canbusload.c, canerrsim.c, canfdtest.c, canframelen.c, cangw.c, canlogserver.c, bcmserver.c), the ISO-TP family as isotp*.c, the J1939 family as j1939*.c plus testj1939.c, and the serial tools as slcan_attach.c, slcand.c and slcanpty.c. Subdirectories hold the parts that are not single-file programs: calc-bit-timing/, isobusfs/, j1939_timedate/, j1939_vehicle_position/ and mcp251xfd/.

The data flow for the common case is: frames arrive from the bus, the kernel delivers them on a CAN socket, candump formats and optionally filters them and writes them to a logfile in the compact format, and canplayer later pushes that same compact format back onto a bus. The log converters exist because not every capture tool writes that format: asc2log converts an ASC logfile to the compact CAN frame logfile, log2asc goes the other way, and log2long turns the compact representation into something readable. That converter trio is the part people miss when they assume can-utils only speaks its own format.

Installing can-utils and capturing your first frames

Most users get the tools from their distribution, since the README links the Debian package description. On a Debian-derived system the package is named can-utils, and the same name appears in the related searches for Ubuntu and Arch. If you need a newer build, or you are targeting Android or a Raspberry Pi, the README documents a CMake build: place the build folder anywhere and pass CMake the source path, relative or absolute.

cmake -GNinja .. && ninja

That is the Linux example from the README, run from a build directory with the source one level up. The README also gives an install-prefix override, `CC=clang cmake -DCMAKE_INSTALL_PREFIX=./out .. && make install`, and a Raspberry Pi toolchain example. A plain Makefile sits at the top level as well.

Once the binaries are on your PATH, the first real use is to watch traffic on an interface. The README describes candump as the tool that displays, filters and logs CAN data to files, and cansend as the tool that sends a single frame. Running candump with an interface name prints incoming frames as they arrive and keeps running until you interrupt it; canplayer then reads a logfile produced by candump, and cangen generates random frames when no hardware is attached.

For a virtual bus, the search question about vCAN points at the kernel's virtual CAN driver, which lets you exercise candump and cansend without a physical adapter. The README itself does not document vcan, so treat the kernel documentation it links as the source for that setup.

Where can-utils is the wrong tool

The first limitation is platform. This is Linux userspace for the Linux CAN subsystem. The related searches include 'can utils windows', and the honest answer is that the repository targets Linux: it depends on SocketCAN sockets and, for the serial tools, on the slcan line discipline. If your development host is Windows, can-utils is not the path.

The second limitation is that it is a toolbox, not a product. There is no GUI, no project file, no session management and no built-in database of signal definitions. cansniffer shows content differences and candump can filter, but if you need decoded signals against a DBC, that decoding is not in this repository. The README lists log converters for ASC and the compact format, nothing more.

The third limitation is protocol coverage. ISO-TP tools are tied to the can-isotp kernel module, which the README links to separately; the J1939 tools are tied to the kernel J1939 stack, and the README points to a separate document for installing that module on Debian. Without the matching kernel support, isotpsend, j1939cat and friends have nothing to talk to. That is a real deployment constraint on older or vendor kernels.

Finally, the repository is not a driver. If your CAN adapter has no SocketCAN driver, can-utils cannot help you; the mcp251xfd/ directory in the tree is a specific hardware case, not a general answer. Check that the interface exists before blaming the tools.

Alternatives and how they differ

The closest functional alternative named in the README itself is socketcand, which exposes RAW, BCM and ISO-TP sockets over TCP/IP, so a remote client can use CAN without a local adapter. The difference in approach matters: can-utils runs on the machine that owns the bus, while socketcand moves the socket interface across the network. If your constraint is a headless board in a vehicle and a workstation elsewhere, socketcand addresses that; can-utils alone does not.

The second alternative in the same list is cannelloni, described as a UDP/SCTP based SocketCAN tunnel. It links two SocketCAN instances over an IP network rather than exporting a socket API to a client. The distinction is tunnel versus server: cannelloni makes two buses look like one, socketcand makes one bus reachable from a program on another host.

Both are listed as separate projects with their own repositories, so they are complements to can-utils rather than replacements for candump or cansend. The actual replacement question is usually about commercial bus analysers with graphical trace views and signal decoding. Those tools do things can-utils does not attempt: persistent sessions, decoded signals, graphical timing views. In exchange they are not scriptable in the way a set of small C programs is, and they are not what a distribution ships as can-utils.

Maintenance, build cost and licence

The repository is not archived, and the last push was on 2026-09-20, so it is being touched. Release cadence is slow and uneven: v2025.01 on 2025-01-28, v2023.03 on 2023-03-15, and v2021.08.0 on 2021-08-19. Between releases, work lands on master. If you package can-utils for a distribution or a product image, plan to pin a commit rather than wait for a tag.

Upgrade cost is low for the basic tools because they are small, self-contained C programs with a shared lib.c. It is higher for the protocol families, where the userspace version has to match kernel support: the ISO-TP tools pair with the can-isotp module and the J1939 tools with the kernel J1939 stack, and the README links separate installation notes for the J1939 module on Debian. A kernel upgrade that changes those interfaces is the event that forces a rebuild.

On licensing, the repository has a LICENSES/ directory but the README does not state a single SPDX identifier for the project. The Makefile carries a Volkswagen Group Electronic Research copyright notice from 2002-2005 with a three-clause style condition set, and it offers an alternative: distribution under GPL version 2 as found in the kernel source's COPYING file, provided the notice is retained in full. The same header says the data structures and external interfaces are not restricted to GPL-compatible modules. This is a dual-option arrangement, not a plain GPL grant, and the file-level notices are what govern. Read LICENSES/ and the headers of the specific files you redistribute; this article is not legal advice.

Editorial conclusion

Adopt can-utils if your CAN interface already appears as a Linux network device and you want command-line tools for capture, replay and protocol work. Do not adopt it if you need a Windows or macOS host, a graphical bus analyser, or a vendor driver that has no SocketCAN binding: the repository is Linux userspace only, and the README points at the kernel documentation for the subsystem itself. Before you rely on it, build from source with CMake and check that candump sees your interface, then verify the licence terms in the LICENSES directory and the Makefile header against how you intend to redistribute the binaries.

Frequently asked questions

Official sources

1. Issues
2. linux-can/can-utils on GitHub
3. README
4. Releases