[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bad packet length


Hello,

This will not work, because SSH is not a stateless protocol - when
you're forking, the internals of SSH sessions state duplicate, and this
is not supported. You would have the same problem with other
cryptographic libraries, including for SSL protocol.
If you need to both read and write in a SSH session, you will need to do
it from the same process and preferably from the same thread. libssh
doesn't support concurrent channel_read and channel_write from different
threads.

Kr,

Aris

Le 14/06/12 08:15, Aviv Zilberman a écrit :
> *Hi,*
> 
> * *
> 
> *I read all the mailing in the archive regarding “bad packet length”
> issue and still didn’t understand the solution.*
> 
> *I am able to write successfully one buffer of data into SSH channel
> using process X (Solaris x86), the remote side (VxWorks) read it
> successfully and send response. *
> 
> *Process Y (I used fork() after connect so one process is responsible
> for writing while the other for reading – both of them use same channel)
> read the message successfully and “automatically” (trigger by libssh)
> send SSH2_MSG_CHANNEL_WINDOW_ADJUST message.*
> 
> *From this moment and so on, every message arrived to remote host
> through the channel is dropped due to “bad packet length”.*
> 
> *Any idea ?*
> 
> * *
> 
> *Thanks in advance,*
> 
> *Aviv*
> 
> * *
> 
> * *
> 
> This e-mail message is intended for the recipient only and contains
> information which is CONFIDENTIAL and which may be proprietary to ECI
> Telecom. If you have received this transmission in error, please inform
> us by e-mail, phone or fax, and then delete the original and all copies
> thereof.
> 

Follow-Ups:
RE: Bad packet lengthAviv Zilberman <Aviv.Zilberman@xxxxxxxxxxx>
References:
Bad packet lengthAviv Zilberman <Aviv.Zilberman@xxxxxxxxxxx>
Archive administrator: postmaster@lists.cynapses.org