Re: [tor-bugs] #25347 [Core Tor/Tor]: Tor stops building circuits, and doesn't start when it has enough directory information

[Tor Bug Tracker & Wiki]

#25347: Tor stops building circuits, and doesn't start when it has enough 
directory
information
-+-
 Reporter:  teor |  Owner:  asn
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.6
 Severity:  Normal   | Resolution:
 Keywords:  031-backport, 032-backport,  |  Actual Points:
  033-must, tor-guard, tor-client, tbb-  |
  usability-website, tbb-needs,  |
  033-triage-20180320, 033-included-20180320 |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by mikeperry):

 Replying to [comment:28 asn]:
 > Replying to [comment:25 mikeperry]:
 > > A couple comments here:
 > >
 > > 1. We already treat non-destroy failures at the guard as rotate-away
 failures in circuit_build_failed(). Note that there is an explicit check
 to not blame the guard if circ->base_.received_destroy is set. If we
 remove that check in circuit_build_failed(), we should not need asn's
 patch, as the behavior would then be equivalent (or actually a superset,
 since it would cover all destroy reasons). (I think this is what arma
 meant in his point H?). This would be a simpler patch.
 > >
 >
 > Seems like a reasonable plan. Let's proceed like that.

 Ok. Note that after talking to arma, I decided to file #25705. In that
 refactor I could also fix this issue. I guess it depends on if we want to
 backport that.

 > > 2. Roger's point G is scary. I like the solution in E, though, and I
 think it actually fixes G. I would implement E by setting an is_predicted
 flag in circuit_predict_and_launch_new(), and then check that flag in
 select_entry_guard_for_circuit() to completely ignore the is_reachable
 status there if it is set. Then if any of those predicted circuits
 succeed, entry_guards_node_success() will get called, which will clear the
 is_uneachable flag and allow us to resume using the guard. For guards that
 fail only a non-zero but small portion of their circuits, this should
 allow us to keep using them rather than rotating away. I am a fan of this
 plan, and could write a patch for it if we like it.
 > >
 >
 > Hmm, I can see how the solution of E can help with G, by making Alice
 try her primary guards more aggressively in cases of predicted circuits,
 but if Alice is a busy hidden service (like Roger describes in E) most of
 her circs are not gonna be predicted.

 But a client/service will always keep building predicted circuits such
 that it has 3 of each type available. This means even a busy hidden
 service will keep making predicted circuits, which, any time they succeed,
 will reset the fact that the guard is reachable for use by other circuits.
 So, so long as some circuits are succeeding through that guard, the
 service should keep going back to it fairly quickly.

 > Furthermore, I wonder if it can completely address the problem in
 actually ''mischievous'' scenarios, where the adversary overloads all 3
 primary guards of Alice (targeting them using guard discovery attacks) to
 make her switch to other guards in her sampled set.

 This case is tricky. I am not sure what to do with predicted circuits if
 all primary guards get into the unreachable state. One option is to toss a
 coin and pick primary vs sampled for predicted circuits, if all primary
 are down.

--
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] #25347 [Core Tor/Tor]: Tor stops building circuits, and doesn't start when it has enough directory information

[Tor Bug Tracker & Wiki]

#25347: Tor stops building circuits, and doesn't start when it has enough 
directory
information
-+-
 Reporter:  teor |  Owner:  asn
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.6
 Severity:  Normal   | Resolution:
 Keywords:  031-backport, 032-backport,  |  Actual Points:
  033-must, tor-guard, tor-client, tbb-  |
  usability-website, tbb-needs,  |
  033-triage-20180320, 033-included-20180320 |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by asn):

 Replying to [comment:25 mikeperry]:
 > A couple comments here:
 >
 > 1. We already treat non-destroy failures at the guard as rotate-away
 failures in circuit_build_failed(). Note that there is an explicit check
 to not blame the guard if circ->base_.received_destroy is set. If we
 remove that check in circuit_build_failed(), we should not need asn's
 patch, as the behavior would then be equivalent (or actually a superset,
 since it would cover all destroy reasons). (I think this is what arma
 meant in his point H?). This would be a simpler patch.
 >

 Seems like a reasonable plan. Let's proceed like that.

 > 2. Roger's point G is scary. I like the solution in E, though, and I
 think it actually fixes G. I would implement E by setting an is_predicted
 flag in circuit_predict_and_launch_new(), and then check that flag in
 select_entry_guard_for_circuit() to completely ignore the is_reachable
 status there if it is set. Then if any of those predicted circuits
 succeed, entry_guards_node_success() will get called, which will clear the
 is_uneachable flag and allow us to resume using the guard. For guards that
 fail only a non-zero but small portion of their circuits, this should
 allow us to keep using them rather than rotating away. I am a fan of this
 plan, and could write a patch for it if we like it.
 >

 Hmm, I can see how the solution of E can help with G, by making Alice try
 her primary guards more aggressively in cases of predicted circuits, but
 if Alice is a busy hidden service (like Roger describes in E) most of her
 circs are not gonna be predicted.

 Furthermore, I wonder if it can completely address the problem in actually
 ''mischievous'' scenarios, where the adversary overloads all 3 primary
 guards of Alice (targeting them using guard discovery attacks) to make her
 switch to other guards in her sampled set.

--
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] #25347 [Core Tor/Tor]: Tor stops building circuits, and doesn't start when it has enough directory information

[Tor Bug Tracker & Wiki]

