2013/4/5 Matt Johnston <m...@ucc.asn.au>: > > > Roy Tam <roy...@gmail.com> wrote: >>I got same issue with 2012.55-1.3@debian(debian does not have 2013.56 >>at the moment) without -K switch. >>Once I not issuing 'exit' command but closing putty window directly, >>the session leaves alone. > > That sounds exactly like the situation fixed in 2013.56
I tried "dpkg-buildpackage -rfakeroot" dropbear-2013.56 and installed dropbear_2013.56-0.1_i386.deb restarted dropbear services, open 2 putty connection to that host, and press [X] button on one of them, then run "w" on another one, it show 2 sessions. In "ps auxww", it shows 3 lines of: /usr/sbin/dropbear -d /etc/dropbear/dropbear_dss_host_key -r /etc/dropbear/dropbear_rsa_host_key -p 22 -W 65536 So, the problem still exists. > > Cheers, > Matt >> >>> >>> Cheers, >>> Matt >>> >>> >>> On 2013-04-05 16:25, Mattias Walström wrote: >>>> >>>> Hi! >>>> I still have problems, this is my output from 'who': >>>> admin pts/0 02:50 Apr 5 07:24:09 x.x.x.x >>>> admin pts/1 00:00 Apr 5 09:39:05 y.y.y.y >>>> >>>> current time: >>>> Fri Apr 5 10:18:27 CEST 2013 >>>> >>>> shouldn't the first session be timed out? It has not just been idle >>>> for 2 h 50 min, >>>> the computer is not there any more. So in my opinion, dropbear >>should >>>> have forgotten the >>>> connection. >>>> >>>> Mattias >>>> >>>> On 2013-04-01 17:01, Matt Johnston wrote: >>>>> >>>>> Hi, >>>>> >>>>> The attached attached patch against 2013.56 should fix it, or >>>>> https://secure.ucc.asn.au/hg/dropbear/rev/70811267715c >>>>> >>>>> Dropbear wasn't running cleanup handlers when it exited due >>>>> to the TCP connection being closed. >>>>> >>>>> Matt >>>>> >>>>> On Thu, Mar 28, 2013 at 07:24:55PM +0800, Matt Johnston wrote: >>>>>> >>>>>> I think that -K on the server should be enough. On the >>>>>> server can you run "tcpdump -i eth0 -w cap1.cap port 22", >>>>>> get a ssh session going, pull out the cable, wait 10 >>>>>> minutes, then send me the capture? >>>>>> >>>>>> Could you also check that the Dropbear process for the >>>>>> connection is still running after the connection should have >>>>>> been finished. It's possible that the process is exiting but >>>>>> the session cleanup code isn't working correctly. The whole >>>>>> debug log might give me an idea what's going on. >>>>>> >>>>>> Cheers, >>>>>> Matt >>>>>> >>>>>> On Thu, Mar 28, 2013 at 09:56:02AM +0100, Mattias Walström wrote: >>>>>>> >>>>>>> Thanks for your responses, all your suggestions imply that you >>should >>>>>>> do something >>>>>>> in the client (set keepalive on client end), but shouldn't the >>server >>>>>>> itself be able to >>>>>>> decide if a client is dead (can't OpenSSH do this?). >>>>>>> >>>>>>> If I do the -K 15 -I 20 on the server end only, this will close >>the >>>>>>> connection when >>>>>>> the OpenSSH client has not sent any characters in 20s. I expected >>the >>>>>>> keepalive to be >>>>>>> two way, that the server got responses on these packages as well, >>is >>>>>>> that not the case? >>>>>>> >>>>>>> Regards >>>>>>> Mattias >>>>>> >>>>>> >>>>>>>>> On Wed, Mar 27, 2013 at 11:24 AM, Mattias Walström < >>>>>>>>> mattias.walst...@westermo.se> wrote: >>>>>>>>> >>>>>>>>>> Hi! >>>>>>>>>> I am running dropbear 2013.56, connecting to the server with a >>PC >>>>>>>>>> but >>>>>>>>>> not performing a clean close (I pulled my ethernet cable), >>this >>>>>>>>>> caused >>>>>>>>>> dropbear to never drop its connection. >>>>>>>>>> >>>>>>>>>> Looking at the utmp entries, I could see that the connection >>never >>>>>>>>>> got >>>>>>>>>> dropped, >>>>>>>>>> the utmp entries was kept forever, and running with debug >>indicates >>>>>>>>>> that >>>>>>>>>> also. >>>>>>>>>> Tried to use -K to send keepalive, but it just keeps sending >>>>>>>>>> keepalives >>>>>>>>>> to the peer, >>>>>>>>>> even it is no longer there, and not possible to reach. >>Shouldn't >>>>>>>>>> the connection be dropped if the keepalive does not reach its >>>>>>>>>> destination? >>>>>>>>>> >>>>>>>>>> I know there is the -I option, but that does not really do >>what I >>>>>>>>>> want, >>>>>>>>>> I want the connection to be tear down when the peer is >>unreachable, >>>>>>>>>> not >>>>>>>>>> when the user has been idle for a while. >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> Mattias >>>>>>>>>> >>>>>>> >>> >