-
Notifications
You must be signed in to change notification settings - Fork 599
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
EOF when trying to read/write file using Tectia SSH Server #54
Comments
I'll try and set this up if there's a Mac version of the server. Meanwhile can you post DEBUG-level logs as well? |
is the problem only since 0.7.0? |
No, it was originally discovered with 0.3.1. I just ran the tests with 0.7.0 to make sure it hadn't been fixed in a later version. I'll get on those DEBUG logs. |
Here's the full dump including DEBUG logs:
|
Thanks @incendium It's looking like Tectia doesn't like the READ sftp request sshj sends and just closes the channel. I think the best indicator of what's up may be Tectia logs. Can you get your hands at those, and correlate if there's a relevant event? http://www.tectia.com/manuals/manager-admin/61/ch07s06s02.html |
Note: I built the latest version from git to see if any of the recent changes made a difference. Here is the entire event log chain for a similar request:
And the corresponding SSHJ logs:
|
and here's the error...
hmm |
As there hasn't been any other such report, I have to chalk it down to some idiosyncrasy of the Tectia implementation. Sorry... |
Hi, We've got the exact same problem with Tectia server, any ideas how to get this working? |
I also encountered the same problem with the Tectia Server. I agree, that probably the server does something weird to cause this, but on the other hand, other tools seems to work just fine with the server. I don't have access to the server, so can't fix anything there :( |
+1 please reopen we are also encountering this problem using sshj against tectia server there is a free tectia download at: http://www.ssh.com/index.php/evaluation-downloads/ssh-clientserver-evaluation.html |
Please, reopen the issue, as it seems to be a SSHJ problem. Apparently it seems that the Tectia SSH server creates a handle for the OpenDIR operation and gives it to the SSHJ client. The SSH File Transfer Protocol clearly states: "The SSH_FXP_HANDLE response has the following format: Checking at the SSHJ code (sshj-0.8.1.zip) it seems that the code assumes the incoming string is UTF-8, and the code does some conversions that will fail if applied against a binary string. Tectia SSH Server sends binary strings, so, SSHJ does some conversion resulting in a modified handle when requesting for ReadDir… I have taken the liberty to modify the SSHJ code a bit, just by changing the type of the “handle” as “byte[]” and using readBytes/writeBytes function and it seems to correct the problem. To my eyes, Tectia SSH Server works as specified, and SSHJ is violating clearly the protocol. Please, correct me if I am wrong. |
Thanks for looking into this. Would you like to provide a patch? |
This should be fixed with the merged patch of #150. Closing |
We're having issues communicating with Tectia's SSH server using the latest SSHJ client (0.7.0). Here's the test code and a dump of the error log:
stdout:
stderr:
You can grab the server here - http://www.tectia.com/en/Customers/Evaluate/Client_-_Server.iw3. I have only tested the Windows server (on XP). Setup is relatively straight forward, everything is set up straight out of the box, all you need to do is create a user named test with the password test and drop a file called "test.txt" into their home directory.
Let me know if you need any more info.
The text was updated successfully, but these errors were encountered: