ShaunR

Indeed....but! We are looking at a 0.1% case so it's things like this we have to bear in mind. Error messages not being reported. My money is on it being used. You are probably in the 0.00001% of LabVIEW programmers that don't use it.

Without knowing what the problem (error) is with the underlying socket, you are on a hiding to nothing. The fact it is rare and affects other software points to a hardware or OS issue, not your code (except that your code doesn't report an error). That doesn't mean to say other software or the OS isn't responsible for crowbarring the socket underneath you but you need errors to figure out what is happening and what the state of the socket is when it fails. Another technical detail. The LabVIEW Listener uses SO_EXCLUSIVEADDRUSE and assumes it has sole ownership of the socket. It then uses the "Internecine Avoider" to choose ports. If no net address is defined it binds to all network adapters. Does the device have multiple network interfaces? What is the OS?

What's the error?

I'll preface this with "I have never used that software" and I don't know of any standard fixes. I would be putting on my Sherlock Holmes hat and taking a big toke on the Meerschaum. Maybe someone else has a standard fix but this is how I would approach it... First I would check that the new server.key and certificate format is the same as the old one (probably PEM but just could easily be DER). It's easily done just by opening in a text editor. Jibberish is DER. PEM is "-----BEGIN CERTIFICATE----" (maybe this software only supports one format). Same for the private key - which would be gibberish or something like "-----BEGIN RSA PRIVATE KEY-----". Then I'd create a self-signed certicate and load that with it's key to see if the software had the same complaint. Then I would be taking a closer look at the new certificate and the old one and see what's different about the new one - paying particular attention to the type of Public Key, the Key Extensions and the signing method. (if there is no TLS Webserver Then I would check that the public key of my private key matches that in the certificate. The above would mainly be to verify that the certificate is indeed for the key I think it is for, and that the private key is the same/similar type to that which was used previously. If they are not the same type then I would generate a self signed certificate with the new type and see if I again get the error. Note that this is before we get to what the CA has done so buckle up or use some other software Here is googles cert and what I'd be looking at on the first pass.

Start here and then Google specifics. Good luck Generally though, you choose a licence and then mark the software as being covered by that licence (about box, licence file, etc) . Commercial offerings a bit harder though since you need to stop people using it if they have not bought a licence. Two ways you can look at it. A single piece of software that the user can choose from multiple licences (hard) or multiple, discrete, pieces of software have their own licence (easy). Non commercial is easy-just distribute a licence with the product. Commercial is harder-you need to cripple the software somehow when distributed and only become fully featured after a licence is purchased. You can either go it alone (web page and download) or via NI who have a couple of options. You would need to contact NI since they recently changed their sales model so I don't know what they are offering now, Depends on the licence-there are many. Not that I'm aware of. VIPM is an installer and distribution platform. If it's a commercial product then you will also need to look into the Third Party Licensing and Activation toolkit If you want a completely managed sales solution then speak with NI.

In PEM format?

Hang on. That error seems to be saying it requires the private key. The certificate from the CA is a signed version of that private key's public key. Is that "server_0.key" the private key that you used to generate the Certificate Signing Request (CSR) for the CA?

Yes. But was it in the same location? "National Instruments" has a space in it. Try it in a short path without any spaces like c:\tmp. Try the simple stuff first.

It's not something silly like it can't handle spaces in the path, is it?

Well. LabVIEW 2022 is shipped with OpenSSL 1.0.2u 20 Dec 2019 so don't get your hopes up. That said; if it's an RSA or EC certificate you should be fine. I would be looking at other issues especially as there was no Alert complaining about the certificate or ciphers.

Is there no "Alert" before the RST?

All of the synchronisation primitives use occurrences under the hood. Occurrences are the most efficient but hardest to use since they don't carry any data. On a side note (and people will hate/flame/badger me for this). If you have a write one and read many architecture then the most efficient for task switching is a global variable (but memory suffers).

It's been a very long time since I did any real-time stuff but If I'm reading your charts right... The Linux nisysapi-mDNS is a bottleneck? Is that due to your code looking up addresses or an artifact of the system in general? I also noticed the variable publisher in your first image. Are you using network variables?

The hardest to figure out will be booleans which in JSON can be true, false or NULL. While you can get away with converting null to NAN for output to LabVIEW, be aware that NAN is specifically excluded for encoding as a numeric. RFC4627 section 2.4

Kawaii?