2013/4/5 Matt Johnston <m...@ucc.asn.au>: > Are you using -K ? I wouldn't expect it to time out otherwise. As an example > I hibernate my computer nightly but connections remain alive in the morning.
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. > > 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 >>>>>>>> >>>>> >