[tor-bugs] #2355 [Tor Client]: change the meaning of UseBridges

[Tor Bug Tracker & Wiki]

#2355: change the meaning of UseBridges
-------------------------------------+--------------------------------------
        Reporter:  anonym            |         Type:  enhancement
          Status:  needs_review      |     Priority:  minor      
       Milestone:  Tor: unspecified  |    Component:  Tor Client 
         Version:                    |     Keywords:             
          Parent:                    |       Points:             
Actualpointsdone:                    |   Pointsdone:             
    Actualpoints:                    |  
-------------------------------------+--------------------------------------

Comment(by anonym):

 I had a bit of time to look at this once more and I found a minor issue
 that I fixed, so new patch.

 The bug was: if Tor starts with a few bridges configured in torrc, these
 are ignored until the options are updated (i.e. they we're only added if
 there was an old_config).

 Replying to [comment:5 anonym]:
 > 2) When bridge switching (i.e. repeatedly changing bridges by removing
 the old ones and adding new ones) Vidalia starts to list one "<Path Empty>
 New" entry in the connection list for every abandoned bridge, or something
 like that.

 I've done some debugging and it's quite clear that these spurious entries
 are due to connections started with
 launch_direct_bridge_descriptor_fetch() -- when the decriptor has been
 fetched, I believe the connection _is_ closed by Tor, but Vidalia never
 learns about that happening, so these entries remain. This also happens
 when adding a bridge in vanilla Tor, so it's not introduced by my patch.
 The issue does, however, become more apparent with my patch since more
 direct bridge fetches are done.

 > 3) And here's the big one: when doing frequent bridge switching it can
 occasionally happen that bootstrapping to a known working bridge fails.

 Just to be clear, if this problem occurs we can just remove the bridge
 through Vidalia and then re-add it and then its descriptor will be fetched
 (I guess the probability that it will fail is about the same as in any
 other situation, but I've never got two of these bridge fetch stalls in a
 row). Similarly, if we remove the failed bridge and add another known
 working bridge, the descriptor will be fetched (again, presumably with the
 same fail probability).

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/2355#comment:7>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online