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
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.
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
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
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
I am not using Keepalive. Why is keepalive required? If reading the manual
understood that was to make sure firewalls did not close the connection.
Shouldn't a TCP socket timeout in maximum 15 minutes by itself?
Mattias
On 2013-04-05 13:18, Matt Johnston wrote:
Are you using -K ? I wouldn't
Actually.. when I looked at it again. My first session has been closed, it took
some while, but at last it seems like it was closed.
I just read more about TCP timeouts, must have mixed things up. It is rather
long, but it seems that dropbear now clean upp after itself.
Now in who, I can see
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
And the patch actually attached here.
On Mon, Apr 01, 2013 at 11:01:42PM +0800, 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
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
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
Hi,
At the very least if there is traffic on the connection
(which -K will ensure) then TCP should timeout and the
connection should eventually (a minute or so?) close.
Can you get a packet capture with tcpdump?
Cheers,
Matt
On Wed, Mar 27, 2013 at 04:24:27PM +0100, Mattias Walström wrote:
I remember reporting this problem and sending a patch long time ago (for
version 0.52).
The problem with the keep-alive (if I remember correctly) was that every
time dropbear was sending the keep-alive message, it was also resetting the
timeout counter... so dropbear or dbclient never detect the
I thought those were fixed in 0.53 or perhaps 2011.54:
2011.54 - Tuesday 8 November 2011
- Fixed case where -K 1 keepalive for dbclient would cause a SSH_MSG_IGNORE
packet to be sent
0.53 - Thurs 24 February 2011
- Make -K (keepalive) and -I (idle timeout) work together sensibly in the
client.
Yep, you're right Matt... the latest version contains those fixes... (the
truth is that I'm still working with my patched 0.52 that is rock solid for
my usage)...
Regards,
Fabrizio
On Wed, Mar 27, 2013 at 11:47 AM, Matt Johnston m...@ucc.asn.au wrote:
I thought those were fixed in 0.53 or
14 matches
Mail list logo
