Using USB Dongle on two computers does not work

[gromain]

Hello,

I encountered a problem when trying to setup the dongle on my Raspberry Pi 4. I've configured Opencpn on my personal computer running Manjaro. I'm using the latest git version compiled from sources, as well as the latest oesenc-pi version also compiled from sources (I'm using the packages from the Arch User Repository I'm maintaining, respectively here and here).

On this machine, I've set up the charts using the USB dongle bought from o-charts.org.

When I've tried to do the same on the Raspberry Pi 4, I first ran into problems with CMakeLists.txt, where the architecture was not correctly detected. I've created a patch I have to apply in order for this happen. The patch is available here. It's building up on PR #51 .

When plugging the dongle in the Raspberry and trying to download the charts, it offers me to chose the system. If I select the dongle (sgl001....... )I have an error message:

o-charts API error code: {9}
610:This system name already exists but fingerprint does not match
Operation cancelled

If I try to create the fingerprint file for the dongle in the plugin settings, I then have an error that says ERROR Creating Fingerprint file USB key dongle not detected.. Even after adding the udev rules as in #95, nothing changes.

Nothing special appears in opencpn.log, just the line oesenc_pi.cpp:3949 Create FPR command: /usr/bin/oeserverd -k "/home/carlina/.opencpn".

On my computer, there are 3 fingerprint files, all of them are 95 bytes long and their name starts with oc03X. oeserverd -a answers with oeserverd Version 1.16.

On the Raspberry, the fingerprint files created are 242 bytes long and their name starts with oc03L. oeserverd -a answers with oeserverd Version 1.17.

[gromain]

As an addition, on the Raspberry oeserverd -k ./ does nothing, even with the USB dongle inserted (on my computer, it creates a 95 bytes long FPR file). Dmesg shows the following when plugging the dongle:

[ 7576.602912] usb 1-1: New USB device found, idVendor=1547, idProduct=1000, bcdDevice= 0.01
[ 7576.602917] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 7576.602920] usb 1-1: Product: SG-Lock USB Key
[ 7576.602923] usb 1-1: Manufacturer: SG-Lock
[ 7576.605489] hid-generic 0003:1547:1000.0007: hiddev1,hidraw4: USB HID v1.00 Device [SG-Lock SG-Lock USB Key] on usb-0000:00:14.0-1/input0

Udev rule is properly triggered.

[bdbcat]

@gromain On rPI4, what OS are you using, exactly? Are you building OCPN from source, or installing from PPA?
If building from source for rPI4, why not use the pre-built versions available in PPA or cloudsmith? Same for oesenc_pi...

Please try, and report results: $/usr/bin/oeserverd -a $/usr/bin/oeserverd -s $/usr/bin/oeserverd -t

$ldd /usr/bin/oeserverd

Thanks

[gromain]

Hi @bdbcat , On my main computer:

 rbazile@rbazile-xps $ /usr/bin/oeserverd -a
oeserverd Version 1.16

 rbazile@rbazile-xps $ /usr/bin/oeserverd -s
0
 rbazile@rbazile-xps $ /usr/bin/oeserverd -t
0
 rbazile@rbazile-xps $ ldd /usr/bin/oeserverd
        linux-vdso.so.1 (0x00007ffd884e2000)
        libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fc12ad3f000)
        libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fc12ad39000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007fc12ab5c000)
        libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007fc12ab42000)
        libc.so.6 => /usr/lib/libc.so.6 (0x00007fc12a97b000)
        /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fc12add5000)
        libm.so.6 => /usr/lib/libm.so.6 (0x00007fc12a836000)

On the Raspberry Pi 4:

carlina@nav-carlina $ /usr/bin/oeserverd -a
oeserverd Version 1.17

carlina@nav-carlina $ /usr/bin/oeserverd -s
0
carlina@nav-carlina $ /usr/bin/oeserverd -t
0
carlina@nav-carlina $ ldd /usr/bin/oeserverd
        linux-vdso.so.1 (0x0000007f811d5000)
        libpthread.so.0 => /usr/lib/libpthread.so.0 (0x0000007f81126000)
        libdl.so.2 => /usr/lib/libdl.so.2 (0x0000007f81112000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x0000007f80f0c000)
        libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x0000007f80ee8000)
        libc.so.6 => /usr/lib/libc.so.6 (0x0000007f80d7b000)
        /lib/ld-linux-aarch64.so.1 => /usr/lib/ld-linux-aarch64.so.1 (0x0000007f811a6000)
        libm.so.6 => /usr/lib/libm.so.6 (0x0000007f80cd1000)

[gromain]

Any update here? Anything more I can do to help debug?

Oeserverd not being open-source is a real problem here, since I can't even try and help by debugging directly (also, good crypto doesn't need to be closed source, if proper method are used everything can be public, security by obscurity is not a good way of securing things).

[bdbcat]

I ask again: On rPI4, what OS are you using, exactly? There are many choices, and it does make a difference....

[gromain]

Hi,

Sorry, I didn't realize I missed your first question!

I'm running Manjaro Arm. It's a 64bit OS, Arch Linux derivative.

I'm building both Opencpn and this plugin from sources (from the latest git commit), using the PKGBUILD that can respectively be found here and here.

I'm building from sources because those packages are not available in repositories for my OS and architecture.

[gromain]

Hi,

Any update here? Anything I can try on my side to help or any information missing?

[bdbcat]

@gromain Worked on this. The root problem is that oeserverd depends on libsglarm64-2.31.0.0.so, which in turn depends on libusb-0.1.so.4 But, on Manjaro, the libusb available from pacman is libusb-1.0.so. So, dynamic load/link fails.

[dsr@ManjaroArm ~]$ ldd libsglarm64-2.31.0.0.so
        linux-vdso.so.1 (0x0000007fb5816000)
        libusb-0.1.so.4 => not found
        libpthread.so.0 => /usr/lib/libpthread.so.0 (0x0000007fb5782000)
        libc.so.6 => /usr/lib/libc.so.6 (0x0000007fb5615000)
        /usr/lib/ld-linux-aarch64.so.1 (0x0000007fb57e8000)

Workaround solution: Find and load libusb-0.1.so.4. for arm64 I found a compatible package here: http://ports.ubuntu.com/pool/main/libu/libusb/libusb-0.1-4_0.1.12-32_arm64.deb

1. Extract the libusb-0.1.so.4 from the package.
2. copy to /usr/lib
3. run $sudo ldconfig

After doing this, "oeserverd -t" should report non-zero. I did not try on full OCPN, and oesenc_pi. I am running Manjaro Arm64 headless, using ssh to a CLI, so no GUI access to desktop. But if oeserverd works from CLI, it should work in general.

Good Luck Dave

[gromain]

Perfect, that did the trick.

I'll put this changes in the PKGBUILD so the path is easier for others to follow.

Thanks a lot for your time.