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 <[email protected]> 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: [email protected] [mailto:[email protected]] > Sent: Thursday, June 14, 2012 11:12 AM > To: [email protected] > 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 > <[email protected]> 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. > >
