[tor-bugs] #1247 [Tor Client]: bootstrap hickups when network is down

[Tor Bug Tracker & Wiki]

#1247: bootstrap hickups when network is down
----------------------+-----------------------------------------------------
 Reporter:  anonym    |         Type:  defect    
   Status:  new       |     Priority:  major     
Milestone:            |    Component:  Tor Client
  Version:  0.2.1.22  |   Resolution:  None      
 Keywords:            |       Parent:            
----------------------+-----------------------------------------------------

Old description:

> In short, if the network is down when tor starts for the very first time
> the bootstrapping process might take a very long time (or never finish)
> even if the network is connected just shortly after tor starts and finds
> out that it's offline.
>
> This has been a major issue in live distributions like Incognito and
> amnesia
> for years becase:
>
> 1) they use a system-wide tor process that starts before xorg, and since
> they use NetworkManager, the network isn't up until they xorg has
> started.
> 2) they have an empty tor data directory, so they must bootstrap each
> time they start.
>
> That windows of 10-20 seconds or so of no network can make tor take
> anything from no time to hours to days to finally realise that the
> network is there and it can finish bootstrapping and start working. The
> time it takes seems extremely random, but usually it's done within 10
> minutes or so, but that's still very bad.
>
> The only thing that seems to speed this up is to restart tor when the
> network is up (which admittedly is quite easy to automate with something
> like if-up.d or NetworkManagers event dispatcher). When that is done,
> tor immediately bootstraps and is usable within 10 seconds.
>
> It would of course be preferable if tor could handle it cleanly and fast
> itself, or if it could be "prodded" somehow. For instance, I hoped
> sending tor a SIGHUP would make it re-try getting in touch with the
> directories, but it doesn't. Having an application use tor (so that it
> "optimistically will try to fetch a directory") doesn't help either. To
> me it seems that if tor is stuck with getting dir info, any external
> prodding to get it to do it again is ignored.
>
> I can easily reproduce this problem the following way:
>
> 1) start amnesia in virtualbox and let it get into an X session.
> 2) stop the tor process and disconnects the network.
> 3) clear the tor data directory and start tor.
> 4) wait one minute, then connect the network.
> 5) check the logs for how long it takes until tor bootstraps since
> the network was connected.
>
> I'll attach a debug level log of how this looks for me.
>
> My desired result woulb be that the time measured in step 5
> would be at most 10 seconds. Optimally tor should be able to detect
> that the network is up again completely on its own, but I'm
> equally happy if it could be "prodded" to check for the net again,
> like seding tor a SIGHUP, application request, control port command
> or anything that can be easily scripted.
>
> [Automatically added by flyspray2trac: Operating System: All]

New description:

 In short, if the network is down when tor starts for the very first time
 the bootstrapping process might take a very long time (or never finish)
 even if the network is connected just shortly after tor starts and finds
 out that it's offline.

 This has been a major issue in live distributions like Incognito and
 amnesia
 for years becase:

 1) they use a system-wide tor process that starts before xorg, and since
 they use NetworkManager, the network isn't up until they xorg has started.
 2) they have an empty tor data directory, so they must bootstrap each
 time they start.

 That windows of 10-20 seconds or so of no network can make tor take
 anything from no time to hours to days to finally realise that the
 network is there and it can finish bootstrapping and start working. The
 time it takes seems extremely random, but usually it's done within 10
 minutes or so, but that's still very bad.

 The only thing that seems to speed this up is to restart tor when the
 network is up (which admittedly is quite easy to automate with something
 like if-up.d or NetworkManagers event dispatcher). When that is done,
 tor immediately bootstraps and is usable within 10 seconds.

 It would of course be preferable if tor could handle it cleanly and fast
 itself, or if it could be "prodded" somehow. For instance, I hoped
 sending tor a SIGHUP would make it re-try getting in touch with the
 directories, but it doesn't. Having an application use tor (so that it
 "optimistically will try to fetch a directory") doesn't help either. To
 me it seems that if tor is stuck with getting dir info, any external
 prodding to get it to do it again is ignored.

 I can easily reproduce this problem the following way:

 1) start amnesia in virtualbox and let it get into an X session.
 2) stop the tor process and disconnects the network.
 3) clear the tor data directory and start tor.
 4) wait one minute, then connect the network.
 5) check the logs for how long it takes until tor bootstraps since
 the network was connected.

 I'll attach a debug level log of how this looks for me.

 My desired result woulb be that the time measured in step 5
 would be at most 10 seconds. Optimally tor should be able to detect
 that the network is up again completely on its own, but I'm
 equally happy if it could be "prodded" to check for the net again,
 like seding tor a SIGHUP, application request, control port command
 or anything that can be easily scripted.

 [Automatically added by flyspray2trac: Operating System: All]

--

Comment(by arma):

 Hm. It looks like we lost the debug.log here in the trac transition? :(

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