#25347: Tor stops building circuits, and doesn't start when it has enough 
directory
information
-+-
 Reporter:  teor |  Owner:  asn
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.6
 Severity:  Normal   | Resolution:
 Keywords:  031-backport, 032-backport,  |  Actual Points:
  033-must, tor-guard, tor-client, tbb-  |
  usability-website, tbb-needs,  |
  033-triage-20180320, 033-included-20180320 |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:22 teor]:
 > Replying to [comment:21 asn]:
 > > Replying to some of the high-level comments of arma:
 > >
 > > Replying to [comment:18 arma]:
 > > > (F) Are you sure that the proposed branch is related to the topic of
 this ticket? The ticket title and body seem quite different from what the
 branch does. That makes me wonder if maybe we're not actually solving the
 original bug report. :)
 > > >
 > >
 > > This patch is meant to address the second paragraph of the ticket
 body, and also is meant to directly fix the issue that s7r (and others)
 encountered in #21969. My understanding is that this is the main guard
 issue right now, and not the fact that clients can run out of md retries.
 Do you think this is true, teor?
 >
 > We removed all retry limits when we removed the legacy static download
 schedule code. So clients can't run out of md retries any more. (I can't
 find the ticket right now, but we did merge the patch.)

 It's #23814 in 0.3.3.4-alpha.

 > So yes, failing to reconnect is a major guard issue. I don't know if
 there are any others.

--
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] #25347 [Core Tor/Tor]: Tor stops building circuits, and doesn't start when it has enough directory information

[Tor Bug Tracker & Wiki]

#25347: Tor stops building circuits, and doesn't start when it has enough 
directory
information
-+-
 Reporter:  teor |  Owner:  asn
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.6
 Severity:  Normal   | Resolution:
 Keywords:  031-backport, 032-backport,  |  Actual Points:
  033-must, tor-guard, tor-client, tbb-  |
  usability-website, tbb-needs,  |
  033-triage-20180320, 033-included-20180320 |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by mikeperry):

 Additional wrinkles to 2: we have to ignore the ordering of our primary
 guards for this fix to allow predicted circuits to complete for the case
 of a truly downed guard. However, if all primary guards are unreachable
 though, we may want a different strategy to avoid spamming them with
 predicted circuits. Maybe first check to make sure we have at least 1
 is_reachable primary guard before picking one randomly for predicted
 circuits? How about that?

--
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] #25347 [Core Tor/Tor]: Tor stops building circuits, and doesn't start when it has enough directory information

[Tor Bug Tracker & Wiki]

#25347: Tor stops building circuits, and doesn't start when it has enough 
directory
information
-+-
 Reporter:  teor |  Owner:  asn
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.6
 Severity:  Normal   | Resolution:
 Keywords:  031-backport, 032-backport,  |  Actual Points:
  033-must, tor-guard, tor-client, tbb-  |
  usability-website, tbb-needs,  |
  033-triage-20180320, 033-included-20180320 |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by mikeperry):

 A couple comments here:

 1. We already treat non-destroy failures at the guard as rotate-away
 failures in circuit_build_failed(). Note that there is an explicit check
 to not blame the guard if circ->base_.received_destroy is set. If we
 remove that check in circuit_build_failed(), we should not need asn's
 patch, as the behavior would then be equivalent (or actually a superset,
 since it would cover all destroy reasons). (I think this is what arma
 meant in his point H?). This would be a simpler patch.

 2. Roger's point G is scary. I like the solution in E, though, and I think
 it actually fixes G. If predicted circuits set an is_predicted flag in
 circuit_predict_and_launch_new(), and then we check that flag in
 select_entry_guard_for_circuit() to completely ignore the is_reachable
 status there, then predicted circuits should periodically cause
 entry_guards_node_success() to get called upon any success of a predicted
 circuit for spuriously failing guards, so they don't go the whole 30
 minutes without being used again. I am a fan of this plan, and could write
 a patch for it if we like 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] #25347 [Core Tor/Tor]: Tor stops building circuits, and doesn't start when it has enough directory information

[Tor Bug Tracker & Wiki]

#25347: Tor stops building circuits, and doesn't start when it has enough 
directory
information
-+-
 Reporter:  teor |  Owner:  asn
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.6
 Severity:  Normal   | Resolution:
 Keywords:  031-backport, 032-backport,  |  Actual Points:
  033-must, tor-guard, tor-client, tbb-  |
  usability-website, tbb-needs,  |
  033-triage-20180320, 033-included-20180320 |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Replying to [comment:23 s7r]:
 > It is very hard to reproduce / catch this bug in the wild.
 Hey @s7r, can you test the scenario mentioned in #25600:comment6? Maybe
 it's related to this bug.

--
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] #25347 [Core Tor/Tor]: Tor stops building circuits, and doesn't start when it has enough directory information

[Tor Bug Tracker & Wiki]

