Am 23.07.2012, 17:16 Uhr, schrieb Matt Johnston <[email protected]>:
Ah right. Is the server-side sshd/dropbear process still
running? I guess something hasn't noticed that the client
has gone away, though I'm not really sure what you can do.
Hm, are you implicitly suggesting that SO_REUSEADDR woudn't help at all?
Is the embedded device sending icmp port unreachable (or
similar?) packets out, or does it just silently drop the
stale connection's packets?
Well, to just address another point of view: I have never had problems in
a test phase, where I used two linux desktops or notebooks for experiments
with communication via two forwarders to one middleman server. Of course,
any kill of running processes yield a proper closing of tcp channels. And
I don't brutally switch off my notebook. I didn't try it out (but I will
do), what its happening, if I brutally power-off my notebook, and see what
happens when I reestablish a connection with the same forwarder.
Such power cycling is (of course) the natural thing with embedded systems.
When I then connect to another port - no problem.
Rob
Matt
On Mon, Jul 23, 2012 at 03:10:12PM +0200, Maris, Rob wrote:
Thanks for instant answering,
I was still aware of SO_REUSEADDR in dbutil.c, but could not quickly
determine whether this also applies to forwarding channels. In any
case, reconnect goes OK when the embedded system gets a reboot prior
to poweroff (as could be expected).
In the problem case, the host netstat shows up
tcp 0 0 localhost.localdo:51225 localhost.localdo:10526
CLOSE_WAIT
BTW: I'm using 0.52 on a blackfin platform.
Regarding strace: Must be prepared. Is not yet built into the root
file system. I'll return later to it.
Rob
Note: I also noticed
http://comments.gmane.org/gmane.network.ssh.dropbear/962
before, and the suggestions in that thread will probably be realised
after the current problem has been solved.
Am 23.07.2012, 14:32 Uhr, schrieb Matt Johnston <[email protected]>:
>Hi,
>
>Dropbear already does SO_REUSEADDR for all listening
>sockets, see
>https://secure.ucc.asn.au/hg/dropbear/file/983a817f8e41/dbutil.c#l254
>
>Can you run strace on dbclient to see what's failing? Does
>the server log anything?
>
>Cheers,
>Matt
>
>On Mon, Jul 23, 2012 at 02:13:05PM +0200, Maris, Rob wrote:
>>Use case:
>>- embedded system running dbclient with server connection that
>>includes a port forwarding.
>>- system is powered off, and powered on again
>>- upon next boot, the following message is given:
>>dbclient: Remote TCP forward request failed (port 10526 ->
127.0.0.1:22)
>>
>>I'd believe that doing a SO_REUSEADDR via setsockopt() would resolve
>>this issue.
>>However, I'm not sure and where to implement this (in cli_tcpfwd.c?)
>>
>>Thanks for any suggestions.
>>
>>Rob
