Jump to content

ShaunR

Members
  • Content Count

    4,113
  • Joined

  • Days Won

    216

Everything posted by ShaunR

  1. That [attitude] is somewhat problematic for me in that the toolkit isn't just used for connecting safely to servers but often used in laboratories for testing device vulnerabilities and compliance. Limiting the protocols and features because "it's not good practice" or "we don't think XYZ" isn't a good fit for me and this extends outside of just TLS (for example hashes) as the toolkit is also capable of generating certificates, signing/verification and the low-level stuff like raw Diffie Hellman calculations. Of course, I'm limited by the OpenSSL implementation but limiting further based on precieved wisdom isn't what I need.
  2. I don't have a linux machine handy, right now, but try unchecking the "Convert EOL".
  3. Although it may be easier from the User end, it's still fundamentally a port of OpenSSL but without FIPS support. LibreSSL doesn't support TLS1.3, currently, and according to their Git it's sitting at OpenSSL 1.0.1 so it will be a while before it has TLS1.3.
  4. I was failry well insulated (historically) by the NI libraries, from that, since all the LabVIEW versions share the same binaries. NI wanted the binaries to be backwards compatible so they compiled them with the compatibilty flag (and a couple of their own functions). At the time I ummed and ahhd about using my own binaries and took the easy route-especially because of cross platform support where you had no idea what versions of openSSL where installed in Linux distributions on a day-to-day baisis. Not to mention the ball-ache of actually compiling them. Your preference for an intermediary binary definately has the advantage here by being able to dynamically load function pointers wheras I'm pretty stuck with one function breaks everything. I've just spent 3 days trying to get OpenSSL 1.1.1 to compile. Perl? Really? I thought CMake was bad I always do things the hard way, though, because I don't want any dependencies. If you look at all the Windows tutorials they are mainly for Visual Studio (dependency on the MS Runtime). Try and find one for MingW Add to that that I want the same names for 32 and 64 bit and voila! Configure nightmare. I refuse to use a thunking DLL for a library that size that changes the ABI on a whim. But finally I got a VM set up to build it (after finding out far more than I wanted to about Perl). I'm not touching that VM ever again. It will remain a whole VM just to build one library on one OS. Those that do are being really stingy with them too. Considering the exponential increase in address space you would have thought if you rented/bought a VPS they would give you more than one IPv6 out-of-the-box. Not a chance!
  5. Yes. All it means is that I'm moving focus from the NI binaries to supplying my own. NI have usually been a couple of years behind the latest but my customers are demanding the latest (hence my questions about TLS1.3). Couple that with OpenSSL having recently made some ABI breaking changes between versions means that multi-version LabVIEW support is a little tricky if continuing with the NI binaries. So in LabVIEW 20XX you will have [probably] the long term support version of binaries and with mine you'll have the latest with backward compatibility to LabVIEW 2012.
  6. Yes. I already do all of that for TLS (using the OpenSSL bios rather than the OS. of course) but I used the LabVIEW Open. Connect and Close to keep it cross platform when obtaining the socket. Now I've replaced those with OS sockets so was looking at completeness (of the sub-library) for sockets-I already have things like Linger and TCP_Nodelay and have added open, close, listen. I know I don't really have to worry about cross platform since I've given up on Linux/Mac support in the commercial package but I do still make it all cross platform so that I can use it on them As for your Network library. I would never have written mine if you had released it . Unfortunately you added a death timer so it' was unusable when the time came for me to use SSL (and no source for the binaries which hide some functionality). I did try to encourage you to release (in that thread) it but eventually had to write my own. Knowing what I do now about openSSL, I don't blame you for not releasing it but at the time (and for a long time after including at the time of this post) it left a huge hole in capabilities that NI weren't interested in filling.
  7. Indeed. I thought maybe there might have been some moveblock trickery that could have sufficed. Oh well. I've already replaced the listen, connect and close so might as well add read and write.
  8. Does anyone know how to do the reverse? i.e. turn a socket into a LabVIEW refnum? I want to replace the LabVIEW Connect primitive with one that supports IPv6 but don't really want to replace the read and write.
  9. I would suggest the "/proc/meminfo" because you can read it as if it was a text file with the LabVIEW file functions.
  10. Here you go. Set Icon.vi Use it like this: To get back to the original icon just call it with an empty path.
  11. Show us what you have tried. It doesn't matter if it doesn't work, we will help you to get it to work.
  12. It was a gentle reminder of a question I asked you a couple of months ago So will the distributed LabVIEW OpenSSL binaries be updated to 1.1.x anytime soon? (that's the version minimum to support TLS1.3) Can anyone confirm the version in the Beta? To be honest. I'm surprised you aren't one of "The Powers". You've done your time and given impeccable service.
  13. That was my takeaway too (udp vs tcp). However. I've been working with LoRa recently (they just launched a couple of satellites) so my choices were MQTT or COAP to run on ESP8266 and ESP32s. I'm considering COAP mainly for the discovery aspect (which MQTT doesn't have but you can kind of make your own by having a topic to annouce to). The UDP aspect might come into its own if they enable UDP Multicast over the internet as standard though.
  14. Indeed. It does have some useful features though like congestion control targeted at small packets and discovery. Seems to be more performant too.
  15. Do you have (or have you ever) installed Visual Basic on that machine? That gives the controls and a licence to use them.
  16. Looks like users are expecting it to solve their version control (or lack thereof) problems. I don't think NI should be entertaining that for a package builder.
  17. I saw a document about migrating from mscomctl to windows.forms (which is.NET). It mentioned the iTreeview and installing the VB runtime made available Microsoft Treeview in the Active X dialogue box.However. Trying to select it resulted in a dialogue saying it wasnt licenced. ¯\_(⁰͡ ͜ʖ⁰͡ )_/¯ Looks like you'll have to replace all the ActiveX containers with .NET containers.
  18. mscomctl is part of the Visual Basic run-time. You might try installing that IF iTreeview is actually part of it (are you sure it is?)
  19. It was probably registered as part of a 3rd party installer on the original platform. If you don't have that then you will need to find the activeX DLL (and it's dependencies) on the original machine, copy them over, and manually register it. Then keep your fingers and toes crossed.
  20. We can cope with that. In fact. We can cope with UTF 8 everywhere except the front panels. UTF8 LV80.vi
  21. NIPM is the odd one out. The rest are all zip files (including Github) but NIPM is multi-wrapped GZip and the zlib wwrapper we all use doesn't support it out of the box. I can already install all them (VIPM, GPM, raw zipped archives, Github, Sourceforge etc) except the NI one. But whilst looking at that I investigated SystemLink. That is the way forward, IMO - being able to manage addons, programs and installs from there and push them out if necessary (either from the cloud server or your local server). I'm very impressed with SystemLink and think it's an industry game-changer. About time too I never understood why they went for the JKI one in the first place. I moaned like hell when they first said that the JKI one was to be NIs preferred solution. So I guess they are only about 7 years late.
  22. Aren't all the addon installers (VIPM, GM and the one I was playing with) about to be made reduntant with the NI Installer now it supports addons?
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.