PuTTY doesn't log SFTP packets correctly

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
From putty.log:

Outgoing packet type 94 / 0x5e (SSH2_MSG_CHANNEL_DATA)
  00000000  00 00 00 00 00 00 00 05 01 00 00 00
03           .............

Dissecting this packet is easy enough.  From RFC4254:

      byte      SSH_MSG_CHANNEL_DATA
      uint32    recipient channel
      string    data

That yields the following mapping:

00 00 00 00 = recipient channel
00 00 00 05 = data string length (8,192 bytes)
...         = data string

The data string, in turn, corresponds to this (from draft-ietf-secsh-

        uint32             length
        byte               type
        byte[length - 1]   data payload

01 00 00 00 = length

Of course, that doesn't make a lot of sense.  Given that packets
location, it should be SSH_FXP_INIT - not SSH_FXP_OPEN.  Also, the
length, itself, doesn't make a whole lot of sense.

If we assume the data string, instead, corresponds to this, we get a
more sensical mapping:

        byte               type
        byte[length - 1]   data payload

01 = type (SSH_FXP_INIT)
00 00 00 03 = data payload

Here's the structure of the data payload for SSH_FXP_INIT:

        uint32 version
        <extension data>

So, basically, the version is "00 00 00 03" with no extension data.
That makes sense.  What doesn't make sense to me is why the length
field is not repeated.  Indeed, if I don't repeat it in the SFTP
client I wrote, I get this:

5e:00:00:00:00:00:00:00:05:01:00:00:00:03         ^.............

<- NET_SSH2_MSG_IGNORE (0.0334s)
02:00:00:00:00                                    .....

5f:00:00:00:01:00:00:00:01:00:00:00:64:73:73      _...........dss
68:5f:70:61:63:6b:65:74:5f:77:72:61:70:70:65      h_packet_wrappe
72:5f:69:6e:70:75:74:3a:20:69:6e:76:61:6c:69      r_input: invali
64:20:70:61:63:6b:65:74:20:72:65:63:65:69:76      d packet receiv
65:64:3a:20:6c:65:6e:20:31:36:37:37:37:32:32      ed: len 1677722
30:20:63:6c:6f:73:69:6e:67:20:74:68:65:20:6f      0 closing the o
66:66:65:6e:64:69:6e:67:20:69:6e:70:75:74:20      ffending input
63:68:61:6e:6e:65:6c:2e                           channel.

ie. I get an error.

Here's what I have to do to not get an error:

5e:00:00:00:00:00:00:00:09:00:00:00:05:01:00      ^..............
00:00:03                                          ...

<- NET_SSH2_MSG_IGNORE (0.0569s)
02:00:00:00:00                                    .....

5e:00:00:00:01:00:00:00:25:00:00:00:21:02:00      ^.......%...!..
00:00:03:00:00:00:13:6e:65:77:6c:69:6e:65:40      .......newline@
76:61:6e:64:79:6b:65:2e:63:6f:6d:00:00:00:01      vandyke.com....
0a                                                .

Re: PuTTY doesn't log SFTP packets correctly

Quoted text here. Click to load it
Quoted text here. Click to load it
Quoted text here. Click to load it

I agree. In that case, it seems most likely that the SFTP length
field was transmitted in the _previous_ SSH2_MSG_CHANNEL_DATA, but I
can't confirm this since you've only quoted that one.
Simon Tatham         "Every person has a thinking part that wonders what

Re: PuTTY doesn't log SFTP packets correctly

Quoted text here. Click to load it

The previous packet:

Outgoing packet type 94 / 0x5e (SSH2_MSG_CHANNEL_DATA)
  00000000  00 00 00 00 00 00 00 04 00 00 00
05              ............

The dissection of it:

00 00 00 00 = recipient channel
00 00 00 04 = data string length
00 00 00 05 = data string

I'm not sure what this data string corresponds to, though.  Maybe it's
just the length parameter of the SFTP packet, but if the type and data
payload aren't there, then isn't it a malformed SFTP packet?

Re: PuTTY doesn't log SFTP packets correctly

Quoted text here. Click to load it
Quoted text here. Click to load it

It is.

No, because the type and data are in the next message!

An SFTP data stream is parsed by concatenating the data strings from
all the relevant SSH_MSG_CHANNEL_DATA packets, and then dividing the
result back up into packets according to the SFTP rules. There is no
necessary link between the SSH-level packet boundaries and the
SFTP-level ones: it is perfectly legal to split an SFTP packet
across multiple SSH_MSG_CHANNEL_DATAs as you see here, or to combine
two or more into a single SSH_MSG_CHANNEL_DATA, or both at once.
Simon Tatham         "What a caterpillar calls the end of the

Re: PuTTY doesn't log SFTP packets correctly

Quoted text here. Click to load it

Ah...  ok...  thanks!

That said, there is one more thing I'm curious about.  When I try to
upload a 1mb file, PuTTY sends out a bunch of packets like this:

Outgoing packet type 94 / 0x5e (SSH2_MSG_CHANNEL_DATA)
  00000000  00 00 00 00 00 00 00 04 00 00 10
1d              ............

ie. an SSH_FXP_WRITE packet with a length of 4,125 bytes.  Why not
just give it a length of 1,048,576?  SSH_MSG_CHANNEL_DATA's size is
limited per SSH_MSG_CHANNEL_OPEN (although presumably that size limit
only applies to packets sent from the server to the client - not the
other way around), but I don't recall any such limit.  The most I
could find discussing a limit is this:

   The maximum size of a packet is in practice determined by the
   (the maximum size of read or write requests that it sends, plus a
   bytes of packet overhead).  All servers SHOULD support packets of
   least 34000 bytes (where the packet size refers to the full length,
   including the header above).  This should allow for reads and
   of at most 32768 bytes.

That establishes a larger lower bound than what PuTTY is using and
doesn't really establish an upper bound at all.  Maybe in practice,
there's an upper bound, but I don't think the SFTP specs discuss one...

Re: PuTTY doesn't log SFTP packets correctly

Quoted text here. Click to load it

Something else I'm curious about...  why do the SSH_MSG_CHANNEL_DATA
packets that PuTTY sends out for uploading a 1mb file have a data
length of 512 bytes?  That's considerably less than even the maximum
packet size decided upon in SSH_MSG_CHANNEL_OPEN.

RFC4254 states the following:

   For example, one might want to use smaller packets for
   interactive connections to get better interactive response on slow

It seems that if that were the reason that the outgoing packets would,
in the SSH_MSG_CHANNEL_OPEN message, have a max reported size of 512
bytes, as well.  As is, they have a max reported size of 16,384 bytes.

I guess, ultimately, what I'm wondering if these implementation
decisions are done for practical reasons.  For example, comments in
SSH.C suggest that although, in theory, you always ought to send an
SSH_MSG_DISCONNECT, in practice, you shouldn't.  I haven't found any
reasons in the specs for why you'd want smaller packet sizes in these
situations, but maybe there are practical considerations that are
beyond the scope of the specs?

Site Timeline