Opened 7 years ago

Last modified 4 months ago

#5483 new enhancement

managed pluggable transports should be able to pause Tor's circuit-building?

Reported by: arma Owned by:
Priority: Medium Milestone:
Component: Circumvention/Pluggable transport Version:
Severity: Normal Keywords: needs-tor-change needs-spec-change
Cc: iang, hmohajer@…, dmr Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Hooman with his Skypemorph transport (http://archives.seul.org/tor/dev/Mar-2012/msg00093.html) notes that when Tor first starts, and starts his transport, it takes his transport a minute or two to become ready. During that time, Tor tries to start a circuit to his configured bridges, times out the circuit, and marks his bridges down.

He can work around the problem in his experiments by starting Tor with "DisableNetwork 1" in the torrc, and when he's ready, remove the line and hup tor. That's not a good solution for real users though.

The problem would be less pronounced for him if Tor had better handling of when to mark a bridge down. There are a variety of tickets about that. But I think those issues are different from this ticket.

Perhaps the various proposals we've been writing recently have some opportunity to fit this in? Which ones are the best ones to look at?

Child Tickets

Change History (12)

comment:1 Changed 7 years ago by iang

Cc: iang added

comment:2 Changed 7 years ago by hmohajer

Cc: hmohajer@… added

comment:3 Changed 7 years ago by asn

If you use pluggable transport proxy managed mode, you should be able to avoid this problem, by sending your CMETHOD lines only after your transport has fully bootstrapped.

If you use external mode, things are harder. You will probably have to wait till TransportControlPort is implemented [0]. Then we will have to extend TransportControlPort to allow client transport proxies to connect to it (since it's designed only for server proxies at the moment). Then we will have to add a new command to TransportControlPort that does something like DisableNetwork, or allows better handling on when to connect to an obfuscated bridge. We will also need to extend the 196 proposal, to make sure that Tor does not send traffic to the network before the TransportControlPort protocol is finished.

All in all, the external-mode solution is not going to happen immediately, but it's one of the things that must happen before we call our pluggable transports stack actually robust. Any help on implementing TransportControlPort is more than welcome (#5408) :)

[0]: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/196-transport-control-ports.txt

comment:4 Changed 6 years ago by arma

See #7153 where we're discussing alternate approaches here. It looks like Flashproxy has a quite similar issue.

comment:5 Changed 6 years ago by dcf

If I understand the issue correctly, this is the same thing that causes us to put

LearnCircuitBuildTimeout 0
CircuitBuildTimeout 60

in the flash proxy torrc. https://gitweb.torproject.org/flashproxy.git/blob/HEAD:/torrc

comment:6 Changed 6 years ago by arma

fyi, I've been using

diff --git a/src/or/entrynodes.c b/src/or/entrynodes.c
index 5d356b6..7ccd6f2 100644
--- a/src/or/entrynodes.c
+++ b/src/or/entrynodes.c
@@ -681,7 +681,7 @@ entry_guard_register_connect_status(const char *digest, int

   /* if the caller asked us to, also update the is_running flags for this
    * relay */
-  if (mark_relay_status)
+  if (mark_relay_status && succeeded)
     router_set_status(digest, succeeded);

   if (first_contact) {

to stop Tor from marking my bridge down, when I know my bridge is up. Not fully tested, but putting the patch here so I don't lose it.

comment:7 Changed 5 years ago by asn

Keywords: needs-tor-change needs-spec-change added

comment:8 Changed 4 years ago by yawning

Parent ID: #16755

comment:9 Changed 21 months ago by yawning

Parent ID: #16755
Severity: Normal

comment:10 Changed 10 months ago by dmr

Cc: dmr added

comment:11 Changed 4 months ago by teor

Owner: asn deleted
Status: newassigned

asn does not need to own any obfuscation tickets any more. Default owners are trouble.

comment:12 Changed 4 months ago by cohosh

Status: assignednew

tickets were assigned to asn, setting them as unassigned (new) again.

Note: See TracTickets for help on using tickets.