USB key dongle for oeSENC

[bcn]

Ask SG directly?


We have done this already in the past for ARM64. Perhaps more voices are helpful...


Hubert

[hreuver]

Originally Posted by bcn

Ask SG directly?

We have done this already in the past for ARM64. Perhaps more voices are helpful...

Frankly, I already sent a question.

The solution of using ARMHF means a oneway ticket to a dependency hell. Perhaps a short-term solution but certainly not the holy grail.
That, or github...

Probably the worst of both worlds..

[bdbcat]

RalphG...


Try this:
https://www.dropbox.com/s/l7vim1yjis...easerverd?dl=0


As before, rename to "oeserverd", etc....


Good Luck
Dave

[RalphG]

Dave,

thank you very much for the christmas present :-)

Dongle detection and serial number output works as it did with the previous version, just without the debug output. So I installed the 3.X oeSENC plugin and copied the latest oeaserverd in place of the original oeserverd.

OpenCPN starts up without errors and shows the correct list of available charts, but startup takes much longer time than before (~10s). Still, I can only see the chart outlines.
Here's what the log says:

12:31:58 CET:  ------- Starting OpenCPN -------
12:31:58 CET: 5.0.0
...
12:32:00 CET: PlugInManager: Loading PlugIn: /usr/lib64/opencpn/liboesenc_pi.so
12:32:00 CET: Loadconfig adding info string: Britische Inseln und Nachbarregionen 2019;2019-2;2020-04-08
12:32:00 CET: Loadconfig adding info string: Deutsche Gewässer 2018;2019-1;2019-01-04
12:32:00 CET: Loadconfig adding info string: Dänemark 2018;2018-4;2019-08-30
12:32:00 CET: Loadconfig adding info string: Spanien 2019;2019-4;2020-04-08
12:32:00 CET: Loadconfig adding info string: Frankreich Atlantic 2019;2019-14;2020-04-08
12:32:00 CET: Loadconfig adding info string: Norwegen 2018 (Trondheim - Nordland);2019-8;2019-03-05
12:32:00 CET: Loadconfig adding info string: Norwegen 2018 (Lofoten - Troms - Finnmark);2019-8;2019-03-05
12:32:00 CET: Loadconfig adding info string: Norwegen 2018 (Østfold - Oslo - Agder);2019-8;2019-03-05
12:32:00 CET: Loadconfig adding info string: Norwegen 2018 (Rogaland - Møre og Romsdal);2019-8;2019-03-05
12:32:00 CET: PlugInManager:  /usr/lib64/opencpn/liboesenc_pi.so
              API Version detected: 111
              PlugIn Version detected: 303
12:32:00 CET: Path to oeserverd is: /usr/bin/oeserverd
12:32:00 CET: Loading World Chart Q=0 in 0 ms.
12:32:01 CET: IsDongleAvailable()::oeserverd execution results:
12:32:01 CET: 1
12:32:01 CET: Dongle detected
...
12:32:01 CET: PlugInManager: oeSENC has loaded very slowly: 911 ms
...
12:32:03 CET: Creating new chart
12:32:03 CET: ChartSymbols loaded from /usr/share/opencpn/s57data/chartsymbols.xml
12:32:04 CET: Using s57data in /usr/share/opencpn/s57data
12:32:04 CET: Initializing Chart /home/ralph/Seekarten/oeSENC/travelmate-ES-2019-4/OC-34-303002.oesenc
12:32:04 CET: processChartInfo /home/ralph/Seekarten/oeSENC/travelmate-ES-2019-4/OC-34-303002.oesenc
12:32:04 CET: validate_SENC_server
12:32:04 CET: Validation Path to oeserverd is: /usr/bin/oeserverd
12:32:04 CET: Validation Path to server test is: /usr/bin/oeserverd
12:32:04 CET: oesenc_pi: Checking oeserverd utility at {/usr/bin/oeserverd}
12:32:04 CET: oesenc_pi: starting oeserverd utility: /usr/bin/oeserverd
12:32:08 CET: oesenc_pi: oeserverd utility at 
{/usr/bin/oeserverd}
 reports Unavailable.

12:32:08 CET: validateUserKey
12:32:08 CET: Current userKey: yOcz-TwPK-69C7-TMWq-7qzu-jQ
12:32:08 CET: validateUserKey E1
12:32:08 CET: 
12:32:08 CET:    Cannot load SENC file /home/ralph/Seekarten/oeSENC/travelmate-ES-2019-4/OC-34-303002.oesenc
12:32:08 CET: Recoverable problem initializing Chart /home/ralph/Seekarten/oeSENC/travelmate-ES-2019-4/OC-34-303002.oesenc
12:32:08 CET:    OpenChartFromStack... Error opening chart /home/ralph/Seekarten/oeSENC/travelmate-ES-2019-4/OC-34-303002.oesenc ... return code 1
12:32:08 CET: Creating new chart
12:32:08 CET: Initializing Chart /home/ralph/Seekarten/oeSENC/travelmate-ES-2019-4/OC-34-303002.oesenc
12:32:08 CET: processChartInfo /home/ralph/Seekarten/oeSENC/travelmate-ES-2019-4/OC-34-303002.oesenc
12:32:08 CET: validate_SENC_server
12:32:08 CET: Available FALSE, retry... nLoop: 1
12:32:09 CET: Available FALSE, retry... nLoop: 2
12:32:09 CET: Available FALSE, retry... nLoop: 3
12:32:10 CET: Available FALSE, retry... nLoop: 4
12:32:10 CET: Available FALSE, retry... nLoop: 5
12:32:11 CET: Available FALSE, retry... nLoop: 6
12:32:11 CET: Available FALSE, retry... nLoop: 7
12:32:12 CET: Available FALSE, retry... nLoop: 8
12:32:12 CET: Available FALSE, retry... nLoop: 9
12:32:13 CET: Validation Path to oeserverd is: /usr/bin/oeserverd
12:32:13 CET: Validation Path to server test is: /usr/bin/oeserverd
12:32:13 CET: oesenc_pi: Checking oeserverd utility at {/usr/bin/oeserverd}
12:32:13 CET: oesenc_pi: starting oeserverd utility: /usr/bin/oeserverd
12:32:16 CET: oesenc_pi: oeserverd utility at 
{/usr/bin/oeserverd}
 reports Unavailable.
