Re: [tor-bugs] #11301 [Tor]: Tor does not reconnect after network loss with bridges

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#11301: Tor does not reconnect after network loss with bridges
-------------------------+-------------------------------------------------
     Reporter:           |      Owner:  nickm
  mikeperry              |     Status:  new
         Type:  defect   |  Milestone:  Tor: 0.2.5.x-final
     Priority:  major    |    Version:
    Component:  Tor      |   Keywords:  tor-client, tbb-usability, tbb-
   Resolution:           |  needs, 025-triaged, flashproxy, 025-deferrable
Actual Points:           |  Parent ID:
       Points:           |
-------------------------+-------------------------------------------------

Comment (by yawning):

 Replying to [comment:12 arma]:
 > I think this is the same as #3259 ?

 From what I've seen, that's a plausible explanation.

 From IRC discussion:

 {{{
 armadev | it's easy to trigger. just do any of the things that
         | causes tor to mark the relay as not running. then tor
         | won't try to connect to it.

 armadev | a fix might be to mark all your bridges up if you have
         | bridges, they're all down, and you get a new stream
         | request

 armadev | another fix might be to not mark your last bridge as
         | down unless you really mean it
 armadev | i like that one more

 armadev | but we also want to stop tor from thrashing if its
         | network is actually down (meaning all its bridges
         | really are unreachable)

 armadev | i think we'd make some good progress if we
         | distinguished "there was a network error attempting to
         | establish the tcp connection" from "i gave up on the
         | circuit because it had been a while, but i did have a
         | tcp connection"
 }}}

 #3259 is the non-pt case, but recent discussion has been centered around
 PTs, and arma notes that there is probably a lot of overlap.

 For every PT apart from meek (and possibly flashproxy), if
 `conn->proxy_state != PROXY_OK` would be sufficient to establish if the
 upstream connection was established.  A few of pt implementations also
 will send back appropriate SOCKSv5 error codes (Host Unreachable/Network
 Unreachable) but the tor side only uses that information for logging
 currently.

 meek loses out here because it blindly sends back a SOCKSv4 success
 response right after receiving the request.

 Dunno.  Maybe I'm overthinking things.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/11301#comment:13>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs