CAN bus over the network, done right.
Devices behind NAT export their SocketCAN interfaces to a central hub. Consume them from anywhere with the tools you already use.
Encrypted and authenticated by default — on QUIC with mutual TLS.
Why can-hub
The hard parts, handled.
Works through NAT
Agents and clients both dial out; the hub rendezvous in the middle. No port forwarding on the device side, no firewall holes.
Zero-config security
ED25519 identities generated on first start, trust-on-first-use pinning both sides, mutual TLS, and per-interface read/write ACLs.
The right transport for CAN
Control rides reliable QUIC streams; frames ride latest-wins datagrams. A lost cyclic frame is repaired by the next cycle, not retransmitted late.
Your tools, unmodified
Mirror a remote bus into a local vcan for candump and Wireshark, or keep using socketcand clients through the bridge.
The pieces
Five small binaries, one fleet.
can-hub →The hub: registry, frame relay, admin plane.
can-hub-agent →Device daemon: exports local SocketCAN interfaces.
can-hub-client →Consumer: list, dump, send, attach, socketcand.
can-hub-cli →Hub administration over the local unix socket.
can-hub-web →Web admin panel: REST API + live telemetry.
REST API →The contract behind the panel — browse it live.
Try it on a virtual bus
No CAN hardware? No problem.
Spin up a virtual bus and run the hub, an agent and a client on one machine.
# virtual bus + hub + an agent exporting it sudo ip link add dev vcan0 type vcan && sudo ip link set up vcan0 can-hub & can-hub-agent --connect tcp://127.0.0.1:7228 --name demo vcan0 & # consume it — list, dump, send can-hub-client --connect tcp://127.0.0.1:7228 list id agent interface 1 demo vcan0 can-hub-client --connect tcp://127.0.0.1:7228 send demo/vcan0 123#DEADBEEF
Reach the buses of the things you build.
Vehicles, machines and fleets behind NAT — encrypted, authenticated, live.