...
and so on
...
12:32:34 CET: PlugInManager: Deactivating PlugIn: /usr/lib64/opencpn/liboesenc_pi.so

It seems to me that oeserverd is working the first time it is used for dongle detection, but then never again. What surprises me is that the log says it is *starting* oeserverd again - isn't it meant to be running in the background after first start? I noticed that it *is* running, even after OpenCPN is closed; I have to kill oeserverd manually.

So, I'm afraid this is more or less the same as before - something with the interaction of plugin and oeserverd is going wrong. How is this possible when we were just trying to solve a libc version problem? What can I do, would it make sense to get me a new snapshot of the plugin sources and compile the plugin again?

Regards, Ralph

[RalphG]

Update: just tried with the newest source from github, version 3.3.14, compiled source and exchanged oeserverd after installation - same result, no charts, and 'oeserverd utility at
{/usr/bin/oeserverd} reports Unavailable.' in the log while dongle detection - manually and during OpenCPN startup - does work :-(

[cagney]

@RalphG

What response do get from this command

$ which oeserverd

?

[RalphG]

Originally Posted by cagney

@RalphG

What response do get from this command

$ which oeserverd

?

Cagney,

/usr/bin/oeserverd, which is the version I got from Dave with libc backward compatibility - the whole thing is about that the standard oeserverd does not work with my system due to unresolved GLIBCXX_3.4.20 and GLIBCXX_3.4.21 .. so, I'm afraid it's more than a confusion about different versions of oeserverd, but the thought appears likely, so thank you for asking :-)

[bdbcat]

RalphG...


Trying to reproduce your run-time environment. Fun...

Where did you find wxWidgets RPM?


Dave

[RalphG]

Hi Dave,

a happy new year to you!

Originally Posted by bdbcat

RalphG...


Trying to reproduce your run-time environment. Fun...

Where did you find wxWidgets RPM?


Dave

The standard RPMs from SL7.5:

wxBase3-3.0.2-15.el7.x86_64
wxGTK3-3.0.2-15.el7.x86_64
wxGTK3-gl-3.0.2-15.el7.x86_64
wxGTK3-media-3.0.2-15.el7.x86_64
wxGTK3-devel-3.0.2-15.el7.x86_64

This seems to become more complicated than a simple libc version problem ... an update to RHEL8 would also be an alternative for me, just not in the moment since I'm relying on the present install for navigation - won't touch this now. But I can do without the dongle, staying with maps licensed to the usual system key.

Thank you so much for trying to solve this problem!

Ralph

[bdbcat]

Ralph...


Thanks for the reply.
If you are not DIW at the moment, I am going to back-burner this project. My plate is overloaded with big-picture work just now.


Dave

[RalphG]

Dave,

yes, I can imagine there are more important things to do than fixing a single installation which is not up to date :-) As I wrote, I didn't expect this would be about more than not building the oeserverd against newest libc - I'll keep the dongles until I can update my systems. Thank you again for all your efforts!

Ralph

Originally Posted by bdbcat

Ralph...


Thanks for the reply.
If you are not DIW at the moment, I am going to back-burner this project. My plate is overloaded with big-picture work just now.


Dave

[bcn]

We got feedback from SG. Asking for the target systems for ARM64.


Ralph's is Scientific Linux 7.5
Other candidates?

[RalphG]

Originally Posted by bcn

We got feedback from SG. Asking for the target systems for ARM64.


Ralph's is Scientific Linux 7.5
Other candidates?

Hubert, you think my problems could be caused by the dongle library? Hmm, this would explain it better than assuming that oeserverd relies on changes in the very latest libc ... but did you notice I can still use oeserverd manually for dongle detection and serial number request? (still, this may not require more than libusb to work ...). If this is the case, any distribution with the same libc should be affected ... anybody with CentOS7/RedHat7 here?

If there's anything I can try out on my system to help, I'll be happy to do so.

Regards, Ralph

[hreuver]

Originally Posted by bcn

We got feedback from SG. Asking for the target systems for ARM64.

Ralph's is Scientific Linux 7.5
Other candidates?

I hope Ubuntu Bionic 18.04LTS is included (Mate or minimal).
I will be testing on Odroid N2.

If Bionic works I guess it will work on another system as well (Debian Buster).
I will test that also, but it will be simple tests, not "production".

PS I got the impression Ralph's system was AMD64(intel/amd), not ARM64(arm v8).

[RalphG]

Originally Posted by hreuver

PS I got the impression Ralph's system was AMD64(intel/amd), not ARM64(arm v8).

Oh yes, that's correct, of course - missed that out.