USB key dongle for oeSENC

[bdbcat]

Ralph....


There is no easy solution here. The dongle support logic is loaded by a "dlopen" call, so static build against a specific glibc version won't work in the general case.


I will investigate alternatives. What exact version of Scientific linux are you running? AMD_64, or i686?



Dave

[RalphG]

Thank you for your answer, Dave; I'm using SL 7.5 (x86_64) now on my onboard system, which is not up to date, but I didn't want to invalidate my system key by updating, and 7.7 has the same libc version anyway. SL is discontinued after 7.X, but there is already CentOS 8.0 available as another Red Hat clone. Maybe with CentOS 8 the current oeserverd will work, but I'm afraid the system key will change and I will loose all my oeSENC charts assigned to the old system key. I intended a smooth migration: assign all newly purchased charts to the dongle while the older charts still work with the system key.

Of course, using explicit dlopen makes it impossible to build the oeserverd statically - but would it do any harm to build it (and the dll you depend on) against an older libc?

I'm a bit surprised that nobody else seems to use OpenCPN on these Red Hat based distributions (on the RPM repository mentioned I could not find a 3.0 oeSENC plugin) - I got used to RHEL with my professional work, and it's very reliable and stable, not a bad choice for a navigational system. However, I would expect the same problem also to arise with other distributions - once you have a working system with assigned charts, there's good reason not to change it. I think the dongle is a perfect solution to get around this system key mess in the future (while not updating the system isn't); if there are alternatives for a smoother migration I'll be happy, otherwise I will wait a while and after all charts have expired, renew them with a dongle and a newly installed system. Since last year I'm using OpenCPN with oeSENC charts as my only electronic navigational system, and after 6.000 miles from northern Norway to southern Spain, I'm very happy with it - thank you very much for this great work!

Originally Posted by bdbcat

Ralph....


There is no easy solution here. The dongle support logic is loaded by a "dlopen" call, so static build against a specific glibc version won't work in the general case.


I will investigate alternatives. What exact version of Scientific linux are you running? AMD_64, or i686?



Dave

[bdbcat]

Ralph...


I worked on this a while last night, but not great news.
I'll tell you what I did, geektalk follows:


Using docker and "holy build box", I made a version of oeserverd with older GLIBC (2.2.5, I think). Booted up a SL 7.5 virtual machine for test. oeserverd starts up OK, so GLIBC dependency satisfied.

Found that SL did not come with libusb. So yum install it. Try to run oeserverd. Segfault after dlopen of dongle library, in libusb.


Full stop. I do not have the source to the dongle support library, so no idea whether the dongle code is bad, or libusb is bad. Waiting to talk to dongle code devs....


Of course, the problem could be related to VBox, but I have not had dongle trouble on other guest platforms. Maybe I could send you the oeserverd binary for a try on real hardware? Any other insight on libusb 1.4 in SL environment?


Dave

[RalphG]

Dave,

never had any problem with libusb or heard of one ...

I guess the dll you are using is the one in the oeserverd directory? ldd shows all dependencies satisfied, so the library itself is build against an older libc.

Yes, please send me your oeserverd binary, I'll be happy to try it out!

Thank you so much for your efforts!

Originally Posted by bdbcat

Ralph...


I worked on this a while last night, but not great news.
I'll tell you what I did, geektalk follows:


Using docker and "holy build box", I made a version of oeserverd with older GLIBC (2.2.5, I think). Booted up a SL 7.5 virtual machine for test. oeserverd starts up OK, so GLIBC dependency satisfied.

Found that SL did not come with libusb. So yum install it. Try to run oeserverd. Segfault after dlopen of dongle library, in libusb.


Full stop. I do not have the source to the dongle support library, so no idea whether the dongle code is bad, or libusb is bad. Waiting to talk to dongle code devs....


Of course, the problem could be related to VBox, but I have not had dongle trouble on other guest platforms. Maybe I could send you the oeserverd binary for a try on real hardware? Any other insight on libusb 1.4 in SL environment?


Dave

[bdbcat]

Ralph...


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


It is called oeaserverd, temporary name.
Exercise it:

$oeaserverd -t      (this gets dongle serial number)



or


$oeaserverd -s      (this returns 0 or 1 on dongle detect)

You will need to ensure that libsgl.....so is somewhere accessible, such as /usr/lib


If it works, rename to "oeserverd", put it in /usr/bin, and then oeSENC_PI should find it.


Good Luck
Dave

[RalphG]

Dave,

the binary executes without any problem; I do not have a dongle at hand right now, so I cannot query the serial number, but already for detection the dongle library will need to interact with libusb, I guess. I'm sailing in the moment so I have no postal address, but I planned to order two dongles for December when I'm back home, then I can try with real hardware (but I will be passing by Castelldefels in a week or so, perhaps I can convince Hubert to deliver on board ;-)). I'll let you know the results ...

It seems to me that it's not really essential if you build on a (virtual) Red Hat / SL / CentOS environment - the oeserverd that came with oeSENC-2.6.0 did work, so I guess an older version of your usual environment would also do.

Anyway, if this binary works, I will have a way to slowly migrate my charts and hopefully won't have to bother you again when there's the next version of oeserverd :-)

