RKS+CAN fails to initialize on Fedora Workstation 37

Hello CAN-Hacker,

I don't speak, read, or write German. I use Google Translate.

I purchased an RKS+CAN cable, and it's not being properly recognized under Fedora Workstation 37. When I plug in the cable, the Linux ACM driver (cdc_acm) does not create a tty device for use with SocketCAN/slcan (e.g., /dev/ttyACM0).

The driver reports the following error:
Probe from 1-1:1.0 failed with error -22.

Code:

[  300.234053] usb 1-1: New USB device found, idVendor=16d0, idProduct=0870, bcdDevice= 1.00 [  300.234059] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [  300.234061] usb 1-1: Product: RKS+CAN VCP [  300.234063] usb 1-1: Manufacturer: KAUFMANN [  300.234065] usb 1-1: SerialNumber: RKS+CAN [  300.339898] cdc_acm: probe of 1-1:1.0 failed with error -22 [  300.339931] usbcore: registered new interface driver cdc_acm [  300.339933] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters

I tried the following, but it didn't fix the problem:

Code:

# echo 0x16d0 0x0870 > /sys/bus/usb/drivers/cdc_acm/new_id

Any support you can provide would be greatly appreciated. Thank you in advance.

Best regards,

--Paul

Hello Paul,

A normal serial TTY (CDC) should be created if no other configuration is specified.

Quote:

In Linux, add the following line to the file /etc/modules: usbserial vendor=0x16d0 product=0x0870 The device will then be available as /dev/ttyUSB0.

However, SocketCAN should also work, using slcan.

Quote:

Best regards, Rainer. Please provide the text you would like me to translate from German to English. Hello Paul, A normal serial TTY (CDC USB device class) should be created if no other configuration is specified.

On Linux, add the following line to the /etc/modules file:
usbserial vendor=0x16d0 product=0x0870
The device is then available as /dev/ttyUSB0.https://github.com/linux-can/can-utils/blob/master/slcand.c

But SocketCAN should also work using slcan.
https://github.com/linux-can/can-utils/blob/master/slcand.c

Best regards,
Rainer

Quote:

insmod /lib/modules/4.15.0-210-generic/kernel/drivers/usb/serial/usbserial.ko vendor=0x16d0 product=0x0870 root@Inspiron-580:/home/rkaufman# ls /dev autofs disk hpet i2c-8 loop6 null sdb1 sg6 tty12 tty24 tty36 tty48 tty6 ttyS12 ttyS24 ttyS8 vcs3 vfio block dri hugepages i2c-9 loop7 port sdb2 shm tty13 tty25 tty37 tty49 tty60 ttyS13 ttyS25 ttyS9 vcs4 vga_arbiter bsg dvd hwrng initctl loop-control ppp sdc snapshot tty14 tty26 tty38 tty5 tty61 ttyS14 ttyS26 ttyUSB0 vcs5 vhci btrfs-control dvdrw i2c-0 input mapper psaux sdd snd tty15 tty27 tty39 tty50 tty62 ttyS15 ttyS27 ttyUSB1

Thank you for your feedback. I need to check what changed. The `insmod` command above seems to have fixed the issue. Just type "modinfo usbserial" to get information about the driver.

Code:

$ sudo modinfo usbserial name:           usbserial filename:       (builtin) license:        GPL v2 file:           drivers/usb/serial/usbserial description:    USB Serial Driver core author:         Greg Kroah-Hartman <gregkh> parm:           vendor:User specified USB idVendor (ushort) parm:           product:User specified USB idProduct (ushort) $ sudo modprobe -v usbserial vendor=0x016d0 product=0x0870 $ lsmod | grep serial $ ls -l /dev/ttyUSB* ls: cannot access '/dev/ttyUSB*': No such file or directory sudo insmod /lib/modules/6.2.13-200.fc37.x86_64/kernel/drivers/usb/serial/usb-serial-simple.ko.xz vendor=0x16d0 product=0x0870 $ lsmod | grep serial usb_serial_simple      24576  0 $ ls -l /dev/ttyUSB* ls: cannot access '/dev/ttyUSB*': No such file or directory

Code:

$ sudo modprobe -v usbserial vendor=0x016d0 product=0x0870 insmod /lib/modules/5.19.0-32-generic/kernel/drivers/usb/serial/usbserial.ko vendor=0x016d0 product=0x0870 $ ls -l /dev/ttyU* crw-rw---- 1 root dialout 188, 0 May 3 11:29 /dev/ttyUSB0 crw-rw---- 1 root dialout 188, 1 May 3 11:29 /dev/ttyUSB1

insmod /lib/modules/4.15.0-210-generic/kernel/drivers/usb/serial/usbserial.ko vendor=0x16d0 product=0x0870
root@Inspiron-580:/home/rkaufman# ls /dev
autofs disk hpet i2c-8 loop6 null sdb1 sg6 tty12 tty24 tty36 tty48 tty6 ttyS12 ttyS24 ttyS8 vcs3 vfio
block dri hugepages i2c-9 loop7 port sdb2 shm tty13 tty25 tty37 tty49 tty60 ttyS13 ttyS25 ttyS9 vcs4 vga_arbiter
bsg dvd hwrng initctl loop-control ppp sdc snapshot tty14 tty26 tty38 tty5 tty61 ttyS14 ttyS26 ttyUSB0 vcs5 vhci
btrfs-control dvdrw i2c-0 input mapper psaux sdd snd tty15 tty27 tty39 tty50 tty62 ttyS15 ttyS27 ttyUSB1

Code:

[...] [ 1179.370935] usbcore: registered new interface driver usbserial_generic [ 1179.370951] usbserial: USB Serial support registered for generic [ 1179.370967] usbserial_generic 1-1:1.0: The "generic" usb-serial driver is only for testing and one-off prototypes. [ 1179.370971] usbserial_generic 1-1:1.0: Tell linux-usb@vger.kernel.org to add your device to a proper driver. [ 1179.370973] usbserial_generic 1-1:1.0: generic converter detected [ 1179.371140] usb 1-1: generic converter now attached to ttyUSB0 [ 1179.371182] usbserial_generic 1-1:1.1: The "generic" usb-serial driver is only for testing and one-off prototypes. [ 1179.371184] usbserial_generic 1-1:1.1: Tell linux-usb@vger.kernel.org to add your device to a proper driver. [ 1179.371187] usbserial_generic 1-1:1.1: generic converter detected [ 1179.371278] usb 1-1: generic converter now attached to ttyUSB1

CAN-Diagnose wrote:

Thank you for your feedback. I need to check what changed. The `insmod` command above seems to have fixed the issue. Just type "modinfo usbserial" before to get information about the driver. Quote: You're welcome, Rainer. Unfortunately, the ttyUSB device is still not being enumerated under Fedora 37. I also tried an Ubuntu 22.04.2 LTS desktop live USB. It enumerates both /dev/ttyUSB0 and /dev/ttyUSB1. It also complains about the device.

From dmesg:


Please let me know which Linux distribution properly supports the RKS+CAN interface, and I will install it.

Kind regards,

--Paul

Hi Paul,

Quote:

The "generic" usb-serial driver is only for testing and one-off prototypes.

That doesn't mean it doesn't work. It works. It's just that the VID/PID are unknown to this driver. I have already contacted the email address provided and will check the fix (which is just about displaying the info text) in the next few days.

It seems that there are some differences between the distributions.
Naming the module in the `/etc/modules` file was sufficient in older versions of Ubuntu.

