Re: [tor-bugs] #20499 [Core Tor/Tor]: A running Tor won't update the microdesc consensus

[Tor Bug Tracker & Wiki]

#20499: A running Tor won't update the microdesc consensus
---+---
 Reporter:  rubiate|  Owner:  nickm
 Type:  defect | Status:  closed
 Priority:  High   |  Milestone:  Tor:
   |  0.2.9.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.2.9.4-alpha
 Severity:  Normal | Resolution:  fixed
 Keywords:  regression, CoreTorTeam201611  |  Actual Points:
Parent ID:  #20534 | Points:
 Reviewer: |Sponsor:
---+---
Changes (by teor):

 * status:  accepted => closed
 * resolution:   => fixed
 * parent:   => #20534


Comment:

 Fixed, reparenting to #20534 for documentation

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20499 [Core Tor/Tor]: A running Tor won't update the microdesc consensus

[Tor Bug Tracker & Wiki]

#20499: A running Tor won't update the microdesc consensus
---+---
 Reporter:  rubiate|  Owner:  nickm
 Type:  defect | Status:  accepted
 Priority:  High   |  Milestone:  Tor:
   |  0.2.9.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.2.9.4-alpha
 Severity:  Normal | Resolution:
 Keywords:  regression, CoreTorTeam201611  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by nickm):

 Okay.  We've merged a fairly large passel of fixes to try to address this.
 It is reasonably likely that we will need more finetuning, so this will be
 one of the things that makes 0.2.9.5-alpha an alpha release.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20499 [Core Tor/Tor]: A running Tor won't update the microdesc consensus

[Tor Bug Tracker & Wiki]

#20499: A running Tor won't update the microdesc consensus
---+---
 Reporter:  rubiate|  Owner:  nickm
 Type:  defect | Status:  accepted
 Priority:  High   |  Milestone:  Tor:
   |  0.2.9.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.2.9.4-alpha
 Severity:  Normal | Resolution:
 Keywords:  regression, CoreTorTeam201611  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by teor):

 I have sketched out some minor tweaks to the exponential backoff
 parameters in #20534. This makes the download timings much more like
 0.2.8.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20499 [Core Tor/Tor]: A running Tor won't update the microdesc consensus

[Tor Bug Tracker & Wiki]

#20499: A running Tor won't update the microdesc consensus
---+---
 Reporter:  rubiate|  Owner:  nickm
 Type:  defect | Status:  accepted
 Priority:  High   |  Milestone:  Tor:
   |  0.2.9.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.2.9.4-alpha
 Severity:  Normal | Resolution:
 Keywords:  regression, CoreTorTeam201611  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

 * status:  needs_revision => accepted
 * owner:   => nickm


Comment:

 Added #20593 for the reset-on-503 issue above.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20499 [Core Tor/Tor]: A running Tor won't update the microdesc consensus

[Tor Bug Tracker & Wiki]

#20499: A running Tor won't update the microdesc consensus
---+---
 Reporter:  rubiate|  Owner:
 Type:  defect | Status:
   |  needs_revision
 Priority:  High   |  Milestone:  Tor:
   |  0.2.9.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.2.9.4-alpha
 Severity:  Normal | Resolution:
 Keywords:  regression, CoreTorTeam201611  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by nickm):

 Squashing and merging my patch above along with #20591 and #20533.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20499 [Core Tor/Tor]: A running Tor won't update the microdesc consensus

[Tor Bug Tracker & Wiki]

