forwarding problems

[Maris, Rob]

Am 23.07.2012, 17:16 Uhr, schrieb Matt Johnston <matt at ucc.asn.au>:

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