Detect if the network goes down
Implement a way for tor to detect if the network went down. This has multiple use cases (see list of tickets), one for instance is being able to differenciate between "We couldn't connect to a Guard because the Guard is down" vs "We couldn't connect because the network is down". For a more thorough discussion about Guard and network connectivity: https://lists.torproject.org/pipermail/tor-dev/2014-August/007346.html
Furthermore, this also makes a difference when we want to either keep a circuit or kill it depending on if the network went down or not.
We can get this kind of information from the OS, we need an API generic enough that allows us to build a compat layer for each OS. Let's also make sure it's integrated with the latest control command GETINFO network-liveness and the event NETWORK_LIVENESS.
Tickets that could benefit from this: legacy/trac#8239 (moved), legacy/trac#12595 (moved)
Activity
changed milestone to %Tor: unspecified in legacy/trac
added component::core tor/tor in Legacy / Trac milestone::Tor: unspecified in Legacy / Trac needs-design in Legacy / Trac network in Legacy / Trac points::6 in Legacy / Trac priority::medium in Legacy / Trac severity::normal in Legacy / Trac sponsor::U-can in Legacy / Trac status::new in Legacy / Trac tor-client in Legacy / Trac tor-guards-revamp in Legacy / Trac type::enhancement in Legacy / Trac labels
Is this the right layer for solving the problem? How many people actually have their network interface go away, vs just go out of range of the wireless access point?
I've always thought that the right approach here was to distinguish "I seem to not be able to reach anything" from "I can reach some things but not others", which is tricky to begin with, and extra tricky when you consider the time component (if you can't reach anything for a while, but then you do reach something, you cannot learn just from that which situation you were in).
Or to turn it around, if you build the OS-specific code to check if the network interface goes away, is it now any less necessary to solve the problems I raise above?
Replying to arma:
Is this the right layer for solving the problem? How many people actually have their network interface go away, vs just go out of range of the wireless access point?
I've always thought that the right approach here was to distinguish "I seem to not be able to reach anything" from "I can reach some things but not others", which is tricky to begin with, and extra tricky when you consider the time component (if you can't reach anything for a while, but then you do reach something, you cannot learn just from that which situation you were in).
Or to turn it around, if you build the OS-specific code to check if the network interface goes away, is it now any less necessary to solve the problems I raise above?
For example, OS X distinguishes two cases:
- an individual host is "reachable" (there's an entire API for it, see https://developer.apple.com/library/mac/documentation/SystemConfiguration/Reference/SCNetworkReachabilityRef/ )
- an interface appears or disappears
If there are no interfaces apart from localhost, we obviously can't get out. But if there are external interfaces, should we assume that if a certain set of well-known servers can't be reached, the entire network is down (or, we are under attack)? This is a common strategy, but it adds a dependency on external servers for proper behaviour.
Fixing this would really improve TBB usability: often the network may become unreachable for some time (lost connection to the local wi-fi, or the ISP uplink goes down for a while), but when it comes up again, TBB is having lots of trouble connecting to any site: sometimes it takes 2-3 extra minutes, but most of the times I have to restart it (losing my session) :(
BTW, maybe legacy/trac#1136 (moved) is related too.
Trac:
Username: torbacchi
There are currently no plans to do this, since we still don't know how to do it in a cross-platform manner.
Platform-specific approaches might be worth considering, but they would require a proposal and everything.
Pushing this out of 0.2.9 for now.
Trac:
Milestone: Tor: 0.2.9.x-final to Tor: 0.2.???-
I understand that it's hard to do this in a cross-platform manner but I think it would be good if an application running on a specific platform could inform Tor about network events. For example I had the idea to monitor android.net.conn.CONNECTIVITY_CHANGE on Android and set DisableNetwork if the network is down. But I'm not sure if DisableNetwork is suitable here. Maybe a new control command would be more appropriate?
Trac:
Username: timonh -
Replying to timonh:
I understand that it's hard to do this in a cross-platform manner but I think it would be good if an application running on a specific platform could inform Tor about network events. For example I had the idea to monitor android.net.conn.CONNECTIVITY_CHANGE on Android and set DisableNetwork if the network is down. But I'm not sure if DisableNetwork is suitable here. Maybe a new control command would be more appropriate?
Hello,
as we discussed on IRC the other day, I find this approach (of the application notifying Tor of network down events) plausible for now. In the future, if we find techniques to discover network down events in a clean manner in various OSes, we could potentially bake these into Tor (as suggested by this thread), but until then I think experimenting on the application-layer will be cleaner and faster.
FWIW, I have the impression that Orbot is also doing tricks with
DisableNetworkto stop Tor from going mental when the network is down. Check this function for example.Maybe you can try doing the same thing in your application, and then let us know how it works for you? It might be the case that toggling
DisableNetworkdoes not do exactly what a hidden service should be doing when the network goes up and down. We should understand whatDisableNetworkdoes, and what we would ideally like it to do in this case, and if we figure this out we potentially make a control port command or something that implements the precise functionalitity we are looking for (ifDisableNetworkis inadequate).
