linux-can.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Exposing CAN hardware from userspace
@ 2025-10-08  6:08 Magnus Aagaard Sørensen
  2025-10-17 17:43 ` Marc Kleine-Budde
  0 siblings, 1 reply; 2+ messages in thread
From: Magnus Aagaard Sørensen @ 2025-10-08  6:08 UTC (permalink / raw)
  To: linux-can

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Exposing CAN hardware from userspace
  2025-10-08  6:08 Exposing CAN hardware from userspace Magnus Aagaard Sørensen
@ 2025-10-17 17:43 ` Marc Kleine-Budde
  0 siblings, 0 replies; 2+ messages in thread
From: Marc Kleine-Budde @ 2025-10-17 17:43 UTC (permalink / raw)
  To: Magnus Aagaard Sørensen; +Cc: linux-can

[-- Attachment #1: Type: text/plain, Size: 2557 bytes --]

On 08.10.2025 08:08:43, Magnus Aagaard Sørensen wrote:
> 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 remember correctly the Linux kernel fuzzer sysbot already uses the
tap interface to inject CAN frames into the kernel. Let me see.

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

regards,
Marc

-- 
Pengutronix e.K.                 | Marc Kleine-Budde          |
Embedded Linux                   | https://www.pengutronix.de |
Vertretung Nürnberg              | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-9   |

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2025-10-17 17:43 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-10-08  6:08 Exposing CAN hardware from userspace Magnus Aagaard Sørensen
2025-10-17 17:43 ` Marc Kleine-Budde

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