#20499: A running Tor won't update the microdesc consensus
---+---
 Reporter:  rubiate|  Owner:
 Type:  defect | Status:
   |  needs_revision
 Priority:  High   |  Milestone:  Tor:
   |  0.2.9.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.2.9.4-alpha
 Severity:  Normal | Resolution:
 Keywords:  regression, CoreTorTeam201611  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by nickm):

 Replying to [comment:30 teor]:
 > Code review of `20499_part1_029`:
 >
 > I'm surprised your compiler didn't warn about the assignment here:
 > {{{
 > if (dls->backoff = DL_SCHED_DETERMINISTIC)
 > }}}

 Yikes.  Added a fixup commit for that.

 > Replying to [comment:21 arma]:
 > > ...
 > > It seems to me that any design that effectively has a "now you won't
 ask for the consensus anymore" possible outcome is a scary one here.
 >
 > We should think carefully about what we want the default maximum to be,
 and if we want it to be the same in every case:
 > {{{
 > *max = INT_MAX;
 > }}}
 >
 > Perhaps the network could deal with slow zombies if they only retried
 every day/week/month. Or perhaps we really do want them to stop asking. Or
 perhaps we want clients to do one thing, and relays another.
 >
 > Currently, some schedules do have INT_MAX as their maximum, others have
 2, 12, or 73 hours.

 My thinking here was that we're backing off to infinite retries, so we
 might as well let the delays get arbitrarily large.  We might want to cut
 the maximum back down if it turns out to be a problem in practice, but I'd
 like to be cautious about zombies for now.

 > All the other commits look fine, but I'm not sure they're enough to
 solve this issue.

 Me neither!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20499 [Core Tor/Tor]: A running Tor won't update the microdesc consensus

[Tor Bug Tracker & Wiki]

#20499: A running Tor won't update the microdesc consensus
---+---
 Reporter:  rubiate|  Owner:
 Type:  defect | Status:
   |  needs_revision
 Priority:  High   |  Milestone:  Tor:
   |  0.2.9.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.2.9.4-alpha
 Severity:  Normal | Resolution:
 Keywords:  regression, CoreTorTeam201611  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by teor):

 * keywords:  regression => regression, CoreTorTeam201611
 * status:  needs_review => needs_revision


Comment:

 As well as the commits in 20499_part1_029, I think we should also merge
 #20533 to fix the one-download-multiple-failure case.

 We could also merge #20591, I don't think it's causing this particular
 issue, but it could make it worse if the bug is ever triggered.

 If we really do want every failure to result in a schedule increment, we
 have to remove the following code:

 download_status_increment_failure:
 {{{
   /* only count the failure if it's permanent, or we're a server */
   if (status_code != 503 || server) {
 if (dls->n_download_failures < IMPOSSIBLE_TO_DOWNLOAD-1)
   ++dls->n_download_failures;
   }
 }}}

 Because combined with this code in download_status_schedule_get_delay, it
 causes a reset on every 503:
 {{{
 /* Check if we missed a reset somehow */
 if (dls->last_backoff_position > dls_schedule_position) {
   dls->last_backoff_position = 0;
   dls->last_delay_used = 0;
 }
 }}}

 Which is exactly what we don't want when relays are busy - imagine clients
 doing an automatic reset every time they DoS a relay...

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20499 [Core Tor/Tor]: A running Tor won't update the microdesc consensus

[Tor Bug Tracker & Wiki]

#20499: A running Tor won't update the microdesc consensus
--+
 Reporter:  rubiate   |  Owner:
 Type:  defect| Status:  needs_review
 Priority:  High  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.4-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Code review of `20499_part1_029`:

 I'm surprised your compiler didn't warn about the assignment here:
 {{{
 if (dls->backoff = DL_SCHED_DETERMINISTIC)
 }}}

 Replying to [comment:21 arma]:
 > ...
 > It seems to me that any design that effectively has a "now you won't ask
 for the consensus anymore" possible outcome is a scary one here.

 We should think carefully about what we want the default maximum to be,
 and if we want it to be the same in every case:
 {{{
 *max = INT_MAX;
 }}}

 Perhaps the network could deal with slow zombies if they only retried
 every day/week/month. Or perhaps we really do want them to stop asking. Or
 perhaps we want clients to do one thing, and relays another.

 Currently, some schedules do have INT_MAX as their maximum, others have 2,
 12, or 73 hours.

 All the other commits look fine, but I'm not sure they're enough to solve
 this issue.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20499 [Core Tor/Tor]: A running Tor won't update the microdesc consensus