#25347: Tor stops building circuits, and doesn't start when it has enough 
directory
information
-+-
 Reporter:  teor |  Owner:  asn
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.6
 Severity:  Normal   | Resolution:
 Keywords:  031-backport, 032-backport,  |  Actual Points:
  033-must, tor-guard, tor-client, tbb-  |
  usability-website, tbb-needs,  |
  033-triage-20180320, 033-included-20180320 |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by s7r):

 Replying to [comment:10 asn]:
 > Looking at your logs, it seems like your guard rejected about 230 new
 circuit creations in 15 minutes with the excuse of `RESOURCELIMIT`. And
 your client just kept making more and more circuits to the same guard that
 were getting rejected... I've also noticed this exact same behavior on a
 client of mine recently.
 >

 I see that as well, but this happens more often and Tor has no problems in
 switching to guard 2/3 or even guard 3/3 to maintain functionality. This
 time (it happens rarely) it completely remained in this useless state.

 > My theory on why `RESOURCELIMIT` was used by your guard (given that you
 say that DoS patch was disabled) is that `assign_onionskin_to_cpuworker()`
 failed because `onion_pending_add()` failed because
 `have_room_for_onionskin()` failed. That means that the relay was
 overworked and had way too many cells to process at that time.
 Unfortunately, I can't see whether you are sending NTOR or TAP cells given
 your logs.
 >

 I know for sure the DoS patch is not related because I triple checked all
 3 primary guards and not even one of them was running a Tor version that
 includes the DoS patch we merged. I think I was using only NTOR cells,
 because I was only trying to reach check.tpo and duckduckgo clearnet
 websites.

 > Like you said, I think the most obvious misbehavior here is that you
 keep on hassling your guard even tho it's telling you to relax by sending
 your `RESOURCELIMIT` `DESTROY` cells. Perhaps one approach here would be
 to choose a different guard after a guard has sent us `RESOURCELIMIT`
 cells, in an attempt to unclog the guard and to get better service.
 '''Let's think about this some more:'''
 >
 > What's the best behavior here? Should we mark the guard as down after
 receiving a single `RESOURCELIMIT` cell, or should we hassle the guard a
 bit before giving up?
 >

 This is the most important part we need to take care of. I dislike the
 idea to remove the guard after receiving a single `RESOURCELIMIT` cell. At
 least we should retry it after some time using the exponential backoff
 exactly as we do when one of our primary guards is not running or not
 listed, and maintain the same logic, timing and behavior so we don't have
 to maintain more branches.

 > Most importantly, can we make sure that the `DESTROY` cell came from the
 guard and not from some other node in the path? If we can make sure that
 the `DESTROY` cell came from the guard, this seem to me like a pretty safe
 countermeasure since we should trust the guard to tell us whether it's
 overworked or not.
 >

 As I can understand from arma's comment the `DESTROY` cell can only come
 from the guard.

 > WRT timeline here, I think working on this countermeasure (mark guard as
 down when overworked to get better service) seems like a plausible goal
 for 033, but anything more involved will probably need to wait for 034.
 >
 > Would appreciate feedback from Nick or Tim here :)
 >
 > 
 >
 > I still can't explain why you managed to bootstrap after hacking your
 state file tho. Perhaps a coincidence? Perhaps you were overworking your
 guard and when you stopped, it relaxed? Perhaps the hack worked
 differently than you imagine? Not sure.

 I sincerely hope so. But it makes me think: for many hours the guard is
 overworked, and when I delete my state file and restart and edit again the
 new state file putting back all the previous 3/3 primary guards that were
 not allowing me to connect, it just connects fine. I don't have any
 evidence that there was something wrong with the state file, and I don't
 see what could be wrong with it, it does not make any sense. It is very
 hard to reproduce / catch this bug in the wild.

--
Ticket URL: 
Tor Bug 

Re: [tor-bugs] #25347 [Core Tor/Tor]: Tor stops building circuits, and doesn't start when it has enough directory information

[Tor Bug Tracker & Wiki]

#25347: Tor stops building circuits, and doesn't start when it has enough 
directory
information
-+-
 Reporter:  teor |  Owner:  asn
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.6
 Severity:  Normal   | Resolution:
 Keywords:  031-backport, 032-backport,  |  Actual Points:
  033-must, tor-guard, tor-client, tbb-  |
  usability-website, tbb-needs,  |
  033-triage-20180320, 033-included-20180320 |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:21 asn]:
 > Replying to some of the high-level comments of arma:
 >
 > Replying to [comment:18 arma]:
 > > (F) Are you sure that the proposed branch is related to the topic of
 this ticket? The ticket title and body seem quite different from what the
 branch does. That makes me wonder if maybe we're not actually solving the
 original bug report. :)
 > >
 >
 > This patch is meant to address the second paragraph of the ticket body,
 and also is meant to directly fix the issue that s7r (and others)
 encountered in #21969. My understanding is that this is the main guard
 issue right now, and not the fact that clients can run out of md retries.
 Do you think this is true, teor?

 We removed all retry limits when we removed the legacy static download
 schedule code. So clients can't run out of md retries any more. (I can't
 find the ticket right now, but we did merge the patch.)

 So yes, failing to reconnect is a major guard issue. I don't know if there
 are any others.

--
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] #25347 [Core Tor/Tor]: Tor stops building circuits, and doesn't start when it has enough directory information

[Tor Bug Tracker & Wiki]

