From: "Magnus Aagaard Sørensen" <mas@csselectronics.com>
To: linux-can@vger.kernel.org
Subject: Exposing CAN hardware from userspace
Date: Wed, 8 Oct 2025 08:08:43 +0200 [thread overview]
Message-ID: <ef30ff2e-a283-4aa2-be7c-902acfced35e@csselectronics.com> (raw)
Hi,
I am attempting to interface with the CAN hardware in a remote device
over a network and expose it locally as a SocketCAN bus. The remote
device does not run Linux, but I am able to fully expose the CAN
hardware over the network using a custom protocol. Latency in itself is
not an issue for this use case, but accurate timestamping and reliable
transmission to the remote is.
So far I have found a few userspace tools which could handle the network
communication aspect (such as socketcand[1] and cannelloni[2]), but
these all seem to expose the remote side as a local node on a SocketCAN
bus and not a bus in itself.
As there is no CAN hardware locally in my use case, the only option is
to create a virtual CAN bus via vcan if using the above userspace tools.
This presents a few issues:
* The remote timestamp information is not propagated to the local
SocketCAN bus. I.e. the accurate remote hardware timestamp is replaced
by a local software timestamp.
* The direction of messages is lost, as all messages are sent into the
vcan bus and thus marked as tx in e.g. candump.
* Flow control from the remote side is lost, such that local nodes can
send CAN frames even though the remote side is fully loaded.
Overall, vcan is likely the wrong tool for this job, but I am not aware
of any alternatives. Are there any options I have missed which can solve
the above issues without providing a new kernel module? The use case
seems closely related to the tun/tap driver in the networking stack in
general, but I am unsure if these could be extended to handle the
SocketCAN case.
If I were to take the route of a new kernel module, what options do I
have for exposing the data and control structures of a SocketCAN bus to
userspace? So far I know of file descriptors as in the tun/tap case, but
I am not knowledgeable enough in the kernel systems in general to see if
there are other options which would be a better fit for bidirectional
data and/or asynchronous messages?
Any advice is appreciated.
Regards,
Magnus.
[1]: https://github.com/linux-can/socketcand
[2]: https://github.com/mguentner/cannelloni
next reply other threads:[~2025-10-08 6:08 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-08 6:08 Magnus Aagaard Sørensen [this message]
2025-10-17 17:43 ` Exposing CAN hardware from userspace Marc Kleine-Budde
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ef30ff2e-a283-4aa2-be7c-902acfced35e@csselectronics.com \
--to=mas@csselectronics.com \
--cc=linux-can@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).