[Tor Bug Tracker & Wiki]

#20499: A running Tor won't update the microdesc consensus
--+
 Reporter:  rubiate   |  Owner:
 Type:  defect| Status:  needs_review
 Priority:  High  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.4-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  new => needs_review


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20499 [Core Tor/Tor]: A running Tor won't update the microdesc consensus

[Tor Bug Tracker & Wiki]

#20499: A running Tor won't update the microdesc consensus
--+
 Reporter:  rubiate   |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.4-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 I have a branch `bug20499_part1_029` that I think should be sufficient to
 make 0.2.9 work correctly here.  It solves #20534 and #20536 (and #20587
 too, since it was there).  The other stuff, I think, could wait to 0.3.0?
 My understanding is limited though.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20499 [Core Tor/Tor]: A running Tor won't update the microdesc consensus

[Tor Bug Tracker & Wiki]

#20499: A running Tor won't update the microdesc consensus
--+
 Reporter:  rubiate   |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.4-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 What's the current consensus on what the minimal set of fixes for 029 are
 here?  I'd like to do something for the next couple of days for an
 0.2.9.5-alpha, even if we expect that we'll have to fine-tune it a little
 more for 0.2.9.6-rc.

 Should we need to do '''all''' of the subtickets in 0.2.9, do you think?
 Or do we take a simpler approach?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20499 [Core Tor/Tor]: A running Tor won't update the microdesc consensus

[Tor Bug Tracker & Wiki]

#20499: A running Tor won't update the microdesc consensus
--+
 Reporter:  rubiate   |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.4-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Ok, and finally, for the bahaviour at the failure limit, I opened #20536.

 Some of these will also interact with #19969, we should consider both
 tickets when doing the fixes.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20499 [Core Tor/Tor]: A running Tor won't update the microdesc consensus

[Tor Bug Tracker & Wiki]

#20499: A running Tor won't update the microdesc consensus
--+
 Reporter:  rubiate   |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.4-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [comment:24 rubiate]:
 > Replying to [comment:19 arma]:
 > > What is wrong with your relay set-up such that they both fail to get a
 consensus at bootstrap? :)
 >
 > Ah, no, they both got a perfectly good consensus at startup. The
 "failures" every minute after that are from them having a fresh consensus,
 requesting a new one anyway and getting 304 Not Modified in response.

 So your reverted relay is bad: it retries 5 times every hour, when it
 should only try once an hour.
 And your bad relay is also bad: it retries never, when it should at least
 try once an hour.

 I opened #20535 for this.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20499 [Core Tor/Tor]: A running Tor won't update the microdesc consensus

[Tor Bug Tracker & Wiki]

#20499: A running Tor won't update the microdesc consensus
--+
 Reporter:  rubiate   |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.4-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by rubiate):

 Replying to [comment:19 arma]:
 > What is wrong with your relay set-up such that they both fail to get a
 consensus at bootstrap? :)

 Ah, no, they both got a perfectly good consensus at startup. The
 "failures" every minute after that are from them having a fresh consensus,
 requesting a new one anyway and getting 304 Not Modified in response.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20499 [Core Tor/Tor]: A running Tor won't update the microdesc consensus

[Tor Bug Tracker & Wiki]

#20499: A running Tor won't update the microdesc consensus
--+
 Reporter:  rubiate   |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.4-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [comment:21 arma]:
 > Replying to [comment:17 teor]:
 > > But at some exponent, the wait time becomes indistinguishable from
 failure.
 > > (Which is why we need to make sure requests trigger a new attempt.)
 >
 > It is good that we have the belt-and-suspenders fix in place where new
 client requests trigger a new attempt -- but that trick only works for
 clients. We should make sure that directory mirrors also have some way to
 reliably keep trying, and same for exit relays because of the
 should_refuse_unknown_exits() thing. Basically all of the reasons in
 directory_fetches_from_authorities().
 >
 > > I guess this essentially implements hibernate mode then?
 > >
 > > And we could just put the failure count up to something quite high,
 let's say, at most, the failure number at which tor is waiting for the
 average time between tor stable releases?
 >
 > It seems to me that any design that effectively has a "now you won't ask
 for the consensus anymore" possible outcome is a scary one here. Speaking
 of which. is there a place I should look to read about our current
 download design? I only know the one I wrote some years ago, and it looks
 like it's changed since then.

 I logged #20534 for this. There are existing cases where we give up
 forever. We should tune them to do what we think we want.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20499 [Core Tor/Tor]: A running Tor won't update the microdesc consensus

