[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:  new               |     Priority:  minor      
       Milestone:  Tor: unspecified  |    Component:  Tor Client 
         Version:                    |     Keywords:             
          Parent:                    |       Points:             
Actualpointsdone:                    |   Pointsdone:             
    Actualpoints:                    |  
-------------------------------------+--------------------------------------

Comment(by anonym):

 New patch.

 Now bridge descriptors are (re)fetched as soon as the list of bridges are
 changed. Additionally, since there are constraints on how you can combine
 UseBridges with some other options, the following seemed like reasonable
 to me:

 1) TunnelDirConns set to 0 only works with UseBridges set to 0

 2) If we run a server, we can't have UseBridges set to 1, as before. With
 UseBridges set to auto (which is the default value), bridges will not be
 used, just like if we had UseBridges set to 0.

 There are a couple of issues with my patch:

 1) There are two (related) "FIXME" items detailing one issue -- see the
 patch.

 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. This seems to be more of an issue in Vidalia, though. I've
 check with netstat, though, and it seems like one connections per old
 bridge stays for some time before they die (perhaps the one used for
 directory fetches?), but I don't know how to kill those connections.

 3) And here's the big one: when doing frequent bridge switching it can
 occasionally happen that bootstrapping to a known working bridge fails. It
 will eventually be fetched by the scheduled fetches, but then we won't
 fetch its descriptor before download_status_is_ready() thinks it's ok,
 which seems to be 10+ minutes.

 I've managed to reproduce it a couple of times, but I can see no pattern.
 So, given this seemingly random nature of the problem, my only guess is
 that there's some sort of race condition or other type of collision
 affecting the call I added to fetch_bridge_descriptors() in options_act(),
 config.c:1457. I have observed two things which somewhat convince me of
 this:

 3.1) This seems to happen more often when I have loglevel notice than
 info. Hence the (admittedly very small) times required to output stuff
 seems to affect this.

 3.2) If I put that call earlier in options_act() (I've tried several
 places) it fails every time.

 Instead of calling fetch_bridge_descriptors(), another approach would be
 to do a download_status_reset() on each bridge and then let
 run_scheduled_events() (main.c:856) call fetch_bridge_descriptors() for
 us, but that isn't as instantaneous (up to 10 seconds delay).

 Any ideas?

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