<html><head/><body><html><head></head><body>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.<br>
<br>
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).<br>
<br>
Matt<br><br><div class="gmail_quote">"Maris, Rob" <maris.rob@ingenieur.de> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre style="white-space: pre-wrap; word-wrap:break-word; font-family: sans-serif; margin-top: 0px">Am 23.07.2012, 17:16 Uhr, schrieb Matt Johnston <matt@ucc.asn.au>:<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">Ah right. Is the server-side sshd/dropbear process still<br />running? I guess something hasn't noticed that the client<br />has gone away, though I'm not really sure what you can do.</blockquote><br />Hm, are you implicitly suggesting that SO_REUSEADDR woudn't help at all?<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">Is the embedded device sending icmp port unreachable (or<br />similar?) packets out, or does it just silently drop the<br />stale connection's packets?</blockquote><br />Well, to just address another point of view: I have never had problems in <br />a test phase, where I used two linux
desktops or notebooks for experiments <br />with communication via two forwarders to one middleman server. Of course, <br />any kill of running processes yield a proper closing of tcp channels. And <br />I don't brutally switch off my notebook. I didn't try it out (but I will <br />do), what its happening, if I brutally power-off my notebook, and see what <br />happens when I reestablish a connection with the same forwarder.<br /><br />Such power cycling is (of course) the natural thing with embedded systems. <br />When I then connect to another port - no problem.<br /><br />Rob<br /><br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">Matt<br /><br />On Mon, Jul 23, 2012 at 03:10:12PM +0200, Maris, Rob wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;">Thanks for instant answering,<br /><br />I was still aware of
SO_REUSEADDR in dbutil.c, but could not quickly<br />determine whether this also applies to forwarding channels. In any<br />case, reconnect goes OK when the embedded system gets a reboot prior<br />to poweroff (as could be expected).<br /><br />In the problem case, the host netstat shows up<br />tcp 0 0 localhost.localdo:51225 localhost.localdo:10526<br />CLOSE_WAIT<br /><br />BTW: I'm using 0.52 on a blackfin platform.<br /><br />Regarding strace: Must be prepared. Is not yet built into the root<br />file system. I'll return later to it.<br /><br />Rob<br /><br />Note: I also noticed<br /><a href="http://comments.gmane.org/gmane.network.ssh.dropbear/962">http://comments.gmane.org/gmane.network.ssh.dropbear/962</a><br />before, and the suggestions in that thread will probably be realised<br />after the current problem has been solved.<br /><br /><br /><br />Am 23.07.2012, 14:32 Uhr, schrieb Matt Johnston <matt@ucc.asn.au>:<br /><br /><blockquote
class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;">Hi,<br /><br />Dropbear already does SO_REUSEADDR for all listening<br />sockets, see<br /><a href="https://secure.ucc.asn.au/hg/dropbear/file/983a817f8e41/dbutil.c#l254">https://secure.ucc.asn.au/hg/dropbear/file/983a817f8e41/dbutil.c#l254</a><br /><br />Can you run strace on dbclient to see what's failing? Does<br />the server log anything?<br /><br />Cheers,<br />Matt<br /><br />On Mon, Jul 23, 2012 at 02:13:05PM +0200, Maris, Rob wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #fcaf3e; padding-left: 1ex;">Use case:<br />- embedded system running dbclient with server connection that<br />includes a port forwarding.<br />- system is powered off, and powered on again<br />- upon next boot, the following message is given:<br />dbclient: Remote TCP forward request failed (port 10526 -> <br /></blockquote></blockquote><a
href="127.0.0.1:22">127.0.0.1:22</a>)<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #fcaf3e; padding-left: 1ex;">I'd believe that doing a SO_REUSEADDR via setsockopt() would resolve<br />this issue.<br />However, I'm not sure and where to implement this (in cli_tcpfwd.c?)<br /><br />Thanks for any suggestions.<br /><br />Rob<br /></blockquote></blockquote></blockquote></blockquote></pre></blockquote></div></body></html></body></html>