From: grahn+nntp@snipabacken.se
On Thu, 25 Jun 2009 03:13:06 -0400, Barry Margolin wrote:
> In article
> <0df35d0a-48f2-4d6d-90b5-59d9580ba87b@o5g2000prh.googlegroups.com>,
> David Schwartz wrote:
>
>> On Jun 24, 2:28 am, Marco Peng wrote:
>>
>> > I meet a problem, I use dropbear as a ssh server.
>> > I limit the concurrent session max = 1.
>>
>> This strikes me as an incredibly bad idea. If there's some problem
>> within existing session, you can't log in to fix it, as you have
>> discovered. Are you really sure that's what you want to do? In any
>> event, 'dropbear' has a '-K' option to keep the connection active and
>> a '-I' option to break the connection on inactivity.
>>
>> DS
>
> Everyone's recommending turning on keepalives, but I don't understand
> why this is necessary for the OP's problem. It sounds like dropbear has
> a bug. When he closes the ssh connection, it should send a FIN and
> dropbear should realize that the session no longer exists.
>
> Keepalive is necessary if he pulls the network cable or powers down the
> client machine without cleanly shutting down ssh first. But he said
> "shutdown my client without logout".
I kind of assumed he didn't mean "controlled shutdown" as in e.g.
shutting down a Unix machine, but rather hitting the power switch.
Maybe he's using some hand-held wireless device. Either way, he
should have explained better what he's doing and why.
It's interesting in a way ... back in the days I used to shut down
my Commodore-Amiga by just turning power off, because there was no
disk write cache to speak of. With TCP, it's antisocial to do so
because it may leave state on other hosts across the world.
I wonder if the "Host Requirements" RFC, 1123 or whatever it is,
mentions this. That an Internet host should RST before going down,
in decent shutdown scenarios.
/Jorgen
--
// Jorgen Grahn R'lyeh wgah'nagl fhtagn!
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
