[paramiko] paramiko stops responding after huge data is transferred !

[Dwayne Litzenberger]

I just saw this problem again last night on two different machines with the 
latest code from Robey's bzr tree.  I'm working on reproducing it now.

FYI:  The client was Paramiko/Python 2.5/Win32, the server was 
Paramiko/Python2.4/Linux.

On March 17, 2008 09:37:43 am Dwayne Litzenberger wrote:
> I saw this behaviour too, recently.  I was going to see if I could
> reproduce it, but apparently you've done that for me.
>
> On March 15, 2008 07:26:26 am Deepak Rokade wrote:
> > Hi All,
> > I am using paramiko 1.5.3 in my python application.
> > I found that when large data is fetched using paramiko with prefetch,
> > deadlock condition occurs.
> > I found through paramiko debug level logs, that deadlock occurs when
> > paramiko goes for rekeying.
> > Below is the paramiko log.
> >
> > DEB [20080315-18:27:58.843] thr=1   paramiko.transport: Rekeying (hit 91
> > packets, 1051212 bytes received)
> >
> > Above is the last log I saw after which my application stopped
> > responding.
> >
> > For reproducing deadlock quickly, I had set the low limit for
> > REKEY_PACKETS. I set the limit as
> >     REKEY_PACKETS = pow(2, 20)
> >     REKEY_BYTES = pow(2, 20)
> > (In file paramiko/packet.py , class Packetizer)
> >
> >
> > For tackling this problem I close connections periodically.
> > Has this problem been solved in later verion of paramiko ?.
> >
> > I tried paramiko 1.7.1 for short test in which I did not observe deadlock
> > condition even after setting REKEY_PACKETS limit.
> > Below are the debug logs.
> >
> > DEB [20080315-18:23:00.193] thr=6   paramiko.transport: Switch to new
> > keys ...
> > DEB [20080315-18:23:00.467] thr=6   paramiko.transport: Rekeying (hit 91
> > packets, 1049340 bytes received)
> > DEB [20080315-18:23:00.571] thr=6   paramiko.transport: kex
> > algos:['diffie-hellman-group-exchange-sha1',
> > 'diffie-hellman-group1-sha1'] server
> >  key:['ssh-rsa', 'ssh-dss'] client encrypt:['aes128-cbc', '3des-cbc',
> > 'blowfish-cbc', 'cast128-cbc', 'arcfour', 'aes192-cbc', 'aes256-cbc', '
> > rijndael-cbc at lysator.liu.se', 'aes128-ctr', 'aes192-ctr', 'aes256-ctr']
> > server encrypt:['aes128-cbc', '3des-cbc', 'blowfish-cbc', 'cast128-cb
> > c', 'arcfour', 'aes192-cbc', 'aes256-cbc', 'rijndael-cbc at lysator.liu.se',
> > 'aes128-ctr', 'aes192-ctr', 'aes256-ctr'] client mac:['hmac-md5', '
> > hmac-sha1', 'hmac-ripemd160', 'hmac-ripemd160 at openssh.com',
> > 'hmac-sha1-96', 'hmac-md5-96'] server mac:['hmac-md5', 'hmac-sha1',
> > 'hmac-ripemd1 60', 'hmac-ripemd160 at openssh.com', 'hmac-sha1-96',
> > 'hmac-md5-96'] client compress:['none', 'zlib'] server compress:['none',
> > 'zlib'] client la
> >
> >
> > However I am not sure if this problem is actually solved in version 1.7.1
> > Please guide.



-- 
Dwayne Litzenberger, B.A.Sc.
Information Technology Analyst

Open Systems Canada Limited
#210 - 2332 11th Ave
Regina, SK S4P0K1
Office: (306) 359-OSCL (6725)
http://www.oscl.ca/