Is there a reason for not storing the bus speed on exit/load when save connections is enabled?

[consp]

Since I'm trying to get my own device working with savvycan I noticed the bus speed is not stored on exit. Is there a reason not to do this? In my case it would be welcome (and I already did it in a fork) since the slcan like protocol I use with multiple bus support and kind of needs to set the speed every time on start. I'm also working on a slcan driver since I dislike the socketcan/slcand method but I'm quite certain that will not be up to mergeable quality anytime soon.

I actually already have it working but the question is for knowing if I even want to attempt a pull request since there might be a good reason for it not to be done in the first place.

[collin80]

The reason is merely one of legacy. You see, at first, and for several years, the GVRET interface was all there was. No socketcan or anything. The GVRET devices use EEPROM to store the speed so once it is set it stays that way. As such, I never had any real reason to store the speed as the hardware had it stored. Then I added socketcan and that you configure on the command line so there was still no reason to store the speed. Now more interfaces are supported and I can see that it might be useful for some of them. So, I don't have any objection against adding this functionality.

[mickeyl]

I guess the problem is also that with socketcan interfaces you can't reconfigure a CAN interface without possessing CAP_NET_ADMIN or running the app as root, so it's a bit useless anyways.

Did you ever think about splitting parts of the app into a dedicated daemon? This one could then run with the necessary privileges and (re)configure the interface(s) on behalf of the UI app.

[consp]

I guess the problem is also that with socketcan interfaces you can't reconfigure a CAN interface without possessing CAP_NET_ADMIN or running the app as root, so it's a bit useless anyways.

It's one of the many reasons I'm working to get rid of socketcan and talk to the device directly since most serial busses can be talked to without root access. At least if you configure it that way. The slcan reference here is simply a Lawicel protocol to socketcan translator implemented in linux and some DIY canbus adapters use it (mainly arduino based ones) since it's simple and readily available and uart support is pretty much commonplace in linux.

My attempt for saving the bus speeds can be found here: https://github.com/consp/SavvyCAN/commits/remember-busspeed

I'm not a c++/qt programmer so especially all the thread synchronization stuff and c++/qt quirks are not common to me and might be wrong.

[driftregion]

Two bad approaches for supporting reconfiguration of socketcan interfaces:

1. enabling CAP_NET_ADMIN with sudo setcap cap_net_admin,cap_net_raw=eip SavvyCAN and calling socket() and setsockopt() as in https://code.woboq.org/qt5/qtserialbus/src/plugins/canbus/socketcan/socketcanbackend.cpp.html
2. enabling sudo /etc/sbin/ip link set can... commands without password via visudo, then invoking ip via system(). ip has a JSON interface that is enabled with the -j flag. ip -j link list type can

A third option is just to setup hotplugging if reconfiguration isn't actually that important:
on platforms with systemd like ubuntu you can create a persistent service that sets the can interface up as soon as you plug it in.

create /etc/systemd/network/50-can0.network with contents:

[Match]
Name=can0

[CAN]
BitRate=500K

then run

sudo systemctl enable systemd-networkd.service
sudo systemctl start systemd-networkd.service

references:

• https://wiki.archlinux.org/title/systemd-networkd
• https://embeddeduse.com/2019/05/24/speaking-can-request-and-response/