fieldrndservices / libssh2-labview

A LabVIEW library for SSH client support via libssh2
Apache License 2.0
21 stars 2 forks source link

SSH Library usage with NI Xnet #63

Closed Sarithlal closed 7 months ago

Sarithlal commented 8 months ago

Hello Folks

I have a question regarding the usage of this library with IP stack created using NI Xnet. I hhave done telnet over xnet by replacing the tcp reference from NI DAQmx driver to Xnet driver and it worked. Similarly, can I change the IP stack and reuse this code?

Sarithlal commented 8 months ago

image

Sarithlal commented 8 months ago

To do that this vi is actually password protected and not sure what exactly needed here

volks73 commented 8 months ago

The TCP Get Raw Net Object.vi is provided by NI with the LabVIEW development environment and run-time engine. The VI is a low-level LabVIEW-specific internal implementation and password protected by NI. Unless you have a confidentiality agreement with NI or some other code sharing policy with NI, the contents of the block diagram for that specific VI will not be available.

That VI returns the handle to the TCP connection created with the preceding function of creating a TCP connection with a remote computer. The handle is actually the memory address for the TCP connection from the Operating System (OS). This handle is passed to the underlying libssh2 library with the Call Library Function node. This sequence of VIs is essentially the same as creating a socket in C. See the ssh2.c example from the libssh2 project. There is the sock = socket(AF_INET, SOCK_STREAM, 0); line. Typically, creating a socket is an OS specific operation.

I am not familiar with XNET, but is it socket-based? If yes, then it should be possible to create an XNET socket and pass the handle of it to the Call Library Function node instead. From the ssh2.c example, there is the comment:

/* Ultra basic "connect to port 22 on localhost".  Your code is
     * responsible for creating the socket establishing the connection
     */ 

So, as long as a handle to a socket can be obtained for XNET, then it should be possible to SSH over XNET. Do you have an example code for the Telnet implementation?

I know newer versions of LabVIEW, 2022+ I think, (finally) have native SSH/SCP support. Maybe there is already SSH over XNET in newer versions of LabVIEW?

Sarithlal commented 8 months ago

Thank yo very much for your quick and detailed explanation. Here are the snippets for telnet implementation over xnet image

Here are some more insights into my understanding and some questions about the toolkit image

Here is my modifications to the 'session connect' where handle has to be initiated based on the TCP socket from xnet . Please help me to extract the needed dll input from the xnet socket

image

Here is the disconnect update based on Xnet

image

For better clarity, I have exeuted a simple tcp connection over xnet to give you the reference I am getting from TCP socket . Please find the below screenshot, which contains the socket number during the TCP connection. This number is enough for the dll to process the data? I am fraid of the dll capability to access the TCP stack in xnet with this refernce number. Do you think its possible?

image

Incase i probe the normal tcp implementation, I could see the reference number and a number generated by the password protected vi as below. Need to know how can I extract this number from xnet reference number , incase the answer to above question is yes.

image

Sarithlal commented 8 months ago

Some insights about ethernet over xnet https://www.ni.com/docs/de-DE/bundle/ni-xnet/page/nixnet/xnetipstack.html

These are the supported protocol by xnet https://www.ni.com/docs/de-DE/bundle/ni-xnet/page/nixnet/sysconfighardwarexnetintfprotocol.html

Supported ethernet features https://www.ni.com/docs/de-DE/bundle/ni-xnet/page/nixnet/xnetsocketsupportedfeatures.html

volks73 commented 8 months ago

what exactly is neede here?

This is the memory address to the TCP socket from the Operating System (OS). This is called the "handle" as it is a "handle" to the structure saved in memory created by the OS when the TCP connection was created, a.k.a. the socket.

is this dll a generic one which process that packet from the provided handle? or there is any dependency to OS stack or something?

