[tor-bugs] #1138 [Tor - Tor client]: If bridge authority is unreachable, client doesn't fallback to bridge

[Tor Bug Tracker & Wiki]

#1138: If bridge authority is unreachable, client doesn't fallback to bridge
--------------------------------+-------------------------------------------
 Reporter:  arma                |         Type:  defect          
   Status:  new                 |     Priority:  major           
Milestone:  Tor: 0.2.2.x-final  |    Component:  Tor - Tor client
  Version:  0.2.1.19            |   Resolution:  None            
 Keywords:  easy                |       Parent:                  
--------------------------------+-------------------------------------------
Changes (by nickm):

  * keywords:  => easy


Old description:

> When a Tor client starts up using a bridge, and
> UpdateBridgesFromAuthority is
> set (which it is when Vidalia configures you to use a bridge), Tor will
> go to
> the authority first and look up the bridge by fingerprint.
>
> If the bridge authority doesn't have the bridge, or Tor doesn't know the
> fingerprint, then Tor will fall back to asking the bridge directly.
>
> If the bridge authority is filtered, though, then Tor will never notice
> that
> the bridge authority lookup failed. So it will never fall back. Fail.
>
> Our workaround for now is to stop giving out fingerprints via bridgedb.
>
> [Automatically added by flyspray2trac: Operating System: All]

New description:

 When a Tor client starts up using a bridge, and UpdateBridgesFromAuthority
 is
 set (which it is when Vidalia configures you to use a bridge), Tor will go
 to
 the authority first and look up the bridge by fingerprint.

 If the bridge authority doesn't have the bridge, or Tor doesn't know the
 fingerprint, then Tor will fall back to asking the bridge directly.

 If the bridge authority is filtered, though, then Tor will never notice
 that
 the bridge authority lookup failed. So it will never fall back. Fail.

 Our workaround for now is to stop giving out fingerprints via bridgedb.

 [Automatically added by flyspray2trac: Operating System: All]

--

Comment:

 The current retry code in question [that is, the code that isn't getting
 called when the bridge authority is filtered] is the part at the start of
 dir_routerdesc_download_failed() that eventually calls  {{{
 retry_bridge_descriptor_fetch_directly();  So all we need to do is make
 sure that this retry code also happens when the request to the bridge
 authority fails because it was filtered.

 Two possible places to notice that it was filtered are at
 connection_dir_reached_eof() [if the filter closes the connection to the
 authority], or in main.c as we time out connections [if the filter just
 drops packets to the bridge authority.]

 Alternatively, we could change fetch_bridge_descriptors() so that if a
 bridge descriptor download has failed a few times, we retry directly.  For
 that, you'd want to track the number of failed downloads from the bridge
 authority in about the same places you currently mess with
 bridge->download_status.

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