1

I am using a Lawicel CAN adapter to connect to a sensor, and would like to setup a udev rule to avoid the manual can setup.

The manual can setup:

sudo slcand -o -c -f -s6 /dev/ttyUSB0 slcan0
sudo ifconfig slcan0 up

Running candump slcan0 shows, by printing data, that the connection works.

I am thus following a guide to setting up the udev rule from link. But this doesn't work. The udev rule is

# Lawicel CANUSB module
ACTION=="add", ENV{ID_MODEL}=="CANUSB", ENV{SUBSYSTEM}=="tty", RUN+="/usr/bin/logger [udev] Lawicel CANUSB detected - running slcan_add.sh!", RUN+="/usr/local/bin/slcan_add.sh $kernel"
ACTION=="remove", ENV{ID_MODEL}=="CANUSB", ENV{SUBSYSTEM}=="usb", RUN+="/usr/bin/logger [udev] Lawicel CANUSB removed - running slcan_remove.sh!", RUN+="/usr/local/bin/slcan_remove.sh"

and the slcan_add.sh script is

#!/bin/sh
# Bind the USBCAN device
slcand -o -c -f -s6 /dev/$1 slcan0
sleep 2
ifconfig slcan0 up

then I reload the rules and restart udev, and tail -f /var/log/syslog returns the following

morten@thinkpad:~$ tail -f /var/log/syslog
Oct  7 10:56:21 thinkpad kernel: [ 1580.917239] usb 1-1: Detected FT232RL
Oct  7 10:56:21 thinkpad kernel: [ 1580.918002] usb 1-1: FTDI USB Serial Device converter now attached to ttyUSB0
Oct  7 10:56:21 thinkpad mtp-probe: checking bus 1, device 10: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-1"
Oct  7 10:56:21 thinkpad mtp-probe: bus: 1, device: 10 was not an MTP device
Oct  7 10:56:21 thinkpad root: [udev] Lawicel CANUSB detected - running slcan_add.sh!
Oct  7 10:56:21 thinkpad slcand[5967]: starting on TTY device /dev/ttyUSB0
Oct  7 10:56:21 thinkpad slcand[5968]: attached TTY /dev/ttyUSB0 to netdevice slcan0
Oct  7 10:56:21 thinkpad slcand[5968]: netdevice slcan0 renamed to slcan0
Oct  7 10:56:21 thinkpad NetworkManager[649]: <info>  [1633596981.6497] manager: (slcan0): new Generic device (/org/freedesktop/NetworkManager/Devices/8)
Oct  7 10:56:21 thinkpad systemd-udevd[5954]: ethtool: autonegotiation is unset or enabled, the speed and duplex are not writable.
Oct  7 10:56:23 thinkpad snapd[668]: hotplug.go:199: hotplug device add event ignored, enable experimental.hotplug
Oct  7 10:56:23 thinkpad mtp-probe: checking bus 1, device 10: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-1"
Oct  7 10:56:23 thinkpad mtp-probe: bus: 1, device: 10 was not an MTP device
Oct  7 10:56:26 thinkpad ModemManager[791]: <info>  [base-manager] couldn't check support for device '/sys/devices/pci0000:00/0000:00:14.0/usb1/1-1': not supported by any plugin
Oct  7 10:56:27 thinkpad gnome-shell[1997]: Removing a network device that was not added
Oct  7 10:56:27 thinkpad gnome-shell[1426]: Removing a network device that was not added

and candump slcan0 returns SIOCGIFINDEX: No such device. How should I fix this?

NOTE: Using ubuntu 20.04.

EDIT: The udev rule properly recognizes the device and runs the script, so the udev rule should work I figure. If I manually set the usb port and run the shell script with sudo ./sclan_add.sh then it also works, displaying the following in tail -f /var/log/syslog

Oct  7 12:53:26 agrirobot slcand[20933]: starting on TTY device /dev/ttyUSB0
Oct  7 12:53:26 agrirobot slcand[20934]: attached TTY /dev/ttyUSB0 to netdevice slcan0
Oct  7 12:53:26 agrirobot slcand[20934]: netdevice slcan0 renamed to slcan0
Oct  7 12:53:26 agrirobot NetworkManager[649]: <info>  [1633604006.8360] manager: (slcan0): new Generic device (/org/freedesktop/NetworkManager/Devices/22)
Oct  7 12:53:26 agrirobot systemd-udevd[20936]: ethtool: autonegotiation is unset or enabled, the speed and duplex are not writable.

I can't really see what the problem is with the udev rule calling the shell script, but for some reason this makes the difference.

Morten Nissov
  • 130
  • I feel like this is hard to troubleshoot/verify given that the current setup doesn't work, the solving of which is my primary concern. That being said, I'm not 100% sure what the kernel parameter is doing in this context. I'm very new to udev rules. – Morten Nissov Oct 08 '21 at 07:10
  • In your ACTION=="add" udev rule, the 1st positional parameter $kernel appears to be undefined, unless it is a variable that you have previously exported. I suspect (from the tutorial you referenced) it could be slcan?... (wild-ish guess here !). You need to check the device name when you plug it and verify that it is not subject to changes from one plug action to the next... You can probably get the device name with lsblk | grep dev. – Cbhihe Oct 08 '21 at 07:13
  • I suspect the $kernel is a misnomer. It is in fact the "device" name, which you can get per my modified comment. – Cbhihe Oct 08 '21 at 07:15
  • device name, meaning ttyUSB0 or what? – Morten Nissov Oct 08 '21 at 07:16
  • I don't think this is the problem, if you check the lines after starting on TTY device /dev/ttyUSB0 you'll see it does actually start the device. Also when I tried to start it manually I confirmed that the dev port is correct.

    The problem in setting up the can interface comes from elsewhere.

     – Morten Nissov Oct 08 '21 at 07:22
  • Note: deviations in the syslog response to the manual can setup and this automated version starts at the snapd[668]: line – Morten Nissov Oct 08 '21 at 07:22

1 Answers1

1

Solution was a combination of things, partially inspired by this.

udev rule

# Lawicel CANUSB module
ACTION=="add", ENV{ID_MODEL}=="CANUSB", ENV{SUBSYSTEM}=="tty", RUN+="/usr/local/bin/slcan_add_wrapper.sh $kernel"

slcan_add_wrapper.sh

#!/bin/sh
#  Call shell script binding can device
/usr/bin/logger "[udev] Lawicel CANUSB detected - running /usr/local/bin/slcan_add.sh on $1"
echo /usr/local/bin/slcan_add.sh $1 | at now

slcan_add.sh

#!/bin/sh
# Bind the USBCAN device
sleep 1
/usr/bin/logger "binding $1 to slcan0"
slcand -o -c -f -s6 /dev/$1 slcan0
sleep 2
ifconfig slcan0 up

Description

The solution combines utilizing at to avoid udev killing the script for taking too long as well as a, slightly, magic sleep at the start of slcan_add.sh. Running slcan_add.sh from the terminal manually works without the sleep, but for some reason the udev rule refuses to without the sleep, I don't know why and I don't want to troubleshoot this anymore.

If someone finds a cleaner solution then I'll accept it.

Morten Nissov
  • 130