Daemon version is out of date with Driver

[mparuzel]

Currently it seems the daemon and driver are incompatible:

$ sudo ./libicsneo-socketcan-daemon
The libicsneo SocketCAN Usermode Daemon
Copyright Intrepid Control Systems, Inc. 2023

Daemon v3.1.1
libicsneo v0.3.0 HEAD @
Driver v3.0.2

The kernel driver reports an incompatibility with this version of the usermode daemon
Please ensure that both the usermode daemon and kernel driver are up to date

The kernel code has the following check (looking for v3.0.0):

        case SIOCGCLIENTVEROK:
            if (VER_MAJ_FROM_INT(arg) == 3 && VER_MIN_FROM_INT(arg) == 0 && VER_PATCH_FROM_INT(arg) >= 0)
                ret = 0; /* ok to start */
            else
                ret = 1;
            break;

Seems the two repos are a bit out of date.

[captroy]

Hello, I've been struggling with this error as well. I found a 'solution', more of a work around. Edit line 2 of the CMakeLists.txt to version 3.0.0 instead of 3.1.1.

This will at least suppress the error, and allow you to load the daemon, and use can0.

[pottsdl]

I've also experienced this issue.

There are constants at the top of intrepid.c which look to be used elsewhere for versioning purposes, and seems odd they are used in this case.

 58     #define KO_DESC "Netdevice driver for Intrepid CAN/Ethernet devices"
 59     #define KO_MAJOR 3
 60     #define KO_MINOR 1
 61     #define KO_PATCH 0
 62     #define KO_VERSION str(KO_MAJOR) "." str(KO_MINOR) "." str(KO_PATCH)
 63     #define KO_VERSION_INT (KO_MAJOR << 16) | (KO_MINOR << 8) | KO_PATCH

I fixed in my case this way (by fixing the Kernel Module side):

 978     case SIOCGCLIENTVEROK:
 979       /* if (VER_MAJ_FROM_INT(arg) == 3 && VER_MIN_FROM_INT(arg) == 1 && VER_PATCH_FROM_INT(arg) >= 0) */
 980       if (VER_MAJ_FROM_INT(arg) == KO_MAJOR && VER_MIN_FROM_INT(arg) == KO_MINOR && VER_PATCH_FROM_INT(arg) >= 0)
 981         ret = 0; /* ok to start */

Which assumes that checking for a Major-Minor version match continues to be the right paradigm.

[dcanthony68]

I've got this same issue. The work around should definitely fix the problem. This issue is approaching 2 months old and the fix to compare versions seems simple. I'm surprised this hasn't been fixed in the official source code.

[pottsdl]

Appears that this was fixed in the Kernel Module as of 9/8 (thanks @kschwarz-intrepidcs ), this issue can probably be closed on the icsscan side now.