Opened 5 years ago

Closed 4 years ago

#15358 closed enhancement (implemented)

Provide control port event+command for network connectivity info

Reported by: mikeperry Owned by: andrea
Priority: Medium Milestone: Tor: 0.2.7.x-final
Component: Core Tor/Tor Version: Tor: 0.2.7
Severity: Keywords: tor-client, tbb-wants, 027-triaged-1-in, SponsorS
Cc: brade, mcs Actual Points:
Parent ID: Points: small
Reviewer: Sponsor:

Description

For #11222, it would be useful to have a control port event and GETINFO command to learn Tor's current opinion about overall network connectivity, so we can try to differentiate censorship from general network outage.

One potential source of this network liveness info is via circuit_build_times_network_is_live() and circuit_build_times_network_close(). There may be other pieces of Tor that try to decide if the network is up too, though. I seem to recall athena working on some piece of code that needed to do this, but I can't remember the ticket.

Alternatively, there may be more accurate platform-specific mechanisms we could use instead, I bet. Most OSes have a notion of if it's interfaces are connected and sending/receiving packets recently. OS info may prove more useful for this use case than the CBT code is.

Child Tickets

Attachments (1)

tor-control-spec-patch-for-ticket15358.diff (1.1 KB) - added by andrea 4 years ago.
Patch to control-spec.txt for these control protocol changes

Download all attachments as: .zip

Change History (12)

comment:1 Changed 5 years ago by nickm

Milestone: Tor: 0.2.7.x-final

comment:2 Changed 5 years ago by mikeperry

Milestone: Tor: 0.2.7.x-final

Actually, the OS-specific mechanisms probably belong in Firefox. In fact, there was at one point already be code in Firefox to detect if your network interfaces are currently up, though it may have been ripped out by now - https://bugzilla.mozilla.org/show_bug.cgi?id=620472.

It still would be useful to have some info from Tor if Tor has seen any network activity recently, though.

comment:3 Changed 5 years ago by mikeperry

Milestone: Tor: 0.2.7.x-final

I didn't mean to delete the milestone. Not sure how that happened.

comment:4 Changed 5 years ago by mcs

Cc: brade mcs added

comment:5 Changed 5 years ago by nickm

Status: newassigned

comment:6 Changed 5 years ago by mikeperry

Keywords: tbb-wants added; tbb-needs removed

comment:7 Changed 5 years ago by andrea

Owner: set to andrea

comment:8 Changed 5 years ago by nickm

Keywords: 027-triaged-1-in added

Marking more tickets as triaged-in for 0.2.7

comment:9 Changed 5 years ago by isabela

Keywords: SponsorS added
Points: small
Version: Tor: 0.2.7

comment:10 Changed 4 years ago by andrea

This will be in my ticket15358_squashed_2 branch once git pushes work again. A corresponding patch for the spec will be attached to this ticket.

This turned out to be tricky to test because we don't seem to reliably detect network liveness under low-traffic conditions. Experimenting with the effect of cutting off network connectivity on an idle Tor process for testing did not reliably trigger the network down case in circuit_build_times_network_close() when a new circuit build attept that was the only activity at the time failed, even though a Tor process with a steady level of background activity (being used by bitcoind, specifically) did reproducibly detect network deadness within a few minutes. I should investigate this further.

Changed 4 years ago by andrea

Patch to control-spec.txt for these control protocol changes

comment:11 Changed 4 years ago by nickm

Resolution: implemented
Status: assignedclosed

Merged; thanks!

Note: See TracTickets for help on using tickets.