#25347: Tor stops building circuits, and doesn't start when it has enough 
directory
information
-+-
 Reporter:  teor |  Owner:  asn
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.6
 Severity:  Normal   | Resolution:
 Keywords:  031-backport, 032-backport,  |  Actual Points:
  033-must, tor-guard, tor-client, tbb-  |
  usability-website, tbb-needs,  |
  033-triage-20180320, 033-included-20180320 |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by asn):

 Replying to some of the high-level comments of arma:

 Replying to [comment:18 arma]:
 > (F) Are you sure that the proposed branch is related to the topic of
 this ticket? The ticket title and body seem quite different from what the
 branch does. That makes me wonder if maybe we're not actually solving the
 original bug report. :)
 >

 This patch is meant to address the second paragraph of the ticket body,
 and also is meant to directly fix the issue that s7r (and others)
 encountered in #21969. My understanding is that this is the main guard
 issue right now, and not the fact that clients can run out of md retries.
 Do you think this is true, teor?

 > (B) Note that in the ddos mitigation stuff, we refuse circuits from
 overloaders with reason resource-limit (see DOS_CC_DEFENSE_REFUSE_CELL).
 And at least at the time, the goal was to soak up their overload circuits
 at the guard level, i.e. keep them occupied at a point where we're able to
 limit the damage they do. If we implement this ticket, overloader clients
 will immediately skip off to hassle some other guard. Maybe that's ok? Or
 maybe it would be a sad side effect? Maybe we should change the ddos
 mitigation to use some other destroy reason, so we don't trigger
 overloaders to move? I'm not sure what's best, but let's intentionally
 choose something.

 I think this is an important design-level issue here. I was actually not
 aware that the intention of the DoS subsystem is to soak up the overloader
 on a single guard, and if that's the case this patch works completely
 against it and we should NACK it. However, if that's the case, I'm not
 sure what we should do about the users who encounter this reachability
 issue, where they are behind an overloaded guard and they can't use it or
 escape it. Seems like a tradeoff between the overloader completely
 disabling a single guard and its users, or the overloader spreading the
 load across the network and potentially harming multiple relays before
 they kick the overloader to the next one. And of course, all that's
 assuming an accidental overloader who follows the Tor protocol, because if
 they hack their tor client to be intentionally evil they can do whatever
 they want.

 Not sure how to proceed here. Any ideas?

 > (G) Do we have a handle on how often existing guards respond with reason
 resource-limit? Imagine a Tor client that makes a bunch of circuits often,
 say because it's an active onion service. And let's say on average 5% of
 create cells get a resource-limit response. And let's say we wait 30
 minutes before retrying a guard that we marked as down. We're going to
 churn through a *lot* of guards this way, right?

 That's another design-level issue we should think about. We should make
 sure this does not allow an attacker to simply cause an HS to cycle guards
 for ever, by overloading its current guards. Not sure if we can properly
 do this research in the 033 timeframe tho...

--
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] #25347 [Core Tor/Tor]: Tor stops building circuits, and doesn't start when it has enough directory information

[Tor Bug Tracker & Wiki]

#25347: Tor stops building circuits, and doesn't start when it has enough 
directory
information
-+-
 Reporter:  teor |  Owner:  asn
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.6
 Severity:  Normal   | Resolution:
 Keywords:  031-backport, 032-backport,  |  Actual Points:
  033-must, tor-guard, tor-client, tbb-  |
  usability-website, tbb-needs,  |
  033-triage-20180320, 033-included-20180320 |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by asn):

 * status:  needs_review => needs_revision


Comment:

 Marking this as `needs_revision` because at least some of arma's comments
 will require mods to the branch. Will try to do this tomorrow.

--
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] #25347 [Core Tor/Tor]: Tor stops building circuits, and doesn't start when it has enough directory information

[Tor Bug Tracker & Wiki]

#25347: Tor stops building circuits, and doesn't start when it has enough 
directory
information
-+-
 Reporter:  teor |  Owner:  asn
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.6
 Severity:  Normal   | Resolution:
 Keywords:  031-backport, 032-backport,  |  Actual Points:
  033-must, tor-guard, tor-client, tbb-  |
  usability-website, tbb-needs,  |
  033-triage-20180320, 033-included-20180320 |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 And one more:

 (H) You see the
 {{{
   /* Check if we failed at first hop */
 }}}
 clause in circuit_build_failed()?

 All of that stuff looks eerily similar, right? If we proceed with this
 ticket, we should work to unify these two "our first hop failed" cases, so
 we don't try to maintain two parallel versions of what to do.

--
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] #25347 [Core Tor/Tor]: Tor stops building circuits, and doesn't start when it has enough directory information

[Tor Bug Tracker & Wiki]

#25347: Tor stops building circuits, and doesn't start when it has enough 
directory
information
-+-
 Reporter:  teor |  Owner:  asn
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.6
 Severity:  Normal   | Resolution:
 Keywords:  031-backport, 032-backport,  |  Actual Points:
  033-must, tor-guard, tor-client, tbb-  |
  usability-website, tbb-needs,  |
  033-triage-20180320, 033-included-20180320 |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Two more thoughts:

 (F) Are you sure that the proposed branch is related to the topic of this
 ticket? The ticket title and body seem quite different from what the
 branch does. That makes me wonder if maybe we're not actually solving the
 original bug report. :)

 (G) Do we have a handle on how often existing guards respond with reason
 resource-limit? Imagine a Tor client that makes a bunch of circuits often,
 say because it's an active onion service. And let's say on average 5% of
 create cells get a resource-limit response. And let's say we wait 30
 minutes before retrying guard that we marked as down. We're going to churn
 through a *lot* of guards this way, right?

--
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] #25347 [Core Tor/Tor]: Tor stops building circuits, and doesn't start when it has enough directory information

[Tor Bug Tracker & Wiki]

#25347: Tor stops building circuits, and doesn't start when it has enough 
directory
information
-+-
 Reporter:  teor |  Owner:  asn
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.6
 Severity:  Normal   | Resolution:
 Keywords:  031-backport, 032-backport,  |  Actual Points:
  033-must, tor-guard, tor-client, tbb-  |
  usability-website, tbb-needs,  |
  033-triage-20180320, 033-included-20180320 |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Five thoughts:

 (A) if I were designing that patch, I would put the "if
 circuit_get_cpath_opened_len is 0" clause up in
 command_process_destroy_cell(), and then rename the function to the more
 certain entry_guard_sent_destroy_cell(), or maybe something like
 entry_guard_responded_with_destroy_cell(). That way the function is clear
 what it's doing, and it's clear how you're deciding whether to call it,
 and those are kept separate.

 (B) Note that in the ddos mitigation stuff, we refuse circuits from
 overloaders with reason resource-limit (see DOS_CC_DEFENSE_REFUSE_CELL).
 And at least at the time, the goal was to soak up their overload circuits
 at the guard level, i.e. keep them occupied at a point where we're able to
 limit the damage they do. If we implement this ticket, overloader clients
 will immediately skip off to hassle some other guard. Maybe that's ok? Or
 maybe it would be a sad side effect? Maybe we should change the ddos
 mitigation to use some other destroy reason, so we don't trigger
 overloaders to move? I'm not sure what's best, but let's intentionally
 choose something.

 (C) I think you're right that END_CIRC_REASON_HIBERNATING is a good reason
 to include if we're doing this ticket.

 (D) You're fine with circuit_get_cpath_opened_len here, but for your
 future knowledge: I believe clients only get a destroy cell from the guard
 when the guard has failed to establish the first hop. If the circuit fails
 after the guard, clients get a relay truncated cell back. That is,
 destroys currently don't chain back to the client -- if the guard gets a
 destroy from the middle relay, it keeps the circuit open at itself, and
 converts the destroy into a truncated cell to send back. In theory this
 design is to allow clients to say "well ok, how about extending to this
 other relay then", but in practice clients just say "well screw that,
 here's a destroy" and start over.

 (E) For the advanced challenge mode of the game: I wonder if it would be
 useful to distinguish between preemptive circuits that we tried to make,
 where it's actually fine if we don't have them quite yet, vs reactive
 circuits that we tried to make because we have some user request that
 we're trying to handle right now. In the latter case we would want to try
 another guard because we need things to work. But in the former case I
 could imagine waiting for a second or two and *not* falling back to a
 different guard immediately.

--
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] #25347 [Core Tor/Tor]: Tor stops building circuits, and doesn't start when it has enough directory information

[Tor Bug Tracker & Wiki]

#25347: Tor stops building circuits, and doesn't start when it has enough 
directory
information
-+-
 Reporter:  teor |  Owner:  asn
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.6
 Severity:  Normal   | Resolution:
 Keywords:  031-backport, 032-backport,  |  Actual Points:
  033-must, tor-guard, tor-client, tbb-  |
  usability-website, tbb-needs,  |
  033-triage-20180320, 033-included-20180320 |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by asn):

 I did the following chutney testing on the branch above:

 a) I hacked a Tor relay to send a `RESOURCELIMIT` `DESTROY` cell upon
 receiving a `CREATE` cell and made sure that the client would switch
 guards upon seeing the `DESTROY`. Worked.
 b) I hacked a Tor relay to send `RESOURCELIMIT` `DESTROY` cell upon
 receiving a `RELAY` cell (which AFAIK should be after the guard hop has
 been established) and made sure that the client would tear down the
 circuit but '''would not''' mark the guard as unreachable. Worked.

 What other kind of testing would you like to see here?

--
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] #25347 [Core Tor/Tor]: Tor stops building circuits, and doesn't start when it has enough directory information

[Tor Bug Tracker & Wiki]

#25347: Tor stops building circuits, and doesn't start when it has enough 
directory
information
-+-
 Reporter:  teor |  Owner:  asn
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.6
 Severity:  Normal   | Resolution:
 Keywords:  031-backport, 032-backport,  |  Actual Points:
  033-must, tor-guard, tor-client, tbb-  |
  usability-website, tbb-needs,  |
  033-triage-20180320, 033-included-20180320 |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by asn):

 * status:  assigned => needs_review


Comment:

 Thanks for the help people.

 I pushed a branch at `bug25347` in my github repo
 (https://github.com/asn-d6/tor). It basically implements the approach we
 discussed above.

 Unfortunately it's untested. Does anyone have any good hints on how to
 test this? I will be trying to do this today. Will let you know later.

--
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] #25347 [Core Tor/Tor]: Tor stops building circuits, and doesn't start when it has enough directory information

[Tor Bug Tracker & Wiki]

#25347: Tor stops building circuits, and doesn't start when it has enough 
directory
information
-+-
 Reporter:  teor |  Owner:  asn
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.6
 Severity:  Normal   | Resolution:
 Keywords:  031-backport, 032-backport,  |  Actual Points:
  033-must, tor-guard, tor-client, tbb-  |
  usability-website, tbb-needs,  |
  033-triage-20180320, 033-included-20180320 |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by mikeperry):

 Replying to [comment:13 nickm]:
 > You don't even need the flag -- you can check how many open hops the
 circuit has.  If it has >= 1, then it has extended at least one hop, and
 the DESTROY cell might not be from the guard.  If it has 0 open hops, then
 it hasn't extended to the guard yet.

 To clarify, the function (or check) you want to use is
 circuit_get_cpath_opened_len(), not circuit_get_cpath_len(). (This is also
 what dgoulet said in terms of the check, but I wanted to make sure the
 right function is used).

 Wrt why there were no path bias messages -- the path bias code only counts
 circuits that made it to the third hop. This is because it is only
 checking for circuits that fail during tagging, which would allow them to
 survive to the 2nd hop but fail at the 3rd (due to our current lack of any
 MAC mechanism at hop 2). So the lack of those messages is also consistent
 with the guard failing with RESOURCELIMIT from itself.

 Given that, I think it is reasonable to give up on the guard temporarily
 and treat it as if the TLS connection failed: switch to the second guard
 for now, with the hopes of the prop271 code going back to it eventually.

 Yet another case where the adversary or just bad luck can force you to use
 a second guard, but I don't see a way around that. Sitting around waiting
 and doing nothing is arguably even worse, and leaks even more info
 (because for eg, the targeted HS would go down).

