No way to detect self-received (echoed) frames under hardware loopback

[lukas.toma1]

Hello,

Versions: Linux kernel 6.12.47, PEAK proprietary Linux driver 9.2.0, PCAN-USB X6 FD firmware 3.5.1

With the proprietary driver (using SocketCAN ) it's possible to enable genuine hardware loopback (CAN_CTRLMODE_LOOPBACK). Under Linux's software loopback (SocketCAN's default kernel-side echo, which I disabled for this purpose), applications can identify a self-sent/echoed frame via the standard MSG_CONFIRM socket flag. Under hardware loopback, this flag is never set, there's currently no way for an application to distinguish a self-received/echoed frame from a genuinely bus-received one.

From what I can tell, the firmware already reports enough information for the driver to know a given received frame is a self-received echo, but this information isn't currently passed through to userspace in a way applications can act on.

It would be very useful for the application to reliably detect self-received/echo frames when using hardware loopback. Would it be possible to have the driver expose this to userspace, ideally via the standard MSG_CONFIRM mechanism, so it matches the existing software loopback behavior?

Best regards,
Lukas

[S.Grosjean]

Hi,

The ECHO feature is not supported by the netdev variant of the PCAN driver for Linux, which is why the ECHO flag is cleared from the exposed network interface. Therefore, you will never see MSG_CONFIRM in the CAN frames read from these channels.

Regarding “loopback” frames (i.e., those generated by the CAN controller when copying outgoing frames to the bus), the socket-CAN API provides no way to distinguish them from a frame genuinely read from the bus.

Regards,

[lukas.toma1]

Hi,

Thanks for the clarification. Just to make sure I understand correctly: MSG_CONFIRM itself is a general SocketCAN feature, but it only works if the driver implements the frame-echo mechanism on its side. So what you're describing isn't a limitation of the SocketCAN API, it's that your netdev driver variant simply doesn't implement that part of the API for hardware loopback frames, correct?

If so, is this something you'd consider adding in a future driver update? Since the firmware already reports enough information to identify a self-received frame, it seems like the driver could, in principle, hook into the standard echo mechanism to expose this to userspace via MSG_CONFIRM, the same way software loopback already does. This would be very valuable for applications that need to reliably distinguish self-received frames from genuinely bus-received ones.

Best regards,
Lukas

[S.Grosjean]

Hi,

it's that your netdev driver variant simply doesn't implement that part of the API for hardware loopback frames, correct?

Correct. However, MSG_CONFIRM is not a SocketCAN-specific feature; it is part of the generic socket API.

If so, is this something you'd consider adding in a future driver update?

To be honest, you're the first person to ask for this feature. Which is not currently on our TODO list.

This would be very valuable for applications that need to reliably distinguish self-received frames from genuinely bus-received ones.

I think there may be a misunderstanding here. MSG_CONFIRM is associated with locally echoed frames returned by the driver, whereas hardware loopback frames are frames generated by the CAN controller itself. These are two different mechanisms. Could you explain what specific use case requires MSG_CONFIRM on hardware loopback frames?

Best regards,

[lukas.toma1]

Hi,

thank you for the clarification!

I found the following information on the official SocketCAN Documentation (https://docs.kernel.org/networking/can.html):

MSG_CONFIRM:

set when the frame was sent via the socket it is received on. This flag can be interpreted as a ‘transmission confirmation’ when the CAN driver supports the echo of frames on driver level, see Local Loopback of Sent Frames ... (Note: In order to receive such messages on a RAW socket, CAN_RAW_RECV_OWN_MSGS must be set.)

As I understand it, this echo is only generated once the frame has actually been transmitted on the bus, so receiving it back with MSG_CONFIRM set is what would give an application certainty that a specific frame really went out on the bus, rather than just that it was successfully queued to the driver.

And that is actually the specific use case -> a reliable confirmation that a given frame was actually transmitted, as opposed to relying only on the return value of write()/send(), which only confirms the frame was accepted by the driver/queue.

If I've misunderstood how or when the echo frame is generated relative to the actual bus transmission, I'd appreciate a correction, but if my understanding is right, that's the reasoning behind the request.

Best regards
Lukas

[S.Grosjean]

Hi,

set when the frame was sent via the socket it is received on. This flag can be interpreted as a ‘transmission confirmation’ when the CAN driver supports the echo of frames on driver level,

As said, MSG_CONFIRM means that the frame as been echoed on driver level.

To be more precise: SocketCAN drivers for CAN-over-USB interfaces (e.g. peak_usb) use the USB transfer completion event to send the echo frame back to the socket layer. As a result, the application can be certain that the CAN frame has been successfully queued to the USB interface.

This behavior has been accepted for a long time because, while a local loopback mechanism could theoretically be implemented in the USB device itself, it would generate a considerable amount of additional USB traffic (at least twice as much) solely to acknowledge successful frame transmission.

In contrast, local loopback can be implemented on other interface types, such as PCIe, since PCIe traffic handling incurs significantly lower CPU overhead.

That clarification aside, you did not answer my question about my suggestion of providing a "complete" version of the peak_usb driver tailored to your 6.12.47 kernel.

Regards,

[lukas.toma1]

Hi,

thank you very much for the detailed description, that information definitely helped. Regarding the out-of-tree driver, I replied on the original post.

Best regards
Lukas