Thank you so much!

Ralph

[bdbcat]

Ralph...


The binary executes. Good.
When you say $oeaserverd -s, do you get output "0". Or no output at all?


Dave

[RalphG]

Originally Posted by bdbcat

When you say $oeaserverd -s, do you get output "0". Or no output at all?

Sorry if this was misleading; I do get output:

[ralph@heisenberg ~]$ oeaserverd -s
after initlock
0

BUT ... after this success, I thought I could copy your new oe(a)serverd binary into my newly compiled plugin code, build an RPM and start using it with my charts licensed to the old system identifier ... well, I could do that, the plugin is loaded, the existing charts are listed in the popup window as usual, but I can just see the outlines. The log says:

16:23:59 CET:  ------- Starting OpenCPN -------
16:23:59 CET: 5.0.0
[...]
16:24:02 CET: PlugInManager:  /usr/lib64/opencpn/liboesenc_pi.so
              API Version detected: 111
              PlugIn Version detected: 303
16:24:02 CET: Path to oeserverd is: /usr/bin/oeserverd
16:24:02 CET: IsDongleAvailable()::oeserverd execution results:
16:24:02 CET: after initlock
16:24:02 CET: 0
16:24:02 CET: No Dongle detected
[...]
16:24:05 CET: validate_SENC_server
16:24:05 CET: Validation Path to oeserverd is: /usr/bin/oeserverd
16:24:05 CET: Validation Path to server test is: /usr/bin/oeserverd
16:24:05 CET: oesenc_pi: Checking oeserverd utility at {/usr/bin/oeserverd}
16:24:05 CET: oesenc_pi: starting oeserverd utility: /usr/bin/oeserverd
16:24:09 CET: oesenc_pi: oeserverd-Dienstprogramm auf {/usr/bin/oeserverd} berichtet: Nicht verfügbar.

So oeserverd first can be executed, and then it's not available??? Any idea what's going wrong here?

Ralph

[bdbcat]

Ralph...


Yes, I think I know do know.
The extraneous debug line: "after initlock" is confusing the dongle detection, for sure.
Not sure why the server does not work for older licensed charts. Will take a look.


The fact that it prints "after initlock" is very good, though. I see light in the tunnel. No segfault in libusb. Now we need to get you a dongle.


Dave

[RalphG]

Originally Posted by bdbcat

Yes, I think I know do know.
The extraneous debug line: "after initlock" is confusing the dongle detection, for sure.
Not sure why the server does not work for older licensed charts. Will take a look.
Dave

Aah, I see ... so this output isn't there in the 'normal' oeserverd ...

Originally Posted by bdbcat

The fact that it prints "after initlock" is very good, though. I see light in the tunnel. No segfault in libusb. Now we need to get you a dongle.
Dave

Yes, next week I will get quite close to o-charts, perhaps I really can drop in and get one, but I'm not sure, depends on weather, of course; if not, I can try when at home in 4 weeks.

Ralph

[crayiii]

As someone currently relying on orSENC for the Bahamas, it really sucks getting the message the the charts I paid for aren't working on our win 10 computer after using them for a week.

Nothing that I know of changed on the PC.

They really need to fix the authentication method if we are to rely on the product.

[RalphG]

Originally Posted by crayiii

As someone currently relying on orSENC for the Bahamas, it really sucks getting the message the the charts I paid for aren't working on our win 10 computer after using them for a week.

Nothing that I know of changed on the PC.

They really need to fix the authentication method if we are to rely on the product.

I think the dongle *is* the authentication method you are looking for; if you havn't assigned your charts to two systems already, you could order one and assign your charts to it - and be redeemed from win10's quirks from then on. Regarding the changed system fingerprint, I would recommend to contact the o-charts people, I'm sure you will get help.

Ralph

[o-charts.org]

Originally Posted by crayiii

As someone currently relying on orSENC for the Bahamas, it really sucks getting the message the the charts I paid for aren't working on our win 10 computer after using them for a week.

Nothing that I know of changed on the PC.

They really need to fix the authentication method if we are to rely on the product.

crayiii, Windows 10 is the only system and version where sometimes a silent security update can kill your license. Obviously Microsoft does not notify us about these killer updates nor why this happens. For these rare cases we restore your license after checking it. Write us an email with your account or order reference please.



Security or any other updates do not affect your licenses in Linux, Android, Mac or the rest of windows versions.

[crayiii]

Originally Posted by o-charts.org

crayiii, Windows 10 is the only system and version where sometimes a silent security update can kill your license. Obviously Microsoft does not notify us about these killer updates nor why this happens. For these rare cases we restore your license after checking it. Write us an email with your account or order reference please.

Security or any other updates do not affect
your licenses in Linux, Android, Mac or the rest of windows versions.

You really need to either figure out something different or make it very clear that the charts won't be reliable on Windows 10. As it sits now, I'm not able to use the chart sets that I purchased.

[bdbcat]

crayii...


from o-charts:


For these rare cases we restore your license after checking it. Write us an email with your account or order reference please.

Have you actually responded to this offer for help? I expect you will get your charts back after one email exchange.


Dave