--
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] #25347 [Core Tor/Tor]: Tor stops building circuits, and doesn't start when it has enough directory information

[Tor Bug Tracker & Wiki]

#25347: Tor stops building circuits, and doesn't start when it has enough 
directory
information
-+-
 Reporter:  teor |  Owner:  asn
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.6
 Severity:  Normal   | Resolution:
 Keywords:  031-backport, 032-backport,  |  Actual Points:
  033-must, tor-guard, tor-client, tbb-  |
  usability-website, tbb-needs,  |
  033-triage-20180320, 033-included-20180320 |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 You don't even need the flag -- you can check how many open hops the
 circuit has.  If it has >= 1, then it has extended at least one hop, and
 the DESTROY cell might not be from the guard.  If it has 0 open hops, then
 it hasn't extended to the guard yet.

--
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] #25347 [Core Tor/Tor]: Tor stops building circuits, and doesn't start when it has enough directory information

[Tor Bug Tracker & Wiki]

#25347: Tor stops building circuits, and doesn't start when it has enough 
directory
information
-+-
 Reporter:  teor |  Owner:  asn
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.6
 Severity:  Normal   | Resolution:
 Keywords:  031-backport, 032-backport,  |  Actual Points:
  033-must, tor-guard, tor-client, tbb-  |
  usability-website, tbb-needs,  |
  033-triage-20180320, 033-included-20180320 |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by dgoulet):

 Replying to [comment:11 asn]:
 > Nick says that if we get a `DESTROY` cell before we receive a `CREATED`
 cell (or maybe before we send an `EXTEND` cell) we can be sure it comes
 from the guard since there is no one else on the path. I wonder if this is
 easy to figure out in code.

 Code wise this can be simple. You can either add a flag to `circuit_t`
 that says "Got a CREATED" so if True, any DESTROY cell you get, you won't
 be able to tell if Guard or not. I think the other way you can do that is
 walk the `cpath` and see if the first hop is in OPEN state. When you get
 the CREATED cell, see `circuit_finish_handshake()` which will set the hop
 state to OPEN.

 After that, you get the CREATED cell embedded in an EXTENDED cell.

--
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] #25347 [Core Tor/Tor]: Tor stops building circuits, and doesn't start when it has enough directory information

[Tor Bug Tracker & Wiki]

#25347: Tor stops building circuits, and doesn't start when it has enough 
directory
information
-+-
 Reporter:  teor |  Owner:  asn
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.6
 Severity:  Normal   | Resolution:
 Keywords:  031-backport, 032-backport,  |  Actual Points:
  033-must, tor-guard, tor-client, tbb-  |
  usability-website, tbb-needs,  |
  033-triage-20180320, 033-included-20180320 |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by asn):

 Some more info after discussing with Nick:

 Replying to [comment:10 asn]:
 > Like you said, I think the most obvious misbehavior here is that you
 keep on hassling your guard even tho it's telling you to relax by sending
 your `RESOURCELIMIT` `DESTROY` cells. Perhaps one approach here would be
 to choose a different guard after a guard has sent us `RESOURCELIMIT`
 cells, in an attempt to unclog the guard and to get better service.
 '''Let's think about this some more:'''
 >
 > What's the best behavior here? Should we mark the guard as down after
 receiving a single `RESOURCELIMIT` cell, or should we hassle the guard a
 bit before giving up?
 >

 Some reasons to go with the former approach here is:
 a) The way primary guards work, even if we ditch the guard for a single
 `RESOURCELIMIT` cell, we are gonna retry it again after a few minutes.
 Also, after a few minutes there are higher chances that the guard is gonna
 be unclogged since we stopped hassling it.
 b) It will be easier to implement.

 > Most importantly, can we make sure that the `DESTROY` cell came from the
 guard and not from some other node in the path? If we can make sure that
 the `DESTROY` cell came from the guard, this seem to me like a pretty safe
 countermeasure since we should trust the guard to tell us whether it's
 overworked or not.
 >

 Nick says that if we get a `DESTROY` cell before we receive a `CREATED`
 cell (or maybe before we send an `EXTEND` cell) we can be sure it comes
 from the guard since there is no one else on the path. I wonder if this is
 easy to figure out in code.

 Nick also suggested we get feedback from Mike first since he will have
 good ideas on whether this can be bad for anonymity.

--
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] #25347 [Core Tor/Tor]: Tor stops building circuits, and doesn't start when it has enough directory information

[Tor Bug Tracker & Wiki]

