Opened 8 years ago

Closed 8 years ago

Last modified 7 years ago

#3644 closed enhancement (implemented)

Config option to tell Tor whether it can use the network

Reported by: arma Owned by:
Priority: Low Milestone: Tor: 0.2.3.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: tor-client
Cc: n8fr8, anonym, mikeperry Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Motivation 1: Tails wants to start Tor at boot, but have it not touch the network until the user has decided (e.g. via Vidalia) whether to use bridges.

Motivation 2: Tor-on-Android drains its battery when Tor tries to make circuits over and over. Sometimes there is no network, and Tor continues to try to make circuits. Orbot is able to learn whether there is a network, so it could tell Tor whether to avoid draining its battery.

We should add a config option so controllers can tell Tor when the network is gone/present, and Tor should stop doing network stuff in the 'gone' state. Another way of looking at this is an "airplane mode" for Tor.

I'm putting as an 0.2.3 milestone so I don't have to put it in 'unspecified'. I hope somebody will step up and volunteer it; but it can slip if not.

See also #2355 and #2905 for related (albeit confusing) tickets.

Child Tickets

Attachments (1)

xxx-no-public-network.txt (3.6 KB) - added by mikeperry 8 years ago.
Solution outline

Download all attachments as: .zip

Change History (11)

comment:1 Changed 8 years ago by nickm

#3420 is probably relevant, and one solution may well solve both.

comment:2 Changed 8 years ago by mikeperry

We have a solution outline that covers all four use cases (TBB, Tails, Orbot, and Relay bundles). Here is the relevant excerpt for tor:

  • Tor implements DisableNetwork config var
    • The variable will prevent all non-control port activity while on
      • DisableNetwork can also disable remote control ports, too, if that simplifies implementation. Our 4 use cases don't care about remote controllers
    • It must be toggleable via SETCONF

Changed 8 years ago by mikeperry

Attachment: xxx-no-public-network.txt added

Solution outline

comment:3 Changed 8 years ago by nickm

Okay, and this is for 0.2.3.x in Tor? Probably doable if so.

Is it specified what should happen to existing non-control connections if DisableNetwork is changed from 0 to 1?

comment:4 in reply to:  3 Changed 8 years ago by arma

Replying to nickm:

Is it specified what should happen to existing non-control connections if DisableNetwork is changed from 0 to 1?

The only use case for setting DisableNetwork when there are existing connections is Orbot, which will set it when it believes its network is off (so Tor will quit trying to do stuff that drains the battery).

So I'd say the right behavior is to treat it as a hint that all of those connections are broken and you don't know it yet. I.e., close them.

It's possible that once we deploy it we'll realize that what we actually wanted to do was stop touching the connections but not explicitly close them, in case the tcp flows still work when the network comes back. But if we turn out to want that, we can call it a new feature request then.

comment:5 Changed 8 years ago by arma

Cc: mikeperry added

comment:6 Changed 8 years ago by mikeperry

Yeah, in terms of keeping connections open vs closing, I would go with whatever is easiest to implement for now, so long as network and related CPU activity ceases. I think most cell phones get a new IP when they lose data connectivity anyway.

comment:7 Changed 8 years ago by nickm

Status: newneeds_review

Please review branch "disable_network" in my public repository.

comment:8 Changed 8 years ago by nickm

Resolution: implemented
Status: needs_reviewclosed

This still passes my tests, and it looks okay on my second read-through. Merging it.

comment:9 Changed 7 years ago by nickm

Keywords: tor-client added

comment:10 Changed 7 years ago by nickm

Component: Tor ClientTor
Note: See TracTickets for help on using tickets.