forwarding problems

[Maris, Rob]

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 <matt at ucc.asn.au>:

> 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