#25347: Tor stops building circuits, and doesn't start when it has enough 
directory
information
-+-
 Reporter:  teor |  Owner:  asn
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.6
 Severity:  Normal   | Resolution:
 Keywords:  031-backport, 032-backport,  |  Actual Points:
  033-must, tor-guard, tor-client, tbb-  |
  usability-website, tbb-needs,  |
  033-triage-20180320, 033-included-20180320 |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by asn):

 Thanks for the info s7r. I took another look at your logs (after my
 comment:5) and at your latest comment.

 Looking at your logs, it seems like your guard rejected about 230 new
 circuit creations in 15 minutes with the excuse of `RESOURCELIMIT`. And
 your client just kept making more and more circuits to the same guard that
 were getting rejected... I've also noticed this exact same behavior on a
 client of mine recently.

 My theory on why `RESOURCELIMIT` was used by your guard (given that you
 say that DoS patch was disabled) is that `assign_onionskin_to_cpuworker()`
 failed because `onion_pending_add()` failed because
 `have_room_for_onionskin()` failed. That means that the relay was
 overworked and had way too many cells to process at that time.
 Unfortunately, I can't see whether you are sending NTOR or TAP cells given
 your logs.

 Like you said, I think the most obvious misbehavior here is that you keep
 on hassling your guard even tho it's telling you to relax by sending your
 `RESOURCELIMIT` `DESTROY` cells. Perhaps one approach here would be to
 choose a different guard after a guard has sent us `RESOURCELIMIT` cells,
 in an attempt to unclog the guard and to get better service. '''Let's
 think about this some more:'''

 What's the best behavior here? Should we mark the guard as down after
 receiving a single `RESOURCELIMIT` cell, or should we hassle the guard a
 bit before giving up?

 Most importantly, can we make sure that the `DESTROY` cell came from the
 guard and not from some other node in the path? If we can make sure that
 the `DESTROY` cell came from the guard, this seem to me like a pretty safe
 countermeasure since we should trust the guard to tell us whether it's
 overworked or not.

 WRT timeline here, I think working on this countermeasure (mark guard as
 down when overworked to get better service) seems like a plausible goal
 for 033, but anything more involved will probably need to wait for 034.

 Would appreciate feedback from Nick or Tim here :)

 

 I still can't explain why you managed to bootstrap after hacking your
 state file tho. Perhaps a coincidence? Perhaps you were overworking your
 guard and when you stopped, it relaxed? Perhaps the hack worked
 differently than you imagine? Not sure.

--
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] #25347 [Core Tor/Tor]: Tor stops building circuits, and doesn't start when it has enough directory information

[Tor Bug Tracker & Wiki]

#25347: Tor stops building circuits, and doesn't start when it has enough 
directory
information
-+-
 Reporter:  teor |  Owner:  asn
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.6
 Severity:  Normal   | Resolution:
 Keywords:  031-backport, 032-backport,  |  Actual Points:
  033-must, tor-guard, tor-client, tbb-  |
  usability-website, tbb-needs,  |
  033-triage-20180320, 033-included-20180320 |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by asn):

 * owner:  (none) => asn
 * status:  new => assigned


--
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] #25347 [Core Tor/Tor]: Tor stops building circuits, and doesn't start when it has enough directory information

[Tor Bug Tracker & Wiki]

#25347: Tor stops building circuits, and doesn't start when it has enough 
directory
information
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.6
 Severity:  Normal   | Resolution:
 Keywords:  031-backport, 032-backport,  |  Actual Points:
  033-must, tor-guard, tor-client, tbb-  |
  usability-website, tbb-needs   |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by s7r):

 All 3 guards in the primary set were running Tor versions that do not have
 the DoS patch, so this can be eliminated.

 In regards to the 1/3 primary guard being overworked, I can't prove wrong,
 but:
 - usually this is warned in the client log "your guard X is failing a
 larger amount of circuits than usual. success counts are x/y - this could
 indicate an attack but also mean that the Tor network is overloaded ..." -
 there were no such messages in the client log;

 - why does it not heal by itself even in ~7 hours? Shouldn't it either
 move to another guard or do something, rather than keep running in an
 useless state?

 Some more interesting stuff:
 - checked all 3 guards in the primary set and they were behaving normally,
 running in consensus with good bandwidth values;

 - after starting with a new fresh state file (like starting from scratch),
 Tor selected new primary guards and connected just fine. So I turned it
 off, manually edited the state file and put back at `confirmed_idx=0` the
 same previous guard that was hanging before (with the old state file).
 Started it again, and it was working like nothing happened. Could it be a
 coincidence that for 7 hours that particular guard was overworked and
 failing circuits, and after 5 minutes when I edit the new state file it
 comes back to normal operation? Possible, non-zero chance for this to be
 true, but I wouldn't bet on it.

 teor said on irc that we might be doing something with the state file or
 the mds of the primary guards. I tend to think in the same direction.
 Right now I am trying to reproduce it so I can provide two state files:
 the good working state file and the not working one, with the same primary
 guards maybe they will help us determine what is going in.

 I think this is the same bug reported by cypherpunks on the parent ticket
 and by alec, so it might be the last annoying guard bug.

--
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] #25347 [Core Tor/Tor]: Tor stops building circuits, and doesn't start when it has enough directory information

[Tor Bug Tracker & Wiki]

#25347: Tor stops building circuits, and doesn't start when it has enough 
directory
information
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.6
 Severity:  Normal   | Resolution:
 Keywords:  031-backport, 032-backport,  |  Actual Points:
  033-must, tor-guard, tor-client, tbb-  |
  usability-website, tbb-needs   |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by asn):

 Thanks for the logs. Looking at `info_25347.zip​`, I see that after
 bootstrapping to 90% we failed about 80 circuits with:
 {{{
 circuit_mark_for_close_(): Circuit 0 (id: 8) marked for close at
 command.c:589 (orig reason: 517, new reason: 0)
 }}}

 IIUC, this means that the client received a DESTROY cell (from the guard?)
 with reason `END_CIRC_REASON_RESOURCELIMIT`. `RESOURCELIMIT` is an
 interesting reason to receive because it's the one that the DoS subsystem
 uses, but can also be caused by other kind of failures.

--
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] #25347 [Core Tor/Tor]: Tor stops building circuits, and doesn't start when it has enough directory information

[Tor Bug Tracker & Wiki]

#25347: Tor stops building circuits, and doesn't start when it has enough 
directory
information
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.6
 Severity:  Normal   | Resolution:
 Keywords:  031-backport, 032-backport,  |  Actual Points:
  033-must, tor-guard, tor-client, tbb-  |
  usability-website, tbb-needs   |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by s7r):

 Usually when guards stop responding Tor logs a message that guard X is
 failing more circuits than usual.

 I have the guards versions yes, they are all 3 online with no downtime in
 the last days.

 Guard 1/3: Tor 0.2.5.16
 Guard 2/3: Tor 0.2.9.14
 Guard 3/3: Tor 0.2.9.14

