forwarding problems

[Matt Johnston]

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.

Is the embedded device sending icmp port unreachable (or
similar?) packets out, or does it just silently drop the
stale connection's packets?

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 <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