[tor-bugs] #960 [Tor Client]: Tor believes bridges are offline at startup

Tor Bug Tracker & Wiki torproject-admin at torproject.org
Fri Nov 12 02:12:57 UTC 2010


#960: Tor believes bridges are offline at startup
--------------------------------+-------------------------------------------
 Reporter:  phobos              |         Type:  defect    
   Status:  new                 |     Priority:  minor     
Milestone:  Tor: 0.2.3.x-final  |    Component:  Tor Client
  Version:  0.2.1.13-alpha      |   Resolution:  None      
 Keywords:                      |       Parent:            
--------------------------------+-------------------------------------------
Changes (by nickm):

  * milestone:  => Tor: 0.2.3.x-final


Old description:

> [07:42:32] <  phobos> [Info] should_delay_dir_fetches(): delaying dir
> fetches (no running bridges known)
> [07:42:34] <  phobos> lies
> [07:43:17] <  phobos> it's been doing this for 10 minutes
> [07:43:29] <  phobos> yet I can connect to the bridges just fine
> [07:45:56] <  killerchicken_> heh
> [07:46:09] <  killerchicken_> if we could debug this, that would solve a
> lot of problem reports we had
> [07:46:59] <  phobos> forcing an app request through it makes it try
> [07:47:03] <  phobos> and succeed
> [07:48:27] <  killerchicken_> ah
> [07:48:28] <  killerchicken_>  * are marked with purpose 'bridge' and are
> running. Else return 0.
> [07:48:37] <  killerchicken_> ups
> [07:48:40] <  killerchicken_> ./** Return 1 if any of our entry guards
> have descriptors that
> [07:51:30] <  killerchicken_> hm
> [07:52:35] <  killerchicken_> I'd love to debug this more, but it has to
> wait... Have you made a bug report?
> [07:53:04] <  phobos> on my to do list
> [07:53:22] <  killerchicken_> ok
> [07:55:10] <  killerchicken_> I think the problem is inside the
> any_bridge_descriptors_known() / choose_random_entry() logic
> [07:55:37] <  killerchicken_> I'll look at it more if nobody else finds
> the time. Can you please add this stuff from here to the bug?
>
> Log file says:
> ar 27 07:42:12.269 [Info] should_delay_dir_fetches(): delaying dir
> fetches (no running bridges known)
> Mar 27 07:42:23.309 [Info] should_delay_dir_fetches(): delaying dir
> fetches (no running bridges known)
> Mar 27 07:42:28.329 [Info] routerlist_remove_old_routers(): We have 1203
> live routers and 0 old router descriptors.
> Mar 27 07:42:28.334 [Info] should_delay_dir_fetches(): delaying dir
> fetches (no running bridges known)
> Mar 27 07:42:34.348 [Info] should_delay_dir_fetches(): delaying dir
> fetches (no running bridges known)
> Mar 27 07:42:45.388 [Info] should_delay_dir_fetches(): delaying dir
> fetches (no running bridges known)
> Mar 27 07:42:56.420 [Info] should_delay_dir_fetches(): delaying dir
> fetches (no running bridges known)
> Mar 27 07:43:07.461 [Info] should_delay_dir_fetches(): delaying dir
> fetches (no running bridges known)
> Mar 27 07:43:18.500 [Info] should_delay_dir_fetches(): delaying dir
> fetches (no running bridges known)
> Mar 27 07:43:29.541 [Info] should_delay_dir_fetches(): delaying dir
> fetches (no running bridges known)
>
> forcing an app request through tor creates:
> Mar 27 07:46:14.173 [Info] should_delay_dir_fetches(): delaying dir
> fetches (no running bridges known)
> Mar 27 07:46:16.197 [Notice] Application request when we're believed to
> be offline. Optimistically trying known bridges again.
> Mar 27 07:46:16.210 [Info] connection_edge_process_inbuf(): data from
> edge while in 'waiting for circuit' state. Leaving it on buffer.
> Mar 27 07:46:25.220 [Info]
> update_consensus_router_descriptor_downloads(): 3 router descriptors
> downloadable. 0 delayed; 1201 present (0 of those were in old_routers); 0
> would_reject; 0 wouldnt_use; 0 in progress.
> Mar 27 07:46:25.233 [Info] launch_router_descriptor_downloads(): There
> are not many downloadable routerdescs, but we haven't tried downloading
> descriptors recently. Downloading.
> Mar 27 07:46:25.248 [Info] launch_router_descriptor_downloads():
> Launching 1 request for 3 routers, 4 at a time
>
> [Automatically added by flyspray2trac: Operating System: Other Linux]

New description:

 [07:42:32] <  phobos> [Info] should_delay_dir_fetches(): delaying dir
 fetches (no running bridges known)
 [07:42:34] <  phobos> lies
 [07:43:17] <  phobos> it's been doing this for 10 minutes
 [07:43:29] <  phobos> yet I can connect to the bridges just fine
 [07:45:56] <  killerchicken_> heh
 [07:46:09] <  killerchicken_> if we could debug this, that would solve a
 lot of problem reports we had
 [07:46:59] <  phobos> forcing an app request through it makes it try
 [07:47:03] <  phobos> and succeed
 [07:48:27] <  killerchicken_> ah
 [07:48:28] <  killerchicken_>  * are marked with purpose 'bridge' and are
 running. Else return 0.
 [07:48:37] <  killerchicken_> ups
 [07:48:40] <  killerchicken_> ./** Return 1 if any of our entry guards
 have descriptors that
 [07:51:30] <  killerchicken_> hm
 [07:52:35] <  killerchicken_> I'd love to debug this more, but it has to
 wait... Have you made a bug report?
 [07:53:04] <  phobos> on my to do list
 [07:53:22] <  killerchicken_> ok
 [07:55:10] <  killerchicken_> I think the problem is inside the
 any_bridge_descriptors_known() / choose_random_entry() logic
 [07:55:37] <  killerchicken_> I'll look at it more if nobody else finds
 the time. Can you please add this stuff from here to the bug?

 Log file says:
 ar 27 07:42:12.269 [Info] should_delay_dir_fetches(): delaying dir fetches
 (no running bridges known)
 Mar 27 07:42:23.309 [Info] should_delay_dir_fetches(): delaying dir
 fetches (no running bridges known)
 Mar 27 07:42:28.329 [Info] routerlist_remove_old_routers(): We have 1203
 live routers and 0 old router descriptors.
 Mar 27 07:42:28.334 [Info] should_delay_dir_fetches(): delaying dir
 fetches (no running bridges known)
 Mar 27 07:42:34.348 [Info] should_delay_dir_fetches(): delaying dir
 fetches (no running bridges known)
 Mar 27 07:42:45.388 [Info] should_delay_dir_fetches(): delaying dir
 fetches (no running bridges known)
 Mar 27 07:42:56.420 [Info] should_delay_dir_fetches(): delaying dir
 fetches (no running bridges known)
 Mar 27 07:43:07.461 [Info] should_delay_dir_fetches(): delaying dir
 fetches (no running bridges known)
 Mar 27 07:43:18.500 [Info] should_delay_dir_fetches(): delaying dir
 fetches (no running bridges known)
 Mar 27 07:43:29.541 [Info] should_delay_dir_fetches(): delaying dir
 fetches (no running bridges known)

 forcing an app request through tor creates:
 Mar 27 07:46:14.173 [Info] should_delay_dir_fetches(): delaying dir
 fetches (no running bridges known)
 Mar 27 07:46:16.197 [Notice] Application request when we're believed to be
 offline. Optimistically trying known bridges again.
 Mar 27 07:46:16.210 [Info] connection_edge_process_inbuf(): data from edge
 while in 'waiting for circuit' state. Leaving it on buffer.
 Mar 27 07:46:25.220 [Info] update_consensus_router_descriptor_downloads():
 3 router descriptors downloadable. 0 delayed; 1201 present (0 of those
 were in old_routers); 0 would_reject; 0 wouldnt_use; 0 in progress.
 Mar 27 07:46:25.233 [Info] launch_router_descriptor_downloads(): There are
 not many downloadable routerdescs, but we haven't tried downloading
 descriptors recently. Downloading.
 Mar 27 07:46:25.248 [Info] launch_router_descriptor_downloads(): Launching
 1 request for 3 routers, 4 at a time

 [Automatically added by flyspray2trac: Operating System: Other Linux]

--

Comment:

 There are some other problems if Tor comes up before your network does
 AFAICR.  If we fix that well, we may fix this too.

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


More information about the tor-bugs mailing list