A Dynamic Link Library (DLL) is a dynamic or shared library, and a DLL is Windows specific. On Linux, a dynamic library is called a Shared Object (SO) and on macOS this is called a DyLIB. The DLL/SO/DyLib used here is the libssh2lv library. The libssh2lv code is written in C, the same language as the libssh2 library. The libssh2 library provides C ABI (Application Binary Interface). LabVIEW can interface with a library that provides a C ABI through the Call Library Function Node, but LabVIEW has some quirks and requirements to successfully interface with a DLL. Thus, the libssh2lv library "wraps" the libssh2 library and provides a LabVIEW-friendly C ABI.

The dependencies are the same dependencies for libssh2, which is essentially OpenSSL.

The handle to the TCP socket is passed to the libssh2lv wrapper library, which is passed to the libssh2 library. The libssh2 library processes the packets and SSH communication. The libssh2 holds onto the TCP handle and reads/writes to it as needed to maintain the SSH protocol.

This is incompatible to connect. So From the xnet TCP socket what data need to be extracted and connected to the dll?

No surprised as the TCP Interface wire (thin, teal color) is a different type from the Refnum provided by the NI-XNET VI. The TCP Interface wire is actually a socket and OS specific. I believe the NI-XNET Refnum is some C# .NET object. A very brief review of the documentation you provided and general searching on NI-XNET indicates the NI-XNET library is implemented in C# .NET. LabVIEW is capable of interfacing with C# .NET objects similar to DLLs on Windows. Thus, the structure in memory for the TCP Interface and the NI-XNET Refnum are different and incompatible. The TCP Interface wire is closer to a File wire (also thin, teal color) than a Refnum.

The handle is memory address. If you think about the memory of your computer as one giant continuous block of bytes, then each byte has an address starting with 1. The handle is the memory address of the TCP address socket. The libssh2 library will look at that memory address and grab the TCP socket information it needs. This is sometimes referred to as "pass by reference", even if it is not strictly pass by reference. If this memory address (reference) is even off by one byte, nothing will work and you may crash your computer (segmentation fault) or (worse) leak information (buffer overflow/underflow).

More information about Refnums available at What is the Structure in Memory of a Reference Number (Refnum) Used by LabVIEW

I did some digging around the NI-XNET library, and I do not see any way to extract the connection ID of the TCP socket from the Refnum. Casting is not going to work. This will lead to all kinds of problems.

All this said, my general rule is that if it is hard to do in LabVIEW, then there are very good reasons not to do it. SSH over NI-XNET appears to be hard and/or not possible with this toolkit. You may want to investigate other LabVIEW Tools for SSH and SFTP. I believe the LABSSH toolkit is a C# .NET implemented library, so it might interface directly with NI-XNET.

Sarithlal commented 8 months ago

That also doesn't support . Any other solution to it? We can place order for the implementation

Sarithlal commented 8 months ago

Hello

I am trying to use the library , could you help me to create a code that can execute a command in a remote machine after authentication?

[image: image.png] This I have created t authenticate.. I need to send a command "psddr" after the login. How can I implement that using this library?

Freundliche Grüße / Best regards / Cordialement,

Sarithlal MK Test Development Engineer Valeo expert CDA - Site Wemding

Tel:+4990926032863 Valeo Schalter und Sensoren GmbH Valeostrasse 1 86650 Wemding - Germany

[image: valeo] https://valeo.com/ [image: linkedin] https://linkedin.com/company/valeo [image: twitter] https://twitter.com/valeo_group [image: youtube] https://youtube.com/user/ValeoGroup [image: facebook] https://facebook.com/Valeo.Group/ [image: instagram] https://instagram.com/valeo_group

Sitz der Gesellschaft: 74321 Bietigheim-Bissingen Handelsregister: Amtsgericht Stuttgart - HRB 301795 Vorsitzender des Aufsichtsrates: Derrick Zechmair Geschäftsführer: Stiv Michael Smudja, Martin Mandry, Pierre-Yves Veltois

On Fri, Oct 27, 2023 at 4:06 PM Christopher Field @.***> wrote:

what exactly is neede here?

This is the memory address to the TCP socket from the Operating System (OS). This is called the "handle" as it is a "handle" to the structure saved in memory created by the OS when the TCP connection was created, a.k.a. the socket.

is this dll a generic one which process that packet from the provided handle? or there is any dependency to OS stack or something?

A Dynamic Link Library (DLL) is a dynamic or shared library, and a DLL is Windows specific. On Linux, a dynamic library is called a Shared Object (SO) and on macOS this is called a DyLIB. The DLL/SO/DyLib used here is the libssh2lv https://github.com/fieldrndservices/libssh2lv library. The libssh2lv code is written in C, the same language as the libssh2 https://libssh2.org/ library. The libssh2 library provides C ABI (Application Binary Interface). LabVIEW can interface with a library that provides a C ABI through the Call Library Function Node https://knowledge.ni.com/KnowledgeArticleDetails?id=kA03q000000YGZjCAO&l=en-US, but LabVIEW has some quirks and requirements to successfully interface with a DLL. Thus, the libssh2lv library "wraps" the libssh2 library and provides a LabVIEW-friendly C ABI.

The dependencies are the same dependencies for libssh2 https://github.com/libssh2/libssh2/blob/master/docs/INSTALL_CMAKE.md_, which is essentially OpenSSL.

The handle to the TCP socket is passed to the libssh2lv wrapper library, which is passed to the libssh2 library. The libssh2 library processes the packets and SSH communication. The libssh2 holds onto the TCP handle and reads/writes to it as needed to maintain the SSH protocol.

This is incompatible to connect. So From the xnet TCP socket what data need to be extracted and connected to the dll?

No surprised as the TCP Interface wire (thin, teal color) is a different type from the Refnum provided by the NI-XNET VI. The TCP Interface wire is actually a socket and OS specific. I believe the NI-XNET Refnum is some C# .NET object. A very brief review of the documentation you provided and general searching on NI-XNET indicates the NI-XNET library is implemented in C# .NET. LabVIEW is capable of interfacing with C# .NET objects similar to DLLs on Windows. Thus, the structure in memory for the TCP Interface and the NI-XNET Refnum are different and incompatible. The TCP Interface wire is closer to a File wire (also thin, teal color) than a Refnum.

The handle is memory address. If you think about the memory of your computer as one giant continuous block of bytes, then each byte has an address starting with 1. The handle is the memory address of the TCP address socket. The libssh2 library will look at that memory address and grab the TCP socket information it needs. This is sometimes referred to as "pass by reference", even if it is not strictly pass by reference. If this memory address (reference) is even off by one byte, nothing will work and you may crash your computer (segmentation fault) or (worse) leak information (buffer overflow/underflow).

More information about Refnums available at What is the Structure in Memory of a Reference Number (Refnum) Used by LabVIEW https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019ZT5SAM&l=en-US

I did some digging around the NI-XNET library, and I do not see any way to extract the connection ID of the TCP socket from the Refnum. Casting is not going to work. This will lead to all kinds of problems.

All this said, my general rule is that if it is hard to do in LabVIEW, then there are very good reasons not to do it. SSH over NI-XNET appears to be hard and/or not possible with this toolkit. You may want to investigate other LabVIEW Tools for SSH and SFTP https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000015AwOSAU&l=en-US. I believe the LABSSH https://labwerx.net/ toolkit is a C# .NET implemented library, so it might interface directly with NI-XNET.

— Reply to this email directly, view it on GitHub https://github.com/fieldrndservices/libssh2-labview/issues/63#issuecomment-1782978762, or unsubscribe https://github.com/notifications/unsubscribe-auth/AYQLBIDEVYVEYNN27M7YLXLYBO5XTAVCNFSM6AAAAAA6RKUDLWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBSHE3TQNZWGI . You are receiving this because you authored the thread.Message ID: @.***>

-- *This e-mail message is intended for the internal use of the intended recipient(s) only. The information contained herein is confidential/privileged. Its disclosure or reproduction is strictly prohibited. If you are not the intended recipient, please inform the sender immediately, do not disclose it internally or to third parties and destroy it.

In the course of our business relationship and for business purposes only, Valeo may need to process some of your personal data. For more information, please refer to the Valeo Data Protection Statement and Privacy notice available on Valeo.com https://www.valeo.com/en/ethics-and-compliance/#principes*

Sarithlal commented 8 months ago

image

volks73 commented 8 months ago

Hello, please have a look at the Single Command Execution example. This example is also available in the Example Finder within the Help menu of the LabVIEW development environment.

Single_Command_Execution

Sarithlal commented 8 months ago

Thank you very much for your quick response. I have used that example vi. Unfortunately the response is empty while executing using thi toolkit. When I use another toolkit it gives response. Until authentication it worked. Anyidea?

Freundliche Grüße / Best regards / Cordialement,

Sarithlal MK Test Development Engineer Valeo expert CDA - Site Wemding

Tel:+4990926032863 Valeo Schalter und Sensoren GmbH Valeostrasse 1 86650 Wemding - Germany

[image: valeo] https://valeo.com/ [image: linkedin] https://linkedin.com/company/valeo [image: twitter] https://twitter.com/valeo_group [image: youtube] https://youtube.com/user/ValeoGroup [image: facebook] https://facebook.com/Valeo.Group/ [image: instagram] https://instagram.com/valeo_group

Sitz der Gesellschaft: 74321 Bietigheim-Bissingen Handelsregister: Amtsgericht Stuttgart - HRB 301795 Vorsitzender des Aufsichtsrates: Derrick Zechmair Geschäftsführer: Stiv Michael Smudja, Martin Mandry, Pierre-Yves Veltois

On Thu, Nov 9, 2023 at 2:45 PM Christopher Field @.***> wrote:

Hello, please have a look at the Single Command Execution https://github.com/fieldrndservices/libssh2-labview/blob/main/src/Examples/Single%20Command%20Execution.vi example. This example is also available in the Example Finder within the Help menu of the LabVIEW development environment.

[image: Single_Command_Execution] https://user-images.githubusercontent.com/1915469/281750682-51da859b-1b53-468b-bbc7-06fde31995f6.png

— Reply to this email directly, view it on GitHub https://github.com/fieldrndservices/libssh2-labview/issues/63#issuecomment-1803861137, or unsubscribe https://github.com/notifications/unsubscribe-auth/AYQLBIBS7SQFVT5ZSK6TJULYDTNBPAVCNFSM6AAAAAA6RKUDLWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBTHA3DCMJTG4 . You are receiving this because you authored the thread.Message ID: @.***>

-- *This e-mail message is intended for the internal use of the intended recipient(s) only. The information contained herein is confidential/privileged. Its disclosure or reproduction is strictly prohibited. If you are not the intended recipient, please inform the sender immediately, do not disclose it internally or to third parties and destroy it.

In the course of our business relationship and for business purposes only, Valeo may need to process some of your personal data. For more information, please refer to the Valeo Data Protection Statement and Privacy notice available on Valeo.com https://www.valeo.com/en/ethics-and-compliance/#principes*

Sarithlal commented 8 months ago

the reason I stick to this toolkit was its open source, also the IP stack created with a proxy server only works with the TCP driver from Labview. Other toolkits used other programming to imlement it. so its not woking woth the proxy approach

volks73 commented 8 months ago

You want to take a look at the following issues and discussions as other users of this toolkit have experienced a similar issue:

  1. 48

  2. 45

  3. 31

  4. 30

  5. 28

Most of the time a lack of response with this toolkit is a result of the toolkit being relatively low level and not a full featured shell or the output from the command you are attempting to use is on STDERR and not STDOUT.

Is it only a specific command that is not returning a response, or is it all commands?

Sarithlal commented 8 months ago

Thank you for your continued support.

Today I have tried 2 commands and both failed to get response. In wireshark, I could see the traces of transactions but couldn't decrypt and understand it. Tomorrow I will try to follow the issues you had mentioned above.

Could you help me yo understand about changing stdout to stderr?

Thank you

On Thu, 9 Nov 2023, 16:46 Christopher Field, @.***> wrote:

You want to take a look at the following issues and discussions as other users of this toolkit have experienced a similar issue:

  1. 48 https://github.com/fieldrndservices/libssh2-labview/issues/48

  2. 45 https://github.com/fieldrndservices/libssh2-labview/issues/45

  3. 31 https://github.com/fieldrndservices/libssh2-labview/issues/31

  4. 30 https://github.com/fieldrndservices/libssh2-labview/issues/30

  5. 28 https://github.com/fieldrndservices/libssh2-labview/issues/28

Most of the time a lack of response with this toolkit is a result of the toolkit being relatively low level and not a full featured shell or the output from the command you are attempting to use is on STDERR and not STDOUT.

Is it only a specific command that is not returning a response, or is it all commands?

— Reply to this email directly, view it on GitHub https://github.com/fieldrndservices/libssh2-labview/issues/63#issuecomment-1804080127, or unsubscribe https://github.com/notifications/unsubscribe-auth/AYQLBIEFNCSAG3HQPFYZFU3YDT3EHAVCNFSM6AAAAAA6RKUDLWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBUGA4DAMJSG4 . You are receiving this because you authored the thread.Message ID: @.***>

-- *This e-mail message is intended for the internal use of the intended recipient(s) only. The information contained herein is confidential/privileged. Its disclosure or reproduction is strictly prohibited. If you are not the intended recipient, please inform the sender immediately, do not disclose it internally or to third parties and destroy it.

In the course of our business relationship and for business purposes only, Valeo may need to process some of your personal data. For more information, please refer to the Valeo Data Protection Statement and Privacy notice available on Valeo.com https://www.valeo.com/en/ethics-and-compliance/#principes*

Sarithlal commented 8 months ago

image

Sarithlal commented 8 months ago

i have changed the vi to stderr read and got this message

Sarithlal commented 8 months ago

image after executing the same command form alaab ssh library got this response

Sarithlal commented 8 months ago

i jave tried other vi read all - that seems hanging and didnt finish execution. this behaviour is there forall commands I got the same error message , but from the other tool , afterthe error message I have the response as in the above screenshot. Any clue?

volks73 commented 8 months ago

This is a configuration on your remote Linux system. Many Linux system do not have a home directory for the root user. When you SSH as root, the default present working directory (pwd) is /home/<user>, which would be /home/root, but the root user on the remote machine does not have a home directory. This is typically done for security reasons as no one should actually be using a root superuser account as a terminal user. The root user is generally reserved for just brief, temporary usage where elevated privileges, i.e., on some Linux distributions this is sudo. This is something that is configured/managed by the remote Linux system, not specific to this toolkit.

Can you use a different user than root? This is probably a good idea anyways.

Many SSH clients will automatically cd $HOME or similar command. What does echo $HOME show using a more full featured shell?

Possibly some useful references:

  1. https://askubuntu.com/questions/1000220/ssh-without-a-home-directory
  2. https://superuser.com/questions/1610105/suppress-home-directory-check-while-sshing-to-remote-host-for-user-without-home
Sarithlal commented 8 months ago

Hello

Thank you for your response. As you mentioned, we are just in the development phase and do have only user 'root'. As in my previous message you can see the same command is working with other toolkit. That makes me confused.

Regards

On Fri, 10 Nov 2023, 17:05 Christopher Field, @.***> wrote:

This is a configuration on your remote Linux system. Many Linux system do not have a home directory for the root user. When you SSH as root, the default present working directory (pwd) is /home/, which would be /home/root, but the root user on the remote machine does not have a home directory. This is typically done for security reasons as no one should actually be using a root superuser account as a terminal user. The root user is generally reserved for just brief, temporary usage where elevated privileges, i.e., on some Linux distributions this is sudo. This is something that is configured/managed by the remote Linux system, not specific to this toolkit.

Can you use a different user than root? This is probably a good idea anyways.

Many SSH clients will automatically cd $HOME or similar command. What does echo $HOME show using a more full featured shell?

Possibly some useful references:

  1. https://askubuntu.com/questions/1000220/ssh-without-a-home-directory
  2. https://superuser.com/questions/1610105/suppress-home-directory-check-while-sshing-to-remote-host-for-user-without-home

— Reply to this email directly, view it on GitHub https://github.com/fieldrndservices/libssh2-labview/issues/63#issuecomment-1806008729, or unsubscribe https://github.com/notifications/unsubscribe-auth/AYQLBIHJNDLMJNXKZ7PPNTLYDZGDFAVCNFSM6AAAAAA6RKUDLWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBWGAYDQNZSHE . You are receiving this because you authored the thread.Message ID: @.***>

-- *This e-mail message is intended for the internal use of the intended recipient(s) only. The information contained herein is confidential/privileged. Its disclosure or reproduction is strictly prohibited. If you are not the intended recipient, please inform the sender immediately, do not disclose it internally or to third parties and destroy it.

In the course of our business relationship and for business purposes only, Valeo may need to process some of your personal data. For more information, please refer to the Valeo Data Protection Statement and Privacy notice available on Valeo.com https://www.valeo.com/en/ethics-and-compliance/#principes*

volks73 commented 8 months ago

Does the Read-Execute-Print-Loop with a Raspberry Pi.vi example work with your command and remote SSH server? This example works with any remote SSH server, I just got a lot of questions in the past about connecting to a Raspberry Pi.

Sarithlal commented 7 months ago

Thank you .. that worked well.. it's an awesome example. I am so glad with your timely support.

On Fri, 10 Nov 2023, 23:14 Christopher Field, @.***> wrote:

Does the [Read-Execute-Print-Loop with a Raspberry Pi](Read-Execute-Print-Loop with a Raspberry Pi.vi https://github.com/fieldrndservices/libssh2-labview/blob/main/src/Examples/Read-Execute-Print-Loop%20with%20a%20Raspberry%20Pi.vi) example work with your command and remote SSH server? This example works with any remote SSH server, I just get a lot of questions in the past about connecting to a Raspberry Pi.

— Reply to this email directly, view it on GitHub https://github.com/fieldrndservices/libssh2-labview/issues/63#issuecomment-1806507506, or unsubscribe https://github.com/notifications/unsubscribe-auth/AYQLBIC2AENXO7DRU4A4LULYD2RMHAVCNFSM6AAAAAA6RKUDLWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBWGUYDONJQGY . You are receiving this because you were assigned.Message ID: @.***>

-- *This e-mail message is intended for the internal use of the intended recipient(s) only. The information contained herein is confidential/privileged. Its disclosure or reproduction is strictly prohibited. If you are not the intended recipient, please inform the sender immediately, do not disclose it internally or to third parties and destroy it.

In the course of our business relationship and for business purposes only, Valeo may need to process some of your personal data. For more information, please refer to the Valeo Data Protection Statement and Privacy notice available on Valeo.com https://www.valeo.com/en/ethics-and-compliance/#principes*

volks73 commented 7 months ago

I am glad to hear the example worked for your use case. Can I close this issue?

Sarithlal commented 7 months ago

Yes please. If something pops up, will write you here.

Thanks again for your help

On Mon, 13 Nov 2023, 15:56 Christopher Field, @.***> wrote:

I am glad to hear the example worked for your use case. Can I close this issue?

— Reply to this email directly, view it on GitHub https://github.com/fieldrndservices/libssh2-labview/issues/63#issuecomment-1808318955, or unsubscribe https://github.com/notifications/unsubscribe-auth/AYQLBIHT246LDTE76UQ7METYEIYIRAVCNFSM6AAAAAA6RKUDLWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBYGMYTQOJVGU . You are receiving this because you were assigned.Message ID: @.***>

-- *This e-mail message is intended for the internal use of the intended recipient(s) only. The information contained herein is confidential/privileged. Its disclosure or reproduction is strictly prohibited. If you are not the intended recipient, please inform the sender immediately, do not disclose it internally or to third parties and destroy it.

In the course of our business relationship and for business purposes only, Valeo may need to process some of your personal data. For more information, please refer to the Valeo Data Protection Statement and Privacy notice available on Valeo.com https://www.valeo.com/en/ethics-and-compliance/#principes*