[Tor Bug Tracker & Wiki]

#20499: A running Tor won't update the microdesc consensus
--+
 Reporter:  rubiate   |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.4-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [comment:21 arma]:
 > Replying to [comment:17 teor]:
 > > But at some exponent, the wait time becomes indistinguishable from
 failure.
 > > (Which is why we need to make sure requests trigger a new attempt.)
 >
 > It is good that we have the belt-and-suspenders fix in place where new
 client requests trigger a new attempt -- but that trick only works for
 clients. We should make sure that directory mirrors also have some way to
 reliably keep trying, and same for exit relays because of the
 should_refuse_unknown_exits() thing. Basically all of the reasons in
 directory_fetches_from_authorities().
 >
 > > I guess this essentially implements hibernate mode then?
 > >
 > > And we could just put the failure count up to something quite high,
 let's say, at most, the failure number at which tor is waiting for the
 average time between tor stable releases?
 >
 > It seems to me that any design that effectively has a "now you won't ask
 for the consensus anymore" possible outcome is a scary one here. Speaking
 of which. is there a place I should look to read about our current
 download design? I only know the one I wrote some years ago, and it looks
 like it's changed since then.

 Proposal 210 is close, but it's been modified by at least you, me, and
 andrea since then.

 > > Firstly, because they get incremented twice for each failure.
 >
 > I haven't looked into that one, but if so, can we open a new ticket for
 this (what looks like separate) bug?

 #20533

 > > And secondly, because the laptop was offline for 12? hours?
 >
 > Actually, I think I drove my consensus download failure count up to 8
 over the course of about ten minutes -- it launches each new try within a
 second of when the last one failed:
 > {{{
 > Oct 24 03:51:12.713 [info]
 update_consensus_bootstrap_attempt_downloads(): Launching microdesc
 bootstrap mirror networkstatus consensus download.
 > Oct 24 03:51:12.713 [info]
 update_consensus_bootstrap_attempt_downloads(): Launching microdesc
 bootstrap authority networkstatus consensus download.
 > Oct 24 03:51:42.725 [info]
 update_consensus_bootstrap_attempt_downloads(): Launching microdesc
 bootstrap authority networkstatus consensus download.
 > Oct 24 03:52:36.747 [info]
 update_consensus_bootstrap_attempt_downloads(): Launching microdesc
 bootstrap authority networkstatus consensus download.
 > Oct 24 03:54:14.787 [info]
 update_consensus_bootstrap_attempt_downloads(): Launching microdesc
 bootstrap authority networkstatus consensus download.
 > Oct 24 03:57:19.855 [info]
 update_consensus_bootstrap_attempt_downloads(): Launching microdesc
 bootstrap authority networkstatus consensus download.
 > Oct 24 04:00:48.938 [info]
 update_consensus_bootstrap_attempt_downloads(): Launching microdesc
 bootstrap authority networkstatus consensus download.
 > }}}
 >
 > My laptop was closed (asleep) for more than a day, so when it woke up
 its consensus was more than 24 hours old, so it immediately jumped to
 bootstrap mode for its downloads. Ten minutes later, it had given up
 permanently.

 That timing is off from what I would expect - when I designed it, it was:
 Fallbacks: 0, 1, 5, 16, 3600, ...
 Authorities: 10, 21, 3600, ...

 But if we're skipping two on every failure, it could become:
 Fallbacks: 0, (1 or 5 depending on exact failure timing), 3600, ...
 Authorities: 10, 3600, ...
 And if the client has all the authorities as down, I guess it won't even
 try them.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20499 [Core Tor/Tor]: A running Tor won't update the microdesc consensus

