zaq21wsx at rediffmail
Nov 3, 2009, 3:25 AM
Post #3 of 3
(125 views)
Permalink
|
ok basically my FXP_READDIR loop consumed the entire channel window and the partial sftp packet was probably the last channel data server could send. Fixed that by introducing WINDOW_ADJUST message logic. Thanks for your inputs on this.
On Fri, 30 Oct 2009 05:38:29 +0530 wrote
>On Fri, 29 Oct 2009, qqq wrote:
> Hello,
>
> I have a very basic sftp client which is able to successfully
> intialize the transport layer, password authenticate, and start the
> sftp subsystem. Now, I am stuck with an issue when I try to retrieve
> the directory listing. Sometimes I get a transport packet in which the
> sftp packet length field registers a length greater than the enclosing
> transport packet. In othet words sometimes I get a transport packet
> whose lenght is less than what the sftp packet length field registers.
> This happens only sometimes. That is, if I give SSH_FXP_READDIR
> commands say 30 times on the same directory, then I get this packet
> after around 25-30 iterations. I tried to check the readability of the
> socket when this happens but the server does not send anything after
> this and select just hangs. I am not able to think of why this is
> happening and would apprecaite pointers in the right direction. thanks
sftp operates at a protocol layer above the SSH transport, so the size of
sftp's packets may exceed the maximum allowed by the ssh connection. In
these cases, a sftp packet may span multiple transport packets.
-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev[at]mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev[at]mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
|
