volks73
commented
3 years ago The Create from SCP Receive.vi is a "wrapper" around the lv_libssh2_scp_receive function from the libssh2lv project. When I look at the source code for the lv_libssh2_scp_receive function, it is a "thin wrapper" around the libssh2_scp_recv2 function and there are lines 91 to 95:
LIBSSH2_CHANNEL* inner = libssh2_scp_recv2(session->inner, path, file_info->inner);
if (inner == NULL) {
return LV_LIBSSH2_STATUS_ERROR_MALLOC;
}However, according to the documentation for the libssh2_scp_recv2 function:
Pointer to a newly allocated LIBSSH2_CHANNEL instance, or NULL on errors.
and there are three possible errors: LIBSSH2_ERROR_ALLOC, LIBSSH2_ERROR_SCP_PROTOCOL, and LIBSSH2_ERROR_EAGAIN.
The above C wrapper code in the lv_libssh2_scp_receive function is "masking" all errors from the libssh2_scp_recv2 function on a NULL value as a memory allocation error, when it could be a memory allocation error, a SCP Protocol error from the server, and a warning for non-blocking IO but the call would block (The LIBSSH2_ERROR_EAGAIN is not actually an error, it is used with non-blocking IO). This is a bug in the error handling within the libssh2lv C code. If the libssh2_scp_recv2 function returns NULL, then the error code should be checked and the appropriate error should be returned.
I will add an issue to the libssh2lv project to update the error handling. However, this is not the cause of your (@ngblume) issue but a complicating factor which is indicating a memory allocation error but really it is most likely a SCP Protocol error based on your description of conditions when running with two other servers. Unfortunately, the HTML documentation for the libssh2_scp_recv2() function for the LIBSSH2_ERROR_SCP_PROTOCOL error is empty and does provide any details on what could cause this error.
If it is in fact a LIBSSH2_ERROR_SCP_PROTOCOL error, then this is most likely something with the servers and not the client. I have had problems with newer SSH servers, but I believe that was related to supported cryptography algorithms, not with SCP protocol. The SCP protocol has been around for a long time and it does not change often or frequently.
It is also possible that the error is a LIBSSH2_ERROR_EAGAIN warning/error. Are you using non-blocking IO (Write Mode VI in the Channel API)?
Some additional debugging:
- Are you able to use the
scpcommand from the command line, external to LabVIEW and this package? - You mentioned a Raspberry Pi. Can you try the Read-Execute-Print-Loop with a Raspberry Pi example?
- Can you try the Read-Execute-Print-Loop with a Raspberry Pi example but connect to the two other servers? It should work, there is nothing really special about the LabVIEW code that makes it only work with a Raspberry Pi. I just get a lot of requests to interface with a Raspberry Pi via SSH with LabVIEW using this package.
- What type (OpenSSH?) and version of SSH server is running on the 2 problematic servers? Is this the same as the Raspberry Pi? If not, then there is something different between the SSH servers that is causing the SCP protocol error.
- Can you install or use the server and version on the Raspberry Pi on the other servers?
- Can you try the
scp -vvvcommand from the command line with the three different servers and observe the output? The output might indicate where the three servers (Raspberry Pi and the other two) might differ.
ngblume
When using the "Create from SCP Receive.vi" (for example within the SCP Download example), I get a "Memory Allocation Error" (-8102) at the Call Library Node (Function: lv_libssh2_scp_receive). The problem is that this occurs only with some servers, not all and not at all times. Working locally with an RPi works 100% of the time without problems. Working with 2 other servers, I get this error 8 out of 10 times (roughly).
Thanks !
Cheers Niels