[Tor Bug Tracker & Wiki]

#20499: A running Tor won't update the microdesc consensus
--+
 Reporter:  rubiate   |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.4-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Replying to [comment:17 teor]:
 > But at some exponent, the wait time becomes indistinguishable from
 failure.
 > (Which is why we need to make sure requests trigger a new attempt.)

 It is good that we have the belt-and-suspenders fix in place where new
 client requests trigger a new attempt -- but that trick only works for
 clients. We should make sure that directory mirrors also have some way to
 reliably keep trying, and same for exit relays because of the
 should_refuse_unknown_exits() thing. Basically all of the reasons in
 directory_fetches_from_authorities().

 > I guess this essentially implements hibernate mode then?
 >
 > And we could just put the failure count up to something quite high,
 let's say, at most, the failure number at which tor is waiting for the
 average time between tor stable releases?

 It seems to me that any design that effectively has a "now you won't ask
 for the consensus anymore" possible outcome is a scary one here. Speaking
 of which. is there a place I should look to read about our current
 download design? I only know the one I wrote some years ago, and it looks
 like it's changed since then.

 > Firstly, because they get incremented twice for each failure.

 I haven't looked into that one, but if so, can we open a new ticket for
 this (what looks like separate) bug?

 > And secondly, because the laptop was offline for 12? hours?

 Actually, I think I drove my consensus download failure count up to 8 over
 the course of about ten minutes -- it launches each new try within a
 second of when the last one failed:
 {{{
 Oct 24 03:51:12.713 [info] update_consensus_bootstrap_attempt_downloads():
 Launching microdesc bootstrap mirror networkstatus consensus download.
 Oct 24 03:51:12.713 [info] update_consensus_bootstrap_attempt_downloads():
 Launching microdesc bootstrap authority networkstatus consensus download.
 Oct 24 03:51:42.725 [info] update_consensus_bootstrap_attempt_downloads():
 Launching microdesc bootstrap authority networkstatus consensus download.
 Oct 24 03:52:36.747 [info] update_consensus_bootstrap_attempt_downloads():
 Launching microdesc bootstrap authority networkstatus consensus download.
 Oct 24 03:54:14.787 [info] update_consensus_bootstrap_attempt_downloads():
 Launching microdesc bootstrap authority networkstatus consensus download.
 Oct 24 03:57:19.855 [info] update_consensus_bootstrap_attempt_downloads():
 Launching microdesc bootstrap authority networkstatus consensus download.
 Oct 24 04:00:48.938 [info] update_consensus_bootstrap_attempt_downloads():
 Launching microdesc bootstrap authority networkstatus consensus download.
 }}}

 My laptop was closed (asleep) for more than a day, so when it woke up its
 consensus was more than 24 hours old, so it immediately jumped to
 bootstrap mode for its downloads. Ten minutes later, it had given up
 permanently.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20499 [Core Tor/Tor]: A running Tor won't update the microdesc consensus

[Tor Bug Tracker & Wiki]

#20499: A running Tor won't update the microdesc consensus
--+
 Reporter:  rubiate   |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.4-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [comment:19 arma]:
 > Replying to [comment:14 rubiate]:
 > > I set up two new relays:
 > > [...]
 > > Rough timeline:
 > >
 > > 10:36 Both start up
 > > [...] both request the consensus every minute
 > > 10:41 they reach a fail count of 10
 >
 > What is wrong with your relay set-up such that they both failure to get
 a consensus at bootstrap? :)
 >
 > Are you firewalled in some weird way? Are they trying to fetch it from
 fallbackdirs and those are surprisingly faily? Are they trying from
 directory authorities and our authorities are no good?
 >
 > Anyway, it looks like 'revert' is the winner, but it would still be
 great to learn what is so helpful about your test environment that it
 triggers this bug so well.

 Well, they're in Australia, so latency is high, and measured bandwidth is
 low. But I'm not sure that would cause so many failures. Maybe something
 with OpenBSD?

 My relay at the same provider has AccountingMax set, and has disabled its
 DirPort, so it's much harder to interrogate. It's on FreeBSD, but on
 0.2.8.7 (still waiting for a package update), and up to date with its
 consensuses.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20499 [Core Tor/Tor]: A running Tor won't update the microdesc consensus

