Subject: RE: Packet drop on full socket problem

RE: Packet drop on full socket problem

From: Daniel Stenberg <>
Date: Thu, 7 Oct 2010 12:59:22 +0200 (CEST)

On Thu, 7 Oct 2010, Thomas Rauscher wrote:

> You are right, the return value can't be the problem.
> I'm not very familiar with SSH internals, so I may be wrong with the
> following idea.
> What happens when the same packet is encrypted twice? Are the packets binary
> identical or has the internal state of the crypt function changed? Could
> this confuse the receiver then?

Your mails got me thinking about what happens on a short send()s and what
effect libssh2's way of dumping the "resend" buffer like that has.

It has made me completely switch in this matter and now I think you are
absolutely right. What I think may happen is this:

within _libssh2_channel_write()

   _libssh2_transport_write() gets called once to send X bytes. It only manages
   to send off Y bytes (which is less than X). The remaining data that wasn't
   sent is the remainder of the single SSH packet. Only a half SSH packet was
   sent. It is incomplete. The rest is saved in "outbuf" buffer.

   _libssh2_transport_write() gets called again to send the remaining (X-Y)
   bytes and gets EAGAIN back. The second part of the packet didn't get sent.
   The call to _libssh2_transport_drain() is then completely wrong. It will
   discard the second part of the packet.

How to fix?

   The _libssh2_transport_write() function returns data that it sent, even if
   the amount is not a full SSH packet. We can't allow it to do that. We need
   to keep the application thinking EAGAIN until the full packet has been sent,
   as only when the full packet has been sent we can say that the data has
   actually been sent and we are prepared to get more data to send.

   I'll think a bit more and provide something I think is an improvement. Hang

And to answer your question: each packet has an sequence number that gets
increased in each packet, so if there's a bad packet in between that the
receiver will through away as garbage, the receiver will be out of sync with
the sequence number..

Received on 2010-10-07