Udev and two CAN bridges

[YaaJ]

Basic Information:

Printer Model: Voron 2.4
MCU / Printerboard: Octopus + BTT MMB Cubic (CAN bridge + GPIO expander) + EBB36 (toolhead)
Host / SBC : Pi 4
klippy.log : not relevant in this issue

I need a second CAN Bridge that will be installed in a MMU (non standard Box Turtle MMU - 5 lanes - full CANbus). USB → EBB36(CAN bridge + GPIO) → EBB36_1 to EBB36_5

I found interesting information here : Setting Up udev rules for multiple canbus interfaces , and followed the instructions.

But no luck. I’m able to get udev to do what it has to when only one CAN bridge is installed. Works fine, with a custom peripheral name (“can_tool”).
Then the same thing with the second CAN bridge (“can_mmu”) : fail ! As soon as a second adapter is added to the systerm, Linux seems not to be using the udev configuration, and randomly assigns peripheral names. If the second bridge is not configured with udev, the OS randomly assigns can0 or can1. I can get a valid configuration after unpluging-replugging the USB cable a few times ; not acceptable !

What am I missing ??? Could this be related with this bug ? : Debian 11 (Bullseye) udev bug - No board or serial found

Pulling my hair and completely stuck (for 3 days)…

[Sineos]

Overall, this seems like a decent approach to shoot oneself in the foot.

Honestly, if these are stationary controllers then I’d rather use USB than CAN, but if you insist on doing it the “CAN Way” then check Multiple printers on a single CAN bus (a cautionary tale?) - #8 by novaplusplus

Udev can be quite tricky and is not easy to debug.

[willpuckett]

Can you post the udev rules you created, as well as the content of the files in /etc/network/interfaces.d?

[YaaJ]

Thanks for your answer, and for the link !

The problem is that I don’t really have choice, each MMU lane having to be on a CAN bus ! I want to “daisy chain” the GPIO expander and 5 identical lanes, as well as add as many as needed/wanted lanes (“legs”), and not a hub + massive rats nest made of USB cables.

Now reading the thread you linked…

[EDIT] I’ve been using a EBB36 as CAN bridge for a while without any problems (before it was replaced with a BTT MMB Cubic)

[YaaJ]

SUBSYSTEM=="net", ACTION=="add", ATTRS{serial}=="504434031083BA1C", NAME="can_tool"
SUBSYSTEM=="net", ACTION=="add", ATTRS{serial}=="0000:01:00.0", NAME="can_mmu"

The serial "0000:01:00.0" looks weird. Tested with 3 different EBB36s, two used and one brnad new, flashed and reflashed, always get the same. Looks suspicious…
Got “Serial” with one bridge attached (the other being disconnected from its USB port)

[willpuckett]

yes, it does seem like the second serial is incorrect.

For comparison, I have in /etc/udev/rules.d/z21_persistent-local.rules

SUBSYSTEM=="net", ACTION=="add", ATTRS{serial}=="420042000550304B57303220", NAME="cantau"
SUBSYSTEM=="net", ACTION=="add", ATTRS{serial}=="39003B000E53544232323020", NAME="canrho"
SUBSYSTEM=="net", ACTION=="add", ATTRS{serial}=="490033000F50475532323820", NAME="canphi"

