Opened 4 years ago

Last modified 2 years ago

#16120 new enhancement

Detect if the network goes down

Reported by: dgoulet Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: network, tor-guards-revamp, tor-client needs-design
Cc: yawning, n8fr8, asn, catalyst Actual Points:
Parent ID: Points: 6
Reviewer: Sponsor: SponsorU-can

Description

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: #8239, #12595

Child Tickets

Change History (23)

comment:1 Changed 4 years ago by 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?

comment:2 Changed 4 years ago by yawning

Cc: yawning added

comment:3 Changed 4 years ago by dgoulet

Keywords: TorCore201508 added

comment:4 in reply to:  1 Changed 4 years ago by teor

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:

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.

comment:5 Changed 4 years ago by nickm

Milestone: Tor: 0.2.7.x-finalTor: 0.2.8.x-final

comment:6 Changed 4 years ago by dgoulet

Keywords: network added; TorCore201508 removed

comment:7 Changed 4 years ago by torbacchi

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 #1136 is related too.

comment:8 Changed 4 years ago by nickm

Sponsor: SponsorU?

comment:9 Changed 4 years ago by dgoulet

Points: large
Sponsor: SponsorU?SponsorU SponsorR

comment:10 Changed 3 years ago by nickm

Milestone: Tor: 0.2.8.x-finalTor: 0.2.9.x-final

It is impossible that we will fix all 226 currently open 028 tickets before 028 releases. Time to move some out. This is my second pass through the "new" and tickets, looking for things to move to 0.2.9.

comment:11 Changed 3 years ago by isabela

Sponsor: SponsorU SponsorRSponsorU-can

comment:12 Changed 3 years ago by nickm

Keywords: tor-guards-revamp added
Severity: Normal

comment:13 Changed 3 years ago by isabela

Points: large6

comment:14 Changed 3 years ago by asn

Milestone: Tor: 0.2.9.x-finalTor: 0.2.???

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.

comment:15 Changed 3 years ago by 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?

comment:16 in reply to:  15 Changed 3 years ago by asn

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 DisableNetwork to 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 DisableNetwork does not do exactly what a hidden service should be doing when the network goes up and down. We should understand what DisableNetwork does, 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 (if DisableNetwork is inadequate).

comment:17 Changed 3 years ago by asn

Cc: n8fr8 added

comment:18 Changed 3 years ago by asn

Cc: asn added

comment:19 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:20 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:21 Changed 2 years ago by catalyst

Cc: catalyst added

comment:22 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:23 Changed 2 years ago by nickm

Keywords: tor-client needs-design added
Note: See TracTickets for help on using tickets.