[Tor Bug Tracker & Wiki]

#20499: A running Tor won't update the microdesc consensus
--+
 Reporter:  rubiate   |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.4-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Replying to [comment:14 rubiate]:
 > I set up two new relays:
 > [...]
 > Rough timeline:
 >
 > 10:36 Both start up
 > [...] both request the consensus every minute
 > 10:41 they reach a fail count of 10

 What is wrong with your relay set-up such that they both failure to get a
 consensus at bootstrap? :)

 Are you firewalled in some weird way? Are they trying to fetch it from
 fallbackdirs and those are surprisingly faily? Are they trying from
 directory authorities and our authorities are no good?

 Anyway, it looks like 'revert' is the winner, but it would still be great
 to learn what is so helpful about your test environment that it triggers
 this bug so well.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20499 [Core Tor/Tor]: A running Tor won't update the microdesc consensus

[Tor Bug Tracker & Wiki]

#20499: A running Tor won't update the microdesc consensus
--+
 Reporter:  rubiate   |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.4-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Oh, and because we have bad directory mirrors serving out of date
 consensuses repeatedly?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20499 [Core Tor/Tor]: A running Tor won't update the microdesc consensus

[Tor Bug Tracker & Wiki]

#20499: A running Tor won't update the microdesc consensus
--+
 Reporter:  rubiate   |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.4-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [comment:16 nickm]:
 > So, if we're truly on exponential backoff, no maximum could be too
 large, right?

 Technically, yes.

 But at some exponent, the wait time becomes indistinguishable from
 failure.
 (Which is why we need to make sure requests trigger a new attempt.)

 I guess this essentially implements hibernate mode then?

 And we could just put the failure count up to something quite high, let's
 say, at most, the failure number at which tor is waiting for the average
 time between tor stable releases?

 > I also wonder, why are these failure counts so high?

 Firstly, because they get incremented twice for each failure.

 {{{
 download_status_increment_failure() gets called with a status_code of 304

 update_consensus_networkstatus_downloads() gets called again, this time it
 stops at the call to connection_dir_count_by_purpose_and_resource() which
 returns 1 (equal to max_in_progress_conns)

 download_status_increment_failure() gets called again, this time with a
 status_code of 0 (as a result each 304 response results in the fail count
 being increased by 2)
 }}}

 And secondly, because the laptop was offline for 12? hours?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20499 [Core Tor/Tor]: A running Tor won't update the microdesc consensus

[Tor Bug Tracker & Wiki]

#20499: A running Tor won't update the microdesc consensus
--+
 Reporter:  rubiate   |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.4-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 So, if we're truly on exponential backoff, no maximum could be too large,
 right?

 I also wonder, why are these failure counts so high?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20499 [Core Tor/Tor]: A running Tor won't update the microdesc consensus

[Tor Bug Tracker & Wiki]

#20499: A running Tor won't update the microdesc consensus
--+
 Reporter:  rubiate   |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.4-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Perhaps max_dl_tries is also far too low, and we should increase it
 somewhat? 10?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20499 [Core Tor/Tor]: A running Tor won't update the microdesc consensus

[Tor Bug Tracker & Wiki]

#20499: A running Tor won't update the microdesc consensus
--+
 Reporter:  rubiate   |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.4-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by rubiate):

 I set up two new relays:

 bug20499badED6E43F07ABE87C017BD80D4BA24E41F8FF32E94
 bug20499revert 083971FD18EDBD442DF0971D0FDC6F500642AD91

 'bad is running 0.2.9.4-alpha, and 'revert is identical except it has
 09a0f2d0b24 reverted. Both have the same config, other than cosmetic
 differences (different names, ports, logfile).

 Rough timeline:

 10:36 Both start up
 [...] both request the consensus every minute
 10:41 they reach a fail count of 10
 [...] both do nothing every minute, fail count is too high
 11:36 'revert updates the microdesc consensus; valid-until 2016-11-01
 14:00:00
 11:36 'bad is still doing nothing, valid-until 2016-11-01 13:00:00
 11:37 'revert tries to do it again, gets a 304, fail count is 2
 11:38 'revert tries to do it again, gets a 304, fail count is 4
 [...] and so on
 11:41 'revert reaches a fail count of 10 again
 [...] both do nothing
 12:36 'revert updates; valid-until 2016-11-01 15:00:00
 12:36 'bad doesn't; valid-until 2016-11-01 13:00:00
 12:41 'revert hits 10 fails again
 [...] doin' nothin'
 13:00 'bad now has a microdesc consensus past its valid-until date
 [...]
 13:36 'revert updates; valid-until 2016-11-01 16:00:00
 13:36 'bad doesn't; valid-until 2016-11-01 13:00:00
 [...] I suspect this pattern is going to hold.

 'revert:
 http://45.32.188.229:9209/tor/status-vote/current/consensus-microdesc

 'bad:
 http://45.32.188.229:9201/tor/status-vote/current/consensus-microdesc

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20499 [Core Tor/Tor]: A running Tor won't update the microdesc consensus

[Tor Bug Tracker & Wiki]

#20499: A running Tor won't update the microdesc consensus
--+
 Reporter:  rubiate   |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.4-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 I concur that for 0.2.9, reverting 09a0f2d0b seems like a good choice.  If
 we feel cheeky, we might increase the interval, though...

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20499 [Core Tor/Tor]: A running Tor won't update the microdesc consensus

[Tor Bug Tracker & Wiki]

#20499: A running Tor won't update the microdesc consensus
--+
 Reporter:  rubiate   |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.4-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 rubiate, are you able to reproduce this bug consistently? If so, can you
 spin up a relay or bridge with commit 09a0f2d0b24 reverted, and see how
 that fares? My guess is that it will fare much better.

 In the mean time, I've opened #20501 to look at the Tor network for relays
 that were bitten by this bug (seems like quite a few), and #20509 for
 doing something about getting them off the network and/or taking away
 their Guard flag so clients don't get stuck behind them and then be unable
 to use Tor.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20499 [Core Tor/Tor]: A running Tor won't update the microdesc consensus

[Tor Bug Tracker & Wiki]

#20499: A running Tor won't update the microdesc consensus
--+
 Reporter:  rubiate   |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.4-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Easy answer is to revert 09a0f2d0b24 until we've designed a better
 download schedule and a better mechanism for testing it?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20499 [Core Tor/Tor]: A running Tor won't update the microdesc consensus

[Tor Bug Tracker & Wiki]

#20499: A running Tor won't update the microdesc consensus
--+
 Reporter:  rubiate   |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.4-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 #8625 has this choice quote: "I say we merge and wait to see if we get
 bugs reported?"

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20499 [Core Tor/Tor]: A running Tor won't update the microdesc consensus

[Tor Bug Tracker & Wiki]