and cat /etc/network/interfaces.d/* returns

allow-hotplug canphi
iface canphi can static
    bitrate 1000000
    up ip link set $IFACE txqueuelen 128
allow-hotplug canrho
iface canrho can static
    bitrate 1000000
    up ip link set $IFACE txqueuelen 128
allow-hotplug cantau
iface cantau can static
    bitrate 1000000
    up ip link set $IFACE txqueuelen 128

[willpuckett]

Are you running udevadm info -a -p $(udevadm info -q path -p /sys/class/net/can0)| grep serial| head -n 1 to find the serial? If so, I’m curious if you run udevadm info -a -p $(udevadm info -q path -p /sys/class/net/can0)| grep serial instead do you find something that makes more sense?

(Of course change the interface name if needed…)

[willpuckett]

Also try doing the names without the underscores I have a vague recollection that may not be kosher…

[willpuckett]

@YaaJ

ATTRS{serial}=="0000:01:00.0"

looks more like a path than a serial…

You aren’t beholden to using the serial for your rules… I chose it because it was unique, but you could also for instance assign it via the specific usb port… I have my machine stuffed in a closet ahnd I sometimes have to unplug everything to remove it, so I tried to choose a key that would work well regardless of how I reconnected things…

[YaaJ]

@willpuckett

udevadm info

Thanks for your answers.
Yes, I got the Serials with udevadm info

Was thinking of one detail I overlooked. koconnor warns that not having at least one CAN device on a bus leads to unstable results. And it was done with no device on the bus… Have to fix this before going further.

Will try later witthout underscores : removed everything for now (returned to defaults), letting Linux assign the bus names (flashing EBBs with the lightest possible configuration, and a can0 alone)

BTW, discovered that if canXX is assigned by Linux (defaults), I always get can0 for the tool CAN bus, and can1 for the mmu bus… I don’t trust it, but it seems it is usable. Will later swap USB ports to see what happens…

[willpuckett]

@YaaJ

Yes, I got the Serials with udevadm info

for sure but it might be interesting to run it without piping to head to see if your device has multiple serial keys…

Oops, that will show serials for the parent devices. (Sorry, haven’t had coffee yet.)

Running udevadm info -a -p $(udevadm info -q path -p /sys/class/net/cantau) for me returns (some output removed for brevity)

  looking at device '/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/net/cantau':
    KERNEL=="cantau"
    SUBSYSTEM=="net"
    ATTR{tx_queue_len}=="128"
    ATTR{type}=="280"

  looking at parent device '/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0':
    KERNELS=="1-2:1.0"
    SUBSYSTEMS=="usb"
    DRIVERS=="gs_usb"

  looking at parent device '/devices/pci0000:00/0000:00:14.0/usb1/1-2':
    KERNELS=="1-2"
    SUBSYSTEMS=="usb"
    DRIVERS=="usb"
    ATTRS{devnum}=="13"
    ATTRS{devpath}=="2"
    ATTRS{idProduct}=="606f"
    ATTRS{idVendor}=="1d50"
    ATTRS{manufacturer}=="Klipper"
    ATTRS{product}=="stm32f407xx"
    ATTRS{serial}=="420042000550304B57303220"
    ATTRS{speed}=="12"
    ATTRS{tx_lanes}=="1"
    ATTRS{urbnum}=="14890"
    ATTRS{version}==" 2.00"

  looking at parent device '/devices/pci0000:00/0000:00:14.0/usb1':
    KERNELS=="usb1"
    SUBSYSTEMS=="usb"
    DRIVERS=="usb"
    ATTRS{idProduct}=="0002"
    ATTRS{idVendor}=="1d6b"
    ATTRS{manufacturer}=="Linux 6.1.0-27-amd64 xhci-hcd"
    ATTRS{serial}=="0000:00:14.0"
    ATTRS{speed}=="480"
    ATTRS{version}==" 2.00"

So your ATTRS{serial}=="0000:01:00.0" is the serial of your usb hub (internal), and Udev is probably matching any network device plugged into it in your “can_mmu” rule…

When you plug things in, before running udevadm, run lsusb and make sure you see the device. You also might want to run udevadm info -a -p $(udevadm info -q path -p /sys/class/net/can0) (or can1 whichever is showing up in ip link show) and just read through the output…

[YaaJ]

Did it, and don’t understand the results…

First of all there’s 2 CAN busses running.
On for the toolhead, assigned by Linux, can0 CAN bridge + toolhead. Based on a RP2040. Legit Serial with udevadm. Can play with the fan, etc.
Second one, assigned by Linux, can1. EBB36 as bridge + GPIO expander, and a EBB36 node ; STM32. working.
I use RGB LEDs as “probes”. Can access them, change color, etc.

Then, udevadm…

I compared the outputs using winmerge. The ATTRS{serial} line is missing for The can1 bridge… (can1 on the left, can0 on the right)

No idea how to interpret this !

[willpuckett]

How interesting!

Do you anticipate using additional g0b1s in canbus bridge mode? If not, I’d try using

SUBSYSTEM=="net", ACTION=="add", ATTRS{product}=="stm32g0b1xx", NAME="canmmu"

for the Udev rule…

[YaaJ]

Will do this ASAP (= now)
I just swapped the USB ports to see what happens : can0/can1 depends on the USB port on the Pi. Could be a workaround…

[YaaJ]

It works. At least it seems to be working.
Was thinking of something… No serial with the STM32. In klipper/make menuconfig , we have an option for a custom USB Serial Number. Could the missing serial be this one (by default : empty) ???

[YaaJ]

And Bob’s your uncle, winner winner chicken dinner (some idiomatics learnt on eevblog)

Got a UUID from some online generator. Kept the first 16 characters. Entered it in the Klipper menuconfig, recompiled, reflashed.

And got this !!!

[willpuckett]

My ‘USB serial number from CHIPID’ seems to be selected by default… I had a EBB36 on my desk and just flashed with Katapult then Klipper in bridge mode, then ran udevadm info -a -p $(udevadm info -q path -p /sys/class/net/can0)| grep serial| head -n 1 and got ATTRS{serial}=="2C0043000B50304158373420" without having any other devices connected to it.

I just tried changing Klipper menuconfig option to an empty serial, and it reproduces your problem… I’ll update the instructions to explicitly reflect the necessary menuconfig settings!

[YaaJ]

Really weird… Default was “1234” for “USB serial number” and pretty sure “USB serial number from CHIPID” was selected… We will never know what happened. But it is something to be aware of. Will reflash (again !) with “USB serial number from CHIPID” and see what happens. Thinking of “(1234) USB serial number” being selected, and “1234” being rejected. And this for one year or so… The main menu doesn’t show the current USB ID. Maybe a relevant FR to do on Github…

[EDIT] the more I’m thinking of it, the more I’m thinking the problem was beteween the chair and the keyboard… But no whistles and no bells about the USB IDs… And english is not my first langage. And nearly 70 yo. Some neurons now are missing…