Re: Bad packet length

["jeetu.golani@xxxxxxxxx" <jeetu.golani@xxxxxxxxx>]

Hi Aviv,

> As I mention in my mail, I am using multi processes rather multi threads .
> The session is being "duplicate" as part of the "fork()" mechanism while one process only reading from it while other only writing to it.
> Can it still be the same root cause ?

I think one of the core libssh developers maybe better equipped to
answer that, however I suspect that the issue is probably the same
since it involves the same session, in your case across multiple
processes. Maybe you could put across a detailed libssh packet log
some place and that may shed further light.

Bye for now

On Thu, Jun 14, 2012 at 1:19 PM, Aviv Zilberman
<Aviv.Zilberman@xxxxxxxxxxx> wrote:
> Hi Jeetu,
>
> Thanks for replying.
> As I mention in my mail, I am using multi processes rather multi threads .
> The session is being "duplicate" as part of the "fork()" mechanism while one process only reading from it while other only writing to it.
> Can it still be the same root cause ?
>
> Thanks in advance,
> Aviv
>
>
> -----Original Message-----
> From: jeetu.golani@xxxxxxxxx [mailto:jeetu.golani@xxxxxxxxx]
> Sent: Thursday, June 14, 2012 11:12 AM
> To: libssh@xxxxxxxxxx
> Subject: Re: Bad packet length
>
> Hi Aviv,
>
> I think Aris and the others here are better equipped to help you,
> however I've faced similar issues, as you may have read on the thread.
>
> While I'm not clear if you've been working on your own server or
> client wherein you are seeing this problem, however from what was
> discussed (as I understood it), multithreading over a single session
> i.e. using the same session in multiple threads causes race conditions
> which show this behaviour. The solution seems to be to restrict all
> processing for a single session within the same thread, you can have
> multiple sessions each within their own thread however multiple
> threads working on the same session creates problems.
>
> I've verified in my own server that so long as you stick to a single
> session single thread policy, all is well. Unfortunately I've been
> looking at providing X forwarding on my server and this is a little
> tricky to have without having the same session worked on by multiple
> threads. Mechanisms have been suggested to do this by the kind folk
> here however honestly I haven't gotten around to trying them yet.
>
> Hope the above helps, as said maybe the others here can offer a better
> solution, If you'd like you can also go through the server code I've
> been working on and my attempts to have all processing for a single
> session in one thread. The code can be found using - git clone
> git://ebrain.in/libssh-server.git
>
> Bye for now
> Jeetu
> ebrain.in | Beehive Computing
> Discover and use software from devices around you. An open source
> (GPLv3) project.
>
>
> On Thu, Jun 14, 2012 at 11:15 AM, Aviv Zilberman
> <Aviv.Zilberman@xxxxxxxxxxx> wrote:
>> 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.
>
>
> 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.
>
>