[tor-bugs] #23347 [Core Tor/Tor]: Using bridges is not working anymore with tor on master

[Tor Bug Tracker & Wiki]

#23347: Using bridges is not working anymore with tor on master
----------------------------------------------+----------------------------
 Reporter:  gk                                |          Owner:  teor
     Type:  defect                            |         Status:
                                              |  needs_revision
 Priority:  Very High                         |      Milestone:  Tor:
                                              |  0.3.2.x-final
Component:  Core Tor/Tor                      |        Version:
 Severity:  Normal                            |     Resolution:
 Keywords:  tor-bootstrap, tor-bridge-client  |  Actual Points:  0.5
Parent ID:                                    |         Points:  0.5
 Reviewer:  isis                              |        Sponsor:
----------------------------------------------+----------------------------
Changes (by teor):

 * status:  merge_ready => needs_revision


Comment:

 Replying to [comment:13 nickm]:
 > I'm wondering whether we shouldn't extract the magic pair of calls to
 download_status_implement() and turn them into some other "adjust bridge
 download schedule" function?  Or use two separate schedules?

 I think we should use two separate schedules, like we do for bootstrapping
 consensuses and regular consensuses. This makes the different behavior
 explicit, rather than relying on magic numbers.

 It also allows us to have more fine-grained control over how often we
 retry missing bridge descriptors.

 We could use schedules that match the old behaviour:
 {{{
 TestingMissingBridgeDownloadSchedule 0, 1200, 900, 900, 3600
 TestingBridgeDownloadSchedule 1200, 900, 900, 3600
 /* And in a test network */
 TestingMissingBridgeDownloadSchedule 0, 60, 30, 30, 60
 TestingBridgeDownloadSchedule 60, 30, 30, 60
 }}}

 But we probably want something more like this:
 {{{
 /* If we can't get a bridge descriptor, backoff exponentially, just like
 authority consensus downloads */
 TestingMissingBridgeDownloadSchedule 0, 3, 7, 3600, 10800, 25200, 54000,
 111600, 262800
 /* If the bridge keeps giving us a valid descriptor, it's ok to keep
 asking for one every 6 hours (this gives a bridge client 4 attempts per
 day to refresh each bridge descriptor) */
 TestingBridgeDownloadSchedule 21600, 21600
 /* And in a test network, match authority consensus downloads */
 TestingMissingBridgeDownloadSchedule 0, 0, 5, 10, 15, 20, 30, 60
 TestingBridgeDownloadSchedule 30, 30
 }}}

 Is there any reason that a bridge client with a valid bridge descriptor
 should re-download it every hour?

 I'm happy to make this change, but it will probably be towards the end of
 the week. Feel free to grab this ticket if you want to do it before then.

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