[paramiko] [PATCH] missing language field on SSH_FXP_STATUS; fixes interop w/ lftp

Wed May 7 09:43:56 PDT 2008

It turns out that lftp expects SSH_FXP_STATUS packets to include a
language tag (which, looking at draft 3 [which I understand to be the
one paramiko's sftp support conforms to?], does appear to be mandatory),
and presently (prior to the 3.7.2 release), lftp doesn't play nice with
servers which fail to do so.

paramiko.sftp_server.SFTPServer._send_status sends a text field 'desc',
but no RFC-1766-compliant language field. The attached patch resolves
this, and fixes interoperability with lftp 3.7.1.

-- 

Charles Duffy

Systems Engineering

charles_duffy at messageone.com

http://www.messageone.com <http://www.messageone.com/> 

Dell MessageOne
11044 Research Blvd
Building C, Fifth Floor
Austin, TX 78759

From: paramiko-bounces at lag.net [mailto:paramiko-bounces at lag.net] On
Behalf Of Charles Duffy
Sent: Tuesday, May 06, 2008 5:59 PM
To: paramiko at lag.net
Subject: Re: [paramiko] OpenSSH sftp server returns EOF after
directorylisting, paramiko does not.

My initial diagnosis of this issue was incorrect - paramiko is clearly
sending back EOF where it's supposed to.

I'm digging into lftp to try to track this down.

-- 

Charles Duffy

Systems Engineering

charles_duffy at messageone.com

http://www.messageone.com <http://www.messageone.com/> 

Dell MessageOne
11044 Research Blvd
Building C, Fifth Floor
Austin, TX 78759

From: paramiko-bounces at lag.net [mailto:paramiko-bounces at lag.net] On
Behalf Of Charles Duffy
Sent: Monday, May 05, 2008 12:25 PM
To: paramiko at lag.net
Subject: [paramiko] OpenSSH sftp server returns EOF after directory
listing,paramiko does not.

Per subject - if my interpretation of the behavior described below is
correct, lftp (even as current as 3.7.1) appears to be relying on this
behavior.

Running against my paramiko-based server, lftp hangs indefinitely trying
to run a directory listing:

---- path on wire is `/'

---> sending a packet, length=10, type=11(OPENDIR), id=4

<--- got a packet, length=12, type=102(HANDLE), id=4

---- got file handle 687831 (3)

---> sending a packet, length=12, type=12(READDIR), id=5

<--- got a packet, length=231, type=104(NAME), id=5

---- file name count=2

---> sending a packet, length=12, type=12(READDIR), id=6

---> sending a packet, length=12, type=12(READDIR), id=7

<--- got a packet, length=24, type=101(STATUS), id=6

<--- got a packet, length=24, type=101(STATUS), id=7 

  ^^ hangs here until interrupted

...whereas when running against an OpenSSH  server, behavior is quite
different:

---- path on wire is `//home/cduffy/tmp/a'

---> sending a packet, length=28, type=11(OPENDIR), id=4

<--- got a packet, length=13, type=102(HANDLE), id=4

---- got file handle 00000000 (4)

---> sending a packet, length=13, type=12(READDIR), id=5

<--- got a packet, length=501, type=104(NAME), id=5

---- file name count=5

---> sending a packet, length=13, type=12(READDIR), id=6

---> sending a packet, length=13, type=12(READDIR), id=7

<--- got a packet, length=28, type=101(STATUS), id=6

---- status code=1(EOF), message=End of file

---- eof

<--- got a packet, length=28, type=101(STATUS), id=7

---- status code=1(EOF), message=End of file

drwxr-xr-x    4 cduffy   cduffy       4096 May  4 17:48 .

drwxr-xr-x    4 cduffy   cduffy       4096 May  4 17:33 ..

-rw-r--r--    1 cduffy   cduffy          0 May  4 17:48 A

drwxr-xr-x    3 cduffy   cduffy       4096 May  4 17:33 b

drwxr-xr-x    3 cduffy   cduffy       4096 May  4 17:33 d

---> sending a packet, length=13, type=4(CLOSE), id=8

<--- got a packet, length=24, type=101(STATUS), id=8

---- status code=0(OK), message=Success

It appears that STATUS packets 6 and 7 from OpenSSH signal EOF, while
those from paramiko signal some other status (perhaps OK?) which lftp
doesn't see fit to comment on, even on a maximal debug level.

Is this difference in behavior intentional? Is it within the letter of
the sftp standard? (Where *is* the sftp standard? I've had a fair bit of
trouble googling it up).

Thanks!

-- 

Charles Duffy

Systems Engineering

charles_duffy at messageone.com

http://www.messageone.com <http://www.messageone.com/> 

Dell MessageOne
11044 Research Blvd
Building C, Fifth Floor
Austin, TX 78759

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.lag.net/pipermail/paramiko/attachments/20080507/504fc439/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: paramiko_language_tag.diff
Type: application/octet-stream
Size: 1996 bytes
Desc: paramiko_language_tag.diff
Url : http://www.lag.net/pipermail/paramiko/attachments/20080507/504fc439/attachment-0001.obj 