"Always Keep This Host Connected" feature not working reliably when losing internet connection

[GoogleCodeExporter]

This refers to: http://code.google.com/p/connectbot/issues/detail?id=46

This feature is not working perfectly for me.

I setup the connection to be persistent and it retries the connection when it 
gets dropped.

But when the connection dropped because I've switched WLAN on/off, the 
connection retry halts at "<somehost>/<ip>:<port> - Network is unreachable".
I think the same happens when I temporarily lose my internet connection when 
traveling.

It just stays with that message and the connection never gets reestablished. :(
Thus portforwarding with connectbot is yet not stable enough for me. I have to 
manually close the connection and reopen it in connectbot to reestablish it.

Original issue reported on code.google.com by edwinst...@gmail.com on 3 Apr 2011 at 1:43

[GoogleCodeExporter]

I have the same behavior with latest version of connectbot on DInc (latest 
original Verizon 2.2 firmware , rooted).

For example, going down to subway (where mobile network is not available) and 
then out, ConnectBot doesn't try to reconnect anymore when out of subway. 
Connection is lost for good, unless I try to reconnect manually.

In cases where provider chooses to give your phone a "private" IP address (like 
Verizon and most others), using ConnectBot to establish and maintain a VPN 
tunnel with your chosen server (with reverse port forwarding) is one of the 
only universal ways of connecting remotely to your phone. But only if a tunnel 
is stable and reliable, i.e. can reconnect automatically when network 
conditions change.

Great app!  Just need to make it stable for background 24x7 service-like 
operation.

Original comment by dmitry.l...@gmail.com on 29 May 2011 at 4:19

[GoogleCodeExporter]

I suffer from the same reconnection issue described here (and i presume in 
issues 162, 278 and 336).

I've debugged the issue and conclude that---at least for ssh---there is a race 
condition between SSH.java:onDisconnect() (when the ssh connection is 
separated) and ConnectivityReceiver.java:onReceive() (when the network 
interface is disconnected).

On my system, the former wins most of the time by a tiny margin. This leads to 
the following:
In TerminalManager.java:requestReconnect() the condition 
connectivityManager.isConnected() is true when it should be false. This in turn 
leads to reconnectPending() being executed when the network is down.

Judging from the rest of the code, I'd expect that when requestReconnect() is 
called the network is supposed to be down, so that condition makes little sense 
to me. Maybe someone has a good reason for it.  Nevertheless, I've attached a 
patch removing that condition which solves the problem for me.

Original comment by lotan...@gmx.de on 14 May 2013 at 10:55

Attachments:

• fix_reconnect.patch

[GoogleCodeExporter]

Us usual, things are not as easy as they first seem.
My workaround in post #2 works for the transitions:

   mobile data -> no connection -> mobile data

and

   mobile data -> wifi

However, it doesn't work for the transition

   wifi -> mobile data

as there is no network disconnect sent by the system.

For that case the connectivityManager.isConnected() condition described above 
is used.

My new workaround is: wait some time (until the system sends the network 
disconnect---if it is disconnected) and then test if the system is connected 
and act upon it. I assumed 5 seconds because on my system the actual time is 
around 3 seconds, so I left 2 seconds margin.

This has the disadvantage that for 5 seconds after a connection is lost there 
won't be a reconnect---even if the network is available.  But I can live with 
that disadvantage.

Reconnection is working for all the cases described above.

A patch is attached.

Original comment by lotan...@gmx.de on 16 May 2013 at 10:58

Attachments:

• delay_reconnect.patch

[GoogleCodeExporter]

While the above patch works, the whole approach isn't robust.
In particular the fact that if a connection fails (for whatever reason), there 
won't be a reconnect thereafter.

I've now implemented and tested a more intrusive change that attempts a 
reconnect of all existing bridges whose host is set to "stay connected" 
regardless of whether the host had been connected right before. Because of 
that, the queue that is filled by bridges at the time of disconnection and that 
the terminal manager uses at the time of reconnection is not needed 
anymore---it was removed.

Original comment by lotan...@gmx.de on 4 Jun 2013 at 9:04

Attachments:

• more_robust_reconnection.patch