forwarding problems

[Matt Johnston]

When you kill a process the OS will close its TCP connections by sending a reset packet to the other side. If the whole machine turns off those packets can't be sent.

After it reboots, the OS should reject packets from the stale connections and reset them then. But that'll only happen when data or a TCP keepalive is transferred (I think).

Matt

"Maris, Rob" <maris.rob at ingenieur.de> wrote:

>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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20120724/43b044a4/attachment.htm