--
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] #25347 [Core Tor/Tor]: Tor stops building circuits, and doesn't start when it has enough directory information

[Tor Bug Tracker & Wiki]

#25347: Tor stops building circuits, and doesn't start when it has enough 
directory
information
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.6
 Severity:  Normal   | Resolution:
 Keywords:  031-backport, 032-backport,  |  Actual Points:
  033-must, tor-guard, tor-client, tbb-  |
  usability-website, tbb-needs   |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 I wonder if (both?) your guards stopped responding to your extend
 requests, due to a DDoS defence? (Or due to overload?)
 Do you still have your old guard state?
 What are the versions of your guards?

--
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] #25347 [Core Tor/Tor]: Tor stops building circuits, and doesn't start when it has enough directory information

[Tor Bug Tracker & Wiki]

#25347: Tor stops building circuits, and doesn't start when it has enough 
directory
information
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.6
 Severity:  Normal   | Resolution:
 Keywords:  031-backport, 032-backport,  |  Actual Points:
  033-must, tor-guard, tor-client, tbb-  |
  usability-website, tbb-needs   |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by s7r):

 Looks like it's more serious.
 So the jammed Tor instance that generated the logs in #21969 never healed
 even after 7 hours of waiting. Was running TBB 7.5 so it was Tor 0.3.2.9.

 Switched to info log level, closed TBB and launched again. Tor launcher
 never fully load, and was just blocked in the loading state with text
 "Establishing a Tor circuit". Captured and attached a screenshot for this.
 I gathered info log for few minutes in this state, and terminated by
 clicking cancel on Tor launcher.

 Then I switched to debug log level and launched again. Tor launcher
 remained blocked at the same loading level as before. I left it in this
 state and gathered debug logs for about 20 minutes, then clicked cancel on
 Tor launcher to close.

 Tried about 5 more times, still the same result. The only thing that fixed
 it was the deletion of the '''state''' file. After I deleted the state
 file, Tor launcher fully loaded in about 3 seconds and browsing went on
 just fine.

--
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] #25347 [Core Tor/Tor]: Tor stops building circuits, and doesn't start when it has enough directory information

[Tor Bug Tracker & Wiki]

#25347: Tor stops building circuits, and doesn't start when it has enough 
directory
information
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.6
 Severity:  Normal   | Resolution:
 Keywords:  031-backport, 032-backport,  |  Actual Points:
  033-must, tor-guard, tor-client, tbb-  |
  usability-website, tbb-needs   |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by s7r):

 * Attachment "info_25347.zip" added.


--
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] #25347 [Core Tor/Tor]: Tor stops building circuits, and doesn't start when it has enough directory information

[Tor Bug Tracker & Wiki]

#25347: Tor stops building circuits, and doesn't start when it has enough 
directory
information
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.6
 Severity:  Normal   | Resolution:
 Keywords:  031-backport, 032-backport,  |  Actual Points:
  033-must, tor-guard, tor-client, tbb-  |
  usability-website, tbb-needs   |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by s7r):

 * Attachment "debug_25347.zip" added.


--
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] #25347 [Core Tor/Tor]: Tor stops building circuits, and doesn't start when it has enough directory information

[Tor Bug Tracker & Wiki]

#25347: Tor stops building circuits, and doesn't start when it has enough 
directory
information
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.6
 Severity:  Normal   | Resolution:
 Keywords:  031-backport, 032-backport,  |  Actual Points:
  033-must, tor-guard, tor-client, tbb-  |
  usability-website, tbb-needs   |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by s7r):

 * Attachment "tbb-hang-253347.png" added.


--
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] #25347 [Core Tor/Tor]: Tor stops building circuits, and doesn't start when it has enough directory information

[Tor Bug Tracker & Wiki]

#25347: Tor stops building circuits, and doesn't start when it has enough 
directory
information
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.6
 Severity:  Normal   | Resolution:
 Keywords:  031-backport, 032-backport,  |  Actual Points:
  033-must, tor-guard, tor-client, tbb-  |
  usability-website, tbb-needs   |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:  033-must, tor-guard, tor-client, tbb-usability-website, tbb-
 needs =>
 031-backport, 032-backport, 033-must, tor-guard, tor-client, tbb-
 usability-website, tbb-needs


Comment:

 I think we just need to fix #25347 in 0.3.3, all the other related tickets
 are ok.
 And when we fix it. We should backport to 031 and 032.

--
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

[tor-bugs] #25347 [Core Tor/Tor]: Tor stops building circuits, and doesn't start when it has enough directory information

[Tor Bug Tracker & Wiki]

#25347: Tor stops building circuits, and doesn't start when it has enough 
directory
information
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core |Version:  Tor: 0.3.0.6
  Tor/Tor|   Keywords:  033-must, tor-guard, tor-client,
 Severity:  Normal   |  tbb-usability-website, tbb-needs
Actual Points:   |  Parent ID:  #21969
   Points:  1|   Reviewer:
  Sponsor:   |
-+-
 When Tor can't download microdescriptors (#21969), maybe it should try
 authorities or fallbacks (#23863), before it runs out of microdesc retries
 (#24113).

 But even after Tor has the microdescs it needs, it sometimes doesn't start
 building circuits again. Instead, it is in state "waiting for circuit".

 For the log messages, see:
 https://trac.torproject.org/projects/tor/ticket/21969#comment:82

--
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