Anyway, the serial driver is common and part of the kernel, so you can just ignore the warning text and use it. `ttyUSB0` is the actual serial interface, while `ttyUSB1` (I don't know why this is also instantiated in this driver) is only for `winusb`. The USB device provides a second interface for that, but you don't need to use it when working with Linux.

What happens when you do...
"sudo insmod <path> vendor=0x16d0 product=0x0870"
with <path> from the output of "modinfo usbserial"?

Please reconnect the cable and then post the output of the `dmesg` command.

Quote:

sudo insmod /lib/modules/6.2.13-200.fc37.x86_64/kernel/drivers/usb/serial/usb-serial-simple.ko.xz vendor=0x16d0 product=0x0870 text lsmod | grep serial usb_serial_simple 24576 0

It looked good, and it would be interesting to see what the `dmesg` output shows after replugging the cable.

Just found:

Quote:

Generic Serial driver If your device is not one of the devices listed above and is not compatible with the models mentioned, you can try using the "generic" interface. This interface does not send any control messages to the device and does not support any device flow control. The only requirement for your device is that it has at least one bulk input endpoint or one bulk output endpoint. To enable the generic driver to recognize your device, please provide the following: echo <vid> <pid> > /sys/bus/usb-serial/drivers/generic/new_id where the `<vid>` and `<pid>` are replaced with the hexadecimal representation of your device's vendor ID and product ID. If the driver is compiled as a module, you can also provide one ID when loading the module: insmod usbserial vendor=0x#### product=0x#### text This driver has been successfully used to connect to the NetChip USB development board, providing a way to develop USB firmware without having to write a custom driver.

https://www.kernel.org/doc/html/latest/usb/usb-serial.html (at the bottom)

Best regards,
Rainer

Code:

# echo 16d0 0870 >/sys/bus/usb-serial/drivers/generic/new_id # ls -l /dev/ttyUSB* crw-rw----. 1 root dialout 188, 0 May  4 14:02 /dev/ttyUSB0 crw-rw----. 1 root dialout 188, 1 May  4 14:02 /dev/ttyUSB1 # dmesg --follow [...] [ 9247.561326] usb 1-4: new full-speed USB device number 9 using xhci_hcd [ 9247.689178] usb 1-4: New USB device found, idVendor=16d0, idProduct=0870, bcdDevice= 1.00 [ 9247.689184] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 9247.689187] usb 1-4: Product: RKS+CAN VCP [ 9247.689188] usb 1-4: Manufacturer: KAUFMANN [ 9247.689190] usb 1-4: SerialNumber: RKS+CAN [ 9247.691709] usbserial_generic 1-4:1.0: The "generic" usb-serial driver is only for testing and one-off prototypes. [ 9247.691713] usbserial_generic 1-4:1.0: Tell linux-usb@vger.kernel.org to add your device to a proper driver. [ 9247.691715] usbserial_generic 1-4:1.0: generic converter detected [ 9247.691943] usb 1-4: generic converter now attached to ttyUSB0 [ 9247.692250] usbserial_generic 1-4:1.1: The "generic" usb-serial driver is only for testing and one-off prototypes. [ 9247.692253] usbserial_generic 1-4:1.1: Tell linux-usb@vger.kernel.org to add your device to a proper driver. [ 9247.692254] usbserial_generic 1-4:1.1: generic converter detected [ 9247.692334] usb 1-4: generic converter now attached to ttyUSB1 $ lsusb -t -v /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M     ID 1d6b:0003 Linux Foundation 3.0 root hub /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/12p, 480M     ID 1d6b:0002 Linux Foundation 2.0 root hub     |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M         ID 046d:c08e Logitech, Inc.     |__ Port 1: Dev 2, If 1, Class=Human Interface Device, Driver=usbhid, 12M         ID 046d:c08e Logitech, Inc.     |__ Port 2: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M         ID 04f2:0400 Chicony Electronics Co., Ltd     |__ Port 4: Dev 9, If 0, Class=Communications, Driver=usbserial_generic, 12M         ID 16d0:0870 MCS Kaufmann Automotive GmbH, RKS+CAN Interface     |__ Port 4: Dev 9, If 1, Class=Application Specific Interface, Driver=usbserial_generic, 12M         ID 16d0:0870 MCS Kaufmann Automotive GmbH, RKS+CAN Interface     |__ Port 5: Dev 4, If 0, Class=Wireless, Driver=btusb, 12M         ID 04ca:3015 Lite-On Technology Corp. Qualcomm Atheros QCA9377 Bluetooth     |__ Port 5: Dev 4, If 1, Class=Wireless, Driver=btusb, 12M         ID 04ca:3015 Lite-On Technology Corp. Qualcomm Atheros QCA9377 Bluetooth     |__ Port 7: Dev 5, If 0, Class=Video, Driver=uvcvideo, 480M         ID 0408:a030 Quanta Computer, Inc.     |__ Port 7: Dev 5, If 1, Class=Video, Driver=uvcvideo, 480M         ID 0408:a030 Quanta Computer, Inc.

[...]
Just found:

CAN-Diagnose wrote:

Generic Serial driver If your device is not one of the devices listed above and is not compatible with the models mentioned, you can try using the "generic" interface. This interface does not send any control messages to the device and does not support any device flow control. The only requirement for your device is that it has at least one bulk input endpoint or one bulk output endpoint. To enable the generic driver to recognize your device, please provide the following: echo <vid> <pid> > /sys/bus/usb-serial/drivers/generic/new_id where the `<vid>` and `<pid>` are replaced with the hexadecimal representation of your device's vendor ID and product ID. If the driver is compiled as a module, you can also provide one ID when loading the module: insmod usbserial vendor=0x#### product=0x#### text This driver has been successfully used to connect to the NetChip USB development board, providing a way to develop USB firmware without having to write a custom driver. Quote: (at the bottom) Best regards, Rainer

You're welcome. The driver enumerated the ports and attached to the RKS+CAN.

[url]

Next, I need to check if the RKS+CAN interface is compatible with the SocketCAN utility `candump`. According to this matrix, it is supported.
[/url]https://www.kernel.org/doc/html/latest/usb/usb-serial.htmlhttps://elinux.org/CAN_Bus{MARKER}

Code:

$ candump -l slcan0,0:0,#FFFFFFFF Disabled standard output while logging. Enabling Logfile 'candump-2023-05-06_120003.log' $ cat candump-2023-05-06_120003.log | python3 -m cantools decode bmw-e90.dbc (1683392403.155350) slcan0 130#C540FFFFFF :: POWER_130(     AccessoryPower: On,     IgnitionOff: 1,     IgnitionOn: 1 ) [...]

Next, I will have to see if the RKS+CAN works with the SocketCAN utility candump. According to this matrix, it is supported.

808AWD325xi wrote:

[url] I connected the RKS+CAN cable to my BMW and ran candump. It worked! [/url]

It captured CAN frames with arbitration ID 0x130, which broadcasts the Terminal 15 (KL15) ignition status.

Sure, anytime!:Dhttps://elinux.org/CAN_Bus{MARKER}{MARKER}

Hi.

Glad to see your success!

I noticed that some things have changed regarding serial drivers over USB on Linux, as well as the differences between the distributions. I've always used Ubuntu-based systems with those types of drivers.

My next step is to confirm the patch for official kernel device driver support so that the notification message will disappear.
Unfortunately, I am currently very busy with other commitments, so this may take some time.

If you have any further questions regarding CAN/Linux, I'm happy to try and help you!

Best regards,
Rainer