CAN interface udev rename rule not applying

Technical Support
, , , ,
1

Hello,
this issue started to bugger me again. I’ve created rule file like this:

#11-rename-can.rules
KERNELS=="spi0.0", SUBSYSTEMS=="spi", DRIVERS=="mcp25xxfd", ACTION=="add|bind|change", NAME="can1"
KERNELS=="spi2.0", SUBSYSTEMS=="spi", DRIVERS=="mcp25xxfd", ACTION=="add|bind|change", NAME="can0"

But the rule is applied every random boot. In that cases Ive managed to appliy it by rmmod mcp driver and modprobing it again:

sudo rmmod mcp25xxfd
sudo modprobe mcp25xxfd

This is my current torizoncore version:

5.4.115-rt57-5.3.0+git.dbdbcabf0f98 #1-TorizonCore SMP PREEMPT_RT
2

For some reason when I give interfaces names other than can#, for example CAN#, after the reboot interfaces get renamed.

3

Greetings @spasoye,

Seems there is some weird kernel/udev bug when trying to use udev rules to give the name can# as you said. I imagine it’s some weird conflict since the default names the kernel provides are already in the form of can#. Like you said though giving names in other forms like CAN# does not have this issue.

Will using these other naming schemes suffice for you? Or does it have to be in the form of can# for some reason?

Best Regards,
Jeremias

4

We are developing PLC on Verdin and we are using Codesys runtime for that purpose, Codesys does not recognize CAN# name format of interfaces and I haven’t figured out how to change this since the Codesys documentation seems pretty scarce.

5

To rename interface new interface name should be not used. What about renaming them to can5/6, can10/11, or perhaps can00/01. These should work better than moving ±1 already existing can0/can1.

1 Like
6

It is correct that you cannot reliably assign the names can0, can1, since that causes a naming conflict with the enumeration of the interfaces by the driver.

But, you can use your rule to assign new names to be whatever you prefer.
Eg. spican0, spican1
You can then change the base CAN interface name in CoDeSys in the CODESYSControl.cfg file like this:
[CmpSocketCanDrv]
InterfaceName=spican

This is the way that we have bound the physical interface to the name.

Codesys seems to want to number the interfaces 0, 1, …
This meant that we couldn’t just randomly assign a number - though we didn’t really investigate that since the above solution works for us

7

Hey @andyha this morning I made workaround that makes use of reloading the mcp25xxfd module, so I created service that is run on boot and executes reload script:

##### can_rename.sh #####
#!/bin/bash

echo "renaming interfaces"

sudo rmmod mcp25xxfd
sudo modprobe mcp25xxfd

##### codesys_can_rename.service #####
[Unit]
Description=Rename external CAN to can1, and internal to can0
After=systemd-resolved.service connman.service

[Service]
Type=simple
ExecStart=/usr/sbin/can_rename.sh

[Install]
WantedBy=docker.service

But your solution is much more intuitive. Can I ask you where do you look for answers/solutions when you encouter problems with Codesys ?

Thanks @andyha.

8

That’s not easy to answer. Often doing web search is just as fruitful as trying to find it in the documentation. The documentation describes the interfaces and so if you don’t know what you’re looking for then it is frustrating, but in this case I knew that I should look at the SocketCAN interface.