Re: forwarding problems
Maris, Rob <maris.rob <at> ingenieur.de>
2012-07-23 13:10:12 GMT
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
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.
Note: I also noticed
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 <matt <at> ucc.asn.au>:
> Dropbear already does SO_REUSEADDR for all listening
> sockets, see
> Can you run strace on dbclient to see what's failing? Does
> the server log anything?
> 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.