#20499: A running Tor won't update the microdesc consensus
--+
 Reporter:  rubiate   |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.4-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 For thoroughness,
 {{{
 (gdb) print consensus_bootstrap_dl_status
 $6 = {{next_attempt_at = 1477296321, n_download_failures = 0 '\000',
 n_download_attempts = 8 '\b', schedule = DL_SCHED_CONSENSUS,
 want_authority = DL_WANT_AUTHORITY,
 increment_on = DL_SCHED_INCREMENT_ATTEMPT,
 backoff = DL_SCHED_RANDOM_EXPONENTIAL, last_backoff_position = 8 '\b',
 last_delay_used = 273}, {next_attempt_at = 1477295479,
 n_download_failures = 0 '\000', n_download_attempts = 8 '\b',
 schedule = DL_SCHED_CONSENSUS, want_authority = DL_WANT_ANY_DIRSERVER,
 increment_on = DL_SCHED_INCREMENT_ATTEMPT,
 backoff = DL_SCHED_RANDOM_EXPONENTIAL, last_backoff_position = 8 '\b',
 last_delay_used = 7}}
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20499 [Core Tor/Tor]: A running Tor won't update the microdesc consensus

[Tor Bug Tracker & Wiki]

#20499: A running Tor won't update the microdesc consensus
--+
 Reporter:  rubiate   |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.4-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Looking back at rubiate's analysis, my debugging matches theirs.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20499 [Core Tor/Tor]: A running Tor won't update the microdesc consensus

[Tor Bug Tracker & Wiki]

#20499: A running Tor won't update the microdesc consensus
--+
 Reporter:  rubiate   |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.4-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 To give some other context to folks reading this ticket, here is some more
 debugging detail (all from my Tor client that has been opting not to
 retrieve a new consensus for the past week+):

 I set a breakpoint on fetch_networkstatus_callback, and learned that
 prefer_mirrors is 1, and we_are_bootstrapping is 1.
 should_delay_dir_fetches() was 0. It called update_networkstatus_downloads
 as expected.

 Then I set a breakpoint on update_consensus_networkstatus_downloads. Again
 we_are_bootstrapping is 1. use_multi_conn alas is , but
 looking at the function, I assume it's 1 for me. The first round through
 the loop, for vanilla consensus flavor, we_want_to_fetch_flavor() is no,
 so I move on to the second round through the loop. I don't know how
 {{{c = networkstatus_get_latest_consensus_by_flavor(i);}}} goes because
 "print c" also says , but it looks like it runs
 {{{time_to_download_next_consensus[i] = now;}}} next, so I can assume that
 c was NULL. Then it keeps going through the function until it calls
 update_consensus_bootstrap_multiple_downloads(). Looks plausible.

 So I set a breakpoint on update_consensus_bootstrap_multiple_downloads,
 which was trickier than I would have wanted since it looks like my
 compiler inlined it into update_consensus_networkstatus_downloads. But it
 looks like it does make two calls to
 update_consensus_bootstrap_attempt_downloads -- one with dls_f, and the
 next with dls_a.

 So I set a breakpoint on update_consensus_bootstrap_attempt_downloads. It
 sets max_dl_tries to 7, which makes sense since I see it there in
 config.c, set to default to 7.

 Now it gets interesting:
 {{{
 (gdb) print *dls
 $3 = {next_attempt_at = 1477295479, n_download_failures = 0 '\000',
   n_download_attempts = 8 '\b', schedule = DL_SCHED_CONSENSUS,
   want_authority = DL_WANT_ANY_DIRSERVER,
   increment_on = DL_SCHED_INCREMENT_ATTEMPT,
   backoff = DL_SCHED_RANDOM_EXPONENTIAL, last_backoff_position = 8 '\b',
   last_delay_used = 7}
 }}}

 n_download_attempts is 8, and max_dl_tries is 7. I wonder where this is
 going!

 Turns out download_status_is_ready() is no fun to gdb in because it's an
 inline tucked into directory.h, but looking at the code, it seems clear it
 returns 0, i.e. not ready. Then the function exits.

 Then the same thing happens with the
 update_consensus_bootstrap_attempt_downloads call that was for dls_a.

 Conclusion, I somehow failed 8 times to get a consensus, and now I will
 never try again.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #20499 [Core Tor/Tor]: A running Tor won't update the microdesc consensus (was: Relay/Bridge won't update the microdesc consensus while running)

[Tor Bug Tracker & Wiki]

#20499: A running Tor won't update the microdesc consensus
--+
 Reporter:  rubiate   |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.4-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 (changing the title since this happened to my tor client too)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs