Connection lost and following attempt to read/write causes labview crash about libssh2lv HOT 3 CLOSED

@Volinger What happens if you are connected to the Linux-based device via PuTTY (assuming the host computer is a Windows machine) and the Linux-based device goes off? Does PuTTY immediately disconnect? I have had similar behavior with the connection to appear to still be on but in fact it is disconnected with PuTTY and other SSH clients over the years. I believe this is related to timeouts and keep alive configurations. Maybe the discussion in fieldrndservices/libssh2-labview#44 could be of use as the it sounds related.

The LabVIEW crashing via the DLL is possible. My guess is that the TCP read or write buffers (low level) have filled up and a buffer overflow has occurred causing the C code (DLL) to segmentation fault, which can cause the Call Library Node function LabVIEW crash. If the connection is "kept alive" on the host side for a long time and acts like the connection still exists, the bytes will be continuously written to the TCP connection. Interestingly, I don't think there is anything that can be done in the C code to prevent the overflow because it is just using the Windows API. This would be extremely low-level and/or in the libssh2 library.

from libssh2lv.

@volks73 thanks for the suggestions, I will try the thread you sent for the keep alive, maybe some configuration adjustment would be enough.

For the second part - overflow also makes sense theoretically, because what I am doing with the device is running some test which generates lot of data. Although the data is generated on the side of device. I am not very well versed in technical details of SSH, but based on what you described, might this mean that although SSH got disconnected, underlying TCP was alive and it still received data from device, which caused overflow?

This also brings me to another point. As I mentioned, the test generates a lot of data and acts as sort of simulated CPU load for the device. When I was running this test with putty terminal - it gave me the data back without issues and I was even able to close the terminal and test continued (I was able to verify this by checking the CPU load on the device). When using libssh2lv API however, the test gets paused after few seconds and I need to perform read of the data in order for it to continue. May this be that TCP buffer gets full all the time so what I was doing was just clearing it?

from libssh2lv.

...might this mean that although SSH got disconnected, underlying TCP was alive and it still received data from device, which caused overflow?

From my understanding, SSH uses TCP. If SSH is disconnected, then TCP is disconnected. In this context, it is probably best to just equate SSH with TCP. Depending on the Operating System (OS) implementation for the TCP stack and given TCP is bidirectional, there is a read and write buffer. This is usually around 65536 (2^16) bytes. It is possible for an application continue to read and write to the TCP buffers when the TCP connection is broken because the reads and the writes are just to the buffers, not actually sent. It is usually up to the OS/driver/firmware layer to handle sending and receiving the data in the read/write buffers. The application (LabVIEW, this DLL, etc.) are only exposed to the read/write buffers. Thus, there may be some latency between a disconnect and actual error out on a disconnect.

That said, the libssh2 library, which is another layer below this toolkit but a layer above the TCP stack, has internal read and write buffers as well because the TCP read/write buffers tend to be relatively small and I believe the libssh2 library does some "chunking" of large packets to optimize bandwidth and communication. The overflow is probably coming from one of these buffers in the libssh2 library. I believe the size of these buffers are hard-coded in the libssh2 library, or are at least a compile-time constant. In other words, you would have to recompile the libssh2 library and this toolkit with some new value. There is no API function to change the buffer size because these buffers are statically allocated at the initialization of the libssh2 library. I looked into this a while ago for another project. This may no longer be the case, I could be mis-remembering, or just wrong.

Changing the buffer size will actually not prevent the overflow. Your best course of action is to experiment with the keep-alive, timeout, and TCP settings to ensure the disconnect event happens before the buffers fill up.

When using libssh2lv API however, the test gets paused after few seconds and I need to perform read of the data in order for it to continue. May this be that TCP buffer gets full all the time so what I was doing was just clearing it?

You may want to enable non-blocking mode. It sounds like the toolkit is waiting for data to be available on the channel. You probably want to enable non-blocking mode and every 100 ms or so check if data is available. If available, then perform a read. The Read-Execute-Print-Loop with a Raspberry Pi.vi example from the LabVIEW toolkit shows how to use non-blocking mode. Even if your Linux device is not a Raspberry Pi, the example and implementation is still using. It is for any Linux device.

from libssh2lv.