Linux SocketCAN byte order problems

[CWNE88]

I’d like to set capture filter for CAN ID.
Either specific CAN ID variable, or being able to specify which bytes of the payload to match.
Similar to this for selecting ID 5c2:

ether[2:2] == 0x05c2

That “ether” filter will not work, because the device type is SocketCAN.
However, that above filter does actually work if reading from a captured file.
I would like to be able to filter at the capture stage.

From current code:

case DLT_CAN_SOCKETCAN:
bpf_error(cstate, "CAN link-layer type filtering not implemented");

CAN only has an ID, length, and payload (of up to 8 bytes).
Even if we can only filter with specific bytes, that would be enough.

For instance, something like this maybe:

can[2:2] == 0x05c2

At least that way, we could define what bytes in the packet to filter for the CAN type.

Thanks
Paul.

[infrastation]

ether[2:2] is the same as link[2:2], although it is not immediately obvious why offline filtering works and online filtering does not. What would be the cheapest piece of hardware to test these code paths and to reproduce the problem?

[CWNE88]

I did originally try link[2:2] as well, but nothing got captured.
The cheap device I'm using is the isolated (although you probably don't need isolation for a desk test) version of this:
https://www.aliexpress.com/item/1005006032351087.html

[CWNE88]

I've also just noticed (could be unrelated though) that while doing the capture with Wireshark, an ID sent with 0x0ABC comes up in the packet bytes window correctly at 0abc but in the packet details window it shows as 0x2bc. Lower ID of 0x123 seems fine

[CWNE88]

can-request.pcapng.gz

[infrastation]

Thank you, with the file post-capture filtering works as expected. I could get the USB dongle, would it need to be connected to something to capture any packets?

The Wireshark decoder uses only the low 11 bits for the ID, so 0x0abc (0b101010111100) becomes 0x2bc (0b001010111100). I am not familiar with the packet format to confirm whether that's the correct behaviour.

[CWNE88]

Okay, it seems the can ID must be a value that fits within 7 bits, so that explains the Wireshark information.

To set this up, you don't need any other equipment, just the adapter.
Install can-utils to get the cansend command.
When you connect the device, it will come up as can0 (down)

Bring it up with:

ip link set can0 type can bitrate 500000
ip link set up dev can0

Send a message with:
cansend can0 123#11223344
where 123 is the ID and 11223344 is the payload (maximum 8 bytes for the payload)

You can run the capture on a different CLI to test filtering.

[infrastation]

Thank you for the comments, I have ordered a very similar USB dongle and hopefully will be able to reproduce this problem soonish. Meanwhile other developers may want to make additional input.

[infrastation]

This is how my USB CAN device identifies itself:

ID 1d50:606f OpenMoko, Inc. Geschwister Schneider CAN adapter
Product: candleLight USB to CAN adapter
Manufacturer: bytewerk

On Debian 12/AMD64 the problem seems to reproduce as described, in that link[2:2] = 0x0123 works as expected when reading from a savefile, but during the live capture no packets pass the filter:

# tcpdump -vni can0 'link[2:2] = 0x0123'
tcpdump: listening on can0, link-type CAN_SOCKETCAN (CAN-bus with SocketCAN headers), snapshot length 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

Without the filter the capture has the packets of interest (which take 2-3 seconds to appear in the capture after the cansend command) plus sometimes other packets. The DLT is CAN_SOCKETCAN in both cases and the filter looks correct:

(000) ldh      [2]
(001) jeq      #0x123           jt 2	jf 3
(002) ret      #262144
(003) ret      #0

This way, on the surface everything looks fine on the user-space side of the capture device, so maybe something could be wrong in the kernel.

[infrastation]

Using the previously discussed setup, I tried to debug this problem and started three processes:

• cangen can0 to generate some random packets
• candump -x can0 to see what the packets look like
• tcpdump -evni can0 'link[0:1] == 0' to see if the filter matches anything at all

candump was steadily receiving a few packets per second. tcpdump seemingly was stuck, but after a few minutes I noticed it actually captured a few packets (below are the hex dumps only):

0x0000:  0000 0400 0800 0000 d1fc 7929 fcf1 5346  ..........y)..SF

0x0000:  0000 0400 0000 0000 0000 0000 0000 0000  ................

0x0000:  0000 0100 0400 0000 6dea 312e 0000 0000  ........m.1.....

0x0000:  0000 0300 0400 0000 925a 4847 0000 0000  .........ZHG....

0x0000:  0000 0400 0100 0000 ee00 0000 0000 0000  ................

candump printed these packets as follows:

  can0  TX - -  400   [8]  D1 FC 79 29 FC F1 53 46
  can0  TX - -  400   [0]
  can0  TX - -  100   [4]  6D EA 31 2E
  can0  TX - -  300   [4]  92 5A 48 47
  can0  TX - -  400   [1]  EE

As far as I understand this observed behaviour, link[0:1] tests the least significant 8 bits of the ID, not the first octet of the message (the term "payload" would need to be carefully defined to be able to reason about it). As far I understand the expected behaviour, it should test the first octet of the link-layer packet, but the low 8 bits of the ID are three octets past the beginning of the link-layer, so the observed behaviour is not consistent with the spec either.

[infrastation]

Apparently, this bug does not even require a CAN hardware to reproduce, e.g. on Debian 12:

ip li add type vcan name vcan0
ip li set dev vcan0 up

Then run the three programs as shown above using vcan0 as the device. Also, the filter expression link[0:1] % 16 <= 3 could be used to match 1/4 of the random packets rather than 1/256.

[CWNE88]

Thanks for confirming that and looking into it.

[infrastation]

The problem reproduces only for a live capture that uses kernel filtering. With the change below link[0:1] means the very first octet of the captured packet (which in my test seems always to be 0) and link[3:1] means the low 8 bits of the ID. This behaviour is consistent with reading from a file (as discussed earlier), which uses userland filtering too.

--- a/pcap-linux.c
+++ b/pcap-linux.c
@@ -4598,7 +4598,7 @@ pcap_setfilter_linux(pcap_t *handle, struct bpf_program *filter)
 
        /* Install kernel level filter if possible */
 
-       if (handle->fcode.bf_len > USHRT_MAX) {
+       if (handle->fcode.bf_len > 0) {
                /*
                 * fcode.len is an unsigned short for current kernel.
                 * I have yet to see BPF-Code with that much