sftp on computers with several active network adapters

[ujagla]

Hello there.

I've got a problem with the sftp access.
There are several network adapters present in my computer. I'm trying to access a sftp server in the net 192.168.1.0 but FFS seems using the network adapter configured for net 192.168.111.0.
I get the following error code: 10065 (WSAConnectByName).
I'm using FFS 7.5 Build: Sep 26 2015.

Could anybody help on this please?

Best regards, Udo

Edit:
All of a sudden it is working, so no further action required.

[spiral123]

I have recieved this same error, with multiple network adapters. In my case it is the OpenVPN adapter which routes traffic to the SSH server through a VPN.

I can access the SSH server via other SFTP clients.

[spiral123]

Update:

When I add another static route in Windows for the VPN subnet, freefilesync stfp function appears to be able to connect to the ssh host. Odd, that I do not need to add the static route for any other sftp client to successfully connect like putty, or winscp, etc.

Update2:

After a few days of testing, seems adding the static route is not a reliable solution. For some reason, it must be added and deleted a few times, until FreeFileSync will use that route to send the VPN traffic.

[kurtmckee]

Hi! I'm working to standardize on FreeFileSync for my company's sync needs and I'm encountering this issue while running FreeFileSync 8.6.

This is the error I receive:

Cannot find the following folders:

sftp://192.168.0.1/mnt/user/ce

If this error is ignored the folders will be considered empty. Missing folders are created automatically when needed.
___________________________________________

Unable to connect to "192.168.0.1".
Error Code 10065: A socket operation was attempted to an unreachable host. (WSAConnectByName)


I have been able to reproduce this error in the following situations:

- By enabling both the wireless interface and the Ethernet interface simultaneously.
- By enabling only the Ethernet interface and setting multiple static IP addresses.

I have been able to mitigate the error by enabling a single network interface with a single static IP address.

And this is the target use case:

- Windows 7 Enterprise 64-bit
- FreeFileSync 32-bit (the 32-bit binary is specifically run)
- One network interface has multiple static IP addresses
- Another network interface is set to DHCP

I am subscribing to this thread, so please let me know if you need additional logs or tests, or if you'd like me to beta test a new version. Thank you for your time and your work on FreeFileeSync!

[mopani]

I can confirm this issue for a network interface with multiple static IP addresses, trying to connect with SFTP to a local network resource.

It appears to only affect SFTP with FFS for local network addresses, not to drive mapping or UNC share locations (\\server\share\dir\). Neither FQDN nor IP addresses using SFTP work on internal IP ranges.

External IP ranges, both IP address and FQDN, (which have to go through the gateway) work fine.

Removing additional static IP addresses resolves the issue. puTTY, web browsers, and other software do not have any problems connecting when multiple static IP addresses are assigned.

Windows 7 Pro x64, FFSx64 v8.9, v8.8, v8.7, v8.6

[Zenju]

I can confirm this issue for a network interface with multiple static IP addresses, trying to connect with SFTP to a local network resource.

This is a documented limitation of WSAConnectByName which FFS is currently using. However it seems this restriction can be lifted by a more general implementation. Can you test with the following version and see if connections to "localhost" work?
http://www.mediafire.com/file/fg7bk7ntq8dz34y/FreeFileSync_8.10_beta_Windows_Setup.exe

[mopani]

Not sure if you mean local network, or the localhost/127.0.0.1 host.

In any case, this version *does* work to connect to a local network resource with multiple static IP addresses. So the fix works. (For clarity: local network is an address that falls within the static ip's netmask.)

I don't have a localhost/127.0.0.1 to test this with if that was important.

[kurtmckee]

Zenju, thank you for posting this beta!

The 8.10 beta resolves the problems I experienced!

- FFS can now connect when a single network adapter has multiple static IP addresses.
- FFS can now connect with multiple network adapters enabled. (In my use case, this means a wireless adapter with DHCP enabled and a wired adapter with multiple IP addresses.)

I noticed some possible bugs in the beta:

It may be that the beta's "Portable" install option is configured to run as a "Local" install.

After installing the portable version and transferring it to a test PC, I got an error message that the install was corrupted and was not running on the same operating system it was installed on. I worked around the issue by using my PC instead of the test PC.

I encountered a mirroring issue that appears to stem from case normalization.

I'm required to mirror a large package of files to a hardware device that runs Linux internally. Previously I simply deleted all of the files on the hardware device and uploaded the new files when the package was updated. It appears that a directory in the file package changed from uppercase to lowercase between releases, so FFS reported that it was unable to delete files in the "MIB" directory over SFTP. "MIB" matches the case of the source directory on my PC but the destination directory on the hardware device was named "mib". The exact error message (with additional path info redacted) was:

Cannot delete file "sftp://192.168.0.1/path/MIB/OLD_FILE.MIB"
LIBSSH2_ERROR_SFTP_PROTOCOL: SFTP Protocol Error LIBSSH2_FX_NO_SUCH_FILE [libssh2_sftp_unlink]


When I re-ran FFS, it re-detected the same files as before but listed them in the "mib" directory and was able to successfully delete the files during the second mirroring process.

I found similar posts elsewhere on the forum and can add replies to those or open a new thread about this issue.

Thank you again for your work on this! This is a very helpful bug fix! Please let me know whether I should open a new thread about the case sensitivity issue or post to an existing thread. Please also let me know if you need additional information, logs, or beta testing! =)

[Zenju]

@kurtmckee:
problems fixed - Great!
Portable install option - That's a limitation of the beta.
case normalization - Yes, please open a new thread and add steps to reproduce. I have a hunch what this might be about (ignored conflict?), even though FFS should already handle cases like these.

[kurtmckee]

@Zenju, I've created a new thread regarding the case normalization issue I encountered.

[kurtmckee]

@Zenju, I see that FFS 8.10 has been released and the changelog indicates this issue has been fixed.

Thank you for your work!