Read\Write Connection ID VIs have private scope

[salomaogh]

Hello,

I am trying to connect with Azure IOT Central through a SAS Token Authentication (generated by other means) and have managed to do it with this library (https://github.com/mradziwo/mqtt-LabVIEW) following the steps of Mr. Pate in this forum topic (https://lavag.org/topic/21615-azure-iot-mqtt/). However, when i try to establish the TLS communication with IOT Central without the need of a certificate file with the Labview Open Source MQTT library, Labview presents the message: "This VI cannot access the referenced item in protected scope". It is possible to add this feature or unlock the VIs? Here is a screenshot of a Subscriber example.

[francois-normandin]

Hi @salomaogh ,

Those methods are protected because accessing them can change the state of the connection object instance. It will never be exposed directly to prevent leaky abstractions that change the behaviour of the class.

To do what you want, you would extend the TCP connection class and implement the overrides to offer TLS support.

Fortunately, this had been done already. 😀

https://github.com/LabVIEW-Open-Source/MQTT-Connection-SecuredTCP

https://www.vipm.io/package/labview_open_source_project_lib_mqtt_securedtcp_connection/

Check out the SecuredTCP package on VIPM and you should find examples in the palette on how to use the extended methods to register your certificates or use the password field to transmit the token.

This video might help too:
https://youtu.be/2-OJ-U6eTmE

P.S. the reason it is not supported in the base package is because it supports LV2013. The TLS nodes were added in LV2020, so the secured extension is also >=LV2020.

[salomaogh]

Hello Mr. Normandin,

Thank you for the prompt response: I have watched your insightfull video multiple times in depth. Unfortunately i do not have any additional information about Hostname and Server X.509 certificate to pass into the "Configure Secured TCP Client" VI, because i use the SAS Authentification method to generate the password and the DPS Assigned Hub for me. All information i have is about DPS hostname, port 8883, username, password and Client ID (picture below).

When i use MQTT Explorer to connect with IOT Central, i also do not need any certificate. I just check the "encryption" option and that's it.

Mr. Pate did not need to add any certificate here too, when he modified the VI:

Cheers,

[francois-normandin]

Hostname is related to certificate. When you use SAS, you are not supposed to need it.
I've always used X.509 certs for connections, so I propose you probe what's going on in this VI and see if there's not an exception we need to handle when no certificates are passed in...

[salomaogh]

Thank you Mr Normandin. I will check it out.

Cheers.

[salomaogh]

Hello Mr. Normandin,

I've tested your proposition. No error occurs but the "Ready for SSL" boolean flag returns False. Therefore, the flag leads to the "False" condition inside the "OnConnection" VI. After that, when i try to connect with IOT Central, i get Error 66 (Server Disconnected)
with return Code (Connection Accepted). Below screenshots of my test.

"Configure Secured TCP Client VI":

"OnConnection" VI:

Connection error:

Is there any way to set circumvent this problem?

Cheers.

[salomaogh]

Hello Mr. Normandin,

I had to made some changes on the "onConnection" VI to make sure that the connection with IOT Central worked.

I have added an optional control flag "CA Signed Server Certificate?" to circumvent the first statement condition, wired the flag to the "load OS trusted CAs?" parameter in the new "TLS Configuration" VI and then added a condition to check if the certificates paths are valid. However the newly created flag could not be set as a control terminal, due to class error. It seems like other VI must have this flag, even if this does not make sense.

I am not sure if this is a reasonable solution, though. I am no expert in the subject. Do you have any thoughts or ideas? Here is the result:

Cheers,