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
