subject:"\[tor\-bugs\] #22400 \[Core Tor\/Tor\]\: We bootstrap from different primary guards when we start with a non\-live consensus and not enough guards in the state file"

Re: [tor-bugs] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

2018-02-07 Thread Tor Bug Tracker & Wiki

#22400: We bootstrap from different primary guards when we start with a non-live
consensus and not enough guards in the state file
-+-
 Reporter:  arma |  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.7
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-client, tor-guard, bootstrap,|  Actual Points:
  s8-errors  |
Parent ID:   | Points:  3
 Reviewer:  asn  |Sponsor:
 |  Sponsor8-can
-+-
Changes (by asn):

 * status:  needs_information => closed
 * resolution:   => fixed


Comment:

 Seems like this is done now. Closing.

--
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] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

2017-11-15 Thread Tor Bug Tracker & Wiki

#22400: We bootstrap from different primary guards when we start with a non-live
consensus and not enough guards in the state file
-+-
 Reporter:  arma |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.7
 Severity:  Normal   | Resolution:
 Keywords:  tor-client tor-guard 030-backport|  Actual Points:
  bootstrap s8-errors|
Parent ID:   | Points:  3
 Reviewer:  asn  |Sponsor:
 |  Sponsor8-can
-+-
Changes (by catalyst):

 * keywords:  tor-client tor-guard 030-backport bootstrap => tor-client tor-
 guard 030-backport bootstrap s8-errors
 * sponsor:   => Sponsor8-can


--
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] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

2017-11-15 Thread Tor Bug Tracker & Wiki

#22400: We bootstrap from different primary guards when we start with a non-live
consensus and not enough guards in the state file
-+-
 Reporter:  arma |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.7
 Severity:  Normal   | Resolution:
 Keywords:  tor-client tor-guard 030-backport|  Actual Points:
  bootstrap  |
Parent ID:   | Points:  3
 Reviewer:  asn  |Sponsor:
-+-
Changes (by catalyst):

 * cc: catalyst (added)
 * keywords:  tor-client tor-guard 030-backport => tor-client tor-guard
 030-backport bootstrap


--
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] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

2017-09-06 Thread Tor Bug Tracker & Wiki

#22400: We bootstrap from different primary guards when we start with a non-live
consensus and not enough guards in the state file
---+---
 Reporter:  arma   |  Owner:  nickm
 Type:  defect | Status:
   |  needs_information
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.0.7
 Severity:  Normal | Resolution:
 Keywords:  tor-client tor-guard 030-backport  |  Actual Points:
Parent ID: | Points:  3
 Reviewer:  asn|Sponsor:
---+---
Changes (by nickm):

 * status:  accepted => needs_information
 * cc: arma (added)
 * milestone:  Tor: 0.3.1.x-final => Tor: 0.3.3.x-final


Comment:

 Roger, did you want to say more here?  If not we should just close 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] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

2017-07-16 Thread Tor Bug Tracker & Wiki

#22400: We bootstrap from different primary guards when we start with a non-live
consensus and not enough guards in the state file
---+---
 Reporter:  arma   |  Owner:  nickm
 Type:  defect | Status:  accepted
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.1.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.0.7
 Severity:  Normal | Resolution:
 Keywords:  tor-client tor-guard 030-backport  |  Actual Points:
Parent ID: | Points:  3
 Reviewer:  asn|Sponsor:
---+---

Comment (by cypherpunks):

 > Are you quite sure?

 I mean patch for this bug used "reasonably live" that was
 networkstatus_valid_until_is_reasonably_live originally and changelog was
 accurate, later patch was transformed to use live_consensus_is_missing()
 which calls networkstatus_get_live_consensus() and now it's about strongly
 live consensus (not reasonably live) with 3 hours not 1 day. Isn't?

--
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] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

2017-07-16 Thread Tor Bug Tracker & Wiki

#22400: We bootstrap from different primary guards when we start with a non-live
consensus and not enough guards in the state file
---+---
 Reporter:  arma   |  Owner:  nickm
 Type:  defect | Status:  accepted
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.1.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.0.7
 Severity:  Normal | Resolution:
 Keywords:  tor-client tor-guard 030-backport  |  Actual Points:
Parent ID: | Points:  3
 Reviewer:  asn|Sponsor:
---+---

Comment (by nickm):

 Replying to [comment:19 cypherpunks]:
 > > "reasonably live" (under 1 day old)
 >
 > No. "Reasonably live" is about valid_after <= now <= valid_until. 3
 hours range by default.

 Are you quite sure? See `networkstatus_valid_until_is_reasonably_live` in
 networkstatus.c

--
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] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

2017-07-16 Thread Tor Bug Tracker & Wiki

#22400: We bootstrap from different primary guards when we start with a non-live
consensus and not enough guards in the state file
---+---
 Reporter:  arma   |  Owner:  nickm
 Type:  defect | Status:  accepted
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.1.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.0.7
 Severity:  Normal | Resolution:
 Keywords:  tor-client tor-guard 030-backport  |  Actual Points:
Parent ID: | Points:  3
 Reviewer:  asn|Sponsor:
---+---

Comment (by cypherpunks):

 > "reasonably live" (under 1 day old)

 No. "Reasonably live" is about valid_after <= now <= valid_until. 3 hours
 range by default.

--
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] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

2017-06-22 Thread Tor Bug Tracker & Wiki

#22400: We bootstrap from different primary guards when we start with a non-live
consensus and not enough guards in the state file
---+---
 Reporter:  arma   |  Owner:  nickm
 Type:  defect | Status:  accepted
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.1.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.0.7
 Severity:  Normal | Resolution:
 Keywords:  tor-client tor-guard 030-backport  |  Actual Points:
Parent ID: | Points:  3
 Reviewer:  asn|Sponsor:
---+---
Changes (by nickm):

 * status:  merge_ready => accepted


Comment:

 Thank you, asn! Merging to 0.3.0 and forward.

 I'm putting this back in "accept" since I believe Roger has more to add.

--
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] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

2017-06-22 Thread Tor Bug Tracker & Wiki

#22400: We bootstrap from different primary guards when we start with a non-live
consensus and not enough guards in the state file
---+---
 Reporter:  arma   |  Owner:  nickm
 Type:  defect | Status:
   |  merge_ready
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.1.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.0.7
 Severity:  Normal | Resolution:
 Keywords:  tor-client tor-guard 030-backport  |  Actual Points:
Parent ID: | Points:  3
 Reviewer:  asn|Sponsor:
---+---
Changes (by asn):

 * status:  needs_review => merge_ready


Comment:

 Replying to [comment:16 nickm]:
 > I think we do need both checks; without a live consensus, we don't want
 to expand the list _or_ change its members' status.
 >
 > The checks are slightly different; for expand it was "reasonably live"
 and for change status it's "live". I think that maybe they should both
 become "live"; let's try that.
 >
 > What do you think of the commit I just added to the branch?

 Makes sense. I like it more this way and less code dup.

 I tested it with an old consensus from collector, and tor correctly
 declined to add any guards to the sampled set before fetching a new
 consensus.

 Marking this branch as `merge_ready`.

--
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] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

2017-06-22 Thread Tor Bug Tracker & Wiki

#22400: We bootstrap from different primary guards when we start with a non-live
consensus and not enough guards in the state file
---+---
 Reporter:  arma   |  Owner:  nickm
 Type:  defect | Status:
   |  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.1.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.0.7
 Severity:  Normal | Resolution:
 Keywords:  tor-client tor-guard 030-backport  |  Actual Points:
Parent ID: | Points:  3
 Reviewer:  asn|Sponsor:
---+---

Comment (by nickm):

 I think we do need both checks; without a live consensus, we don't want to
 expand the list _or_ change its members' status.

 The checks are slightly different; for expand it was "reasonably live" and
 for change status it's "live". I think that maybe they should both become
 "live"; let's try that.

 What do you think of the commit I just added to the branch?

--
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] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

2017-06-22 Thread Tor Bug Tracker & Wiki

#22400: We bootstrap from different primary guards when we start with a non-live
consensus and not enough guards in the state file
---+---
 Reporter:  arma   |  Owner:  nickm
 Type:  defect | Status:
   |  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.1.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.0.7
 Severity:  Normal | Resolution:
 Keywords:  tor-client tor-guard 030-backport  |  Actual Points:
Parent ID: | Points:  3
 Reviewer:  asn|Sponsor:
---+---

Comment (by asn):

 Patch looks reasonable for what it's trying to do, but I think we now have
 two very similar logics: the one we just added, and the one that already
 exists in `sampled_guards_update_from_consensus()`:
 {{{
   // It's important to use only a live consensus here; we don't want to
   // make changes based on anything expired or old.
   if (gs->type != GS_TYPE_BRIDGE) {
 networkstatus_t *ns = networkstatus_get_live_consensus(approx_time());

 if (! ns) {
   log_info(LD_GUARD, "No live consensus; can't update "
"sampled entry guards.");
   return;
 } else {
   log_info(LD_GUARD, "Updating sampled guard status based on received
 "
"consensus.");
 }
   }
 }}}

 Do we need both checks? If yes, can we functionify 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] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

2017-06-21 Thread Tor Bug Tracker & Wiki

#22400: We bootstrap from different primary guards when we start with a non-live
consensus and not enough guards in the state file
---+---
 Reporter:  arma   |  Owner:  nickm
 Type:  defect | Status:
   |  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.1.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.0.7
 Severity:  Normal | Resolution:
 Keywords:  tor-client tor-guard 030-backport  |  Actual Points:
Parent ID: | Points:  3
 Reviewer:  asn|Sponsor:
---+---
Changes (by asn):

 * reviewer:   => asn


--
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] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

2017-06-19 Thread Tor Bug Tracker & Wiki

#22400: We bootstrap from different primary guards when we start with a non-live
consensus and not enough guards in the state file
---+---
 Reporter:  arma   |  Owner:  nickm
 Type:  defect | Status:
   |  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.1.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.0.7
 Severity:  Normal | Resolution:
 Keywords:  tor-client tor-guard 030-backport  |  Actual Points:
Parent ID: | Points:  3
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

 * keywords:  tor-client gor-guard 030-backport => tor-client tor-guard
 030-backport


--
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] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

2017-06-19 Thread Tor Bug Tracker & Wiki

#22400: We bootstrap from different primary guards when we start with a non-live
consensus and not enough guards in the state file
---+---
 Reporter:  arma   |  Owner:  nickm
 Type:  defect | Status:
   |  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.1.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.0.7
 Severity:  Normal | Resolution:
 Keywords:  tor-client gor-guard 030-backport  |  Actual Points:
Parent ID: | Points:  3
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

 * status:  accepted => needs_review
 * keywords:   => tor-client gor-guard 030-backport
 * points:   => 3


Comment:

 So, the main root bug here is fixed in my branch `bug22400_030_01`.  (I'll
 let #4187 speak for itself.)

 I have a corresponding spec change in branch `bug22400_01` in torspec.

--
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] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

2017-06-16 Thread Tor Bug Tracker & Wiki

#22400: We bootstrap from different primary guards when we start with a non-live
consensus and not enough guards in the state file
--+
 Reporter:  arma  |  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.7
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


--
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] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

2017-06-16 Thread Tor Bug Tracker & Wiki

#22400: We bootstrap from different primary guards when we start with a non-live
consensus and not enough guards in the state file
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.7
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Diagnosis:  The "Loaded an expired consensus. Discarding" message is a red
 herring; that is talking about a cached unverified consensus, as evidenced
 by the next line, "Couldn't load unverified consensus microdesc
 networkstatus from cache."

 What's actually going on here is that we _are_ accepting a slightly old
 consensus.  The expiration check is:
 {{{
   if (from_cache && !accept_obsolete &&
   c->valid_until < now-OLD_ROUTER_DESC_MAX_AGE) {
 log_info(LD_DIR, "Loaded an expired consensus. Discarding.");
 goto done;
   }
 }}}
 with the relevant constant defined as
 {{{
 #define OLD_ROUTER_DESC_MAX_AGE (60*60*24*5)
 }}}


 So, one bug here is that a really old unverified consensus got left
 around.  We have a ticket for that from 2011 (#4187)!

 One other bug is that we're expanding our guard sample even though the
 consensus is a few days out of date.

--
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] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

2017-06-02 Thread Tor Bug Tracker & Wiki

#22400: We bootstrap from different primary guards when we start with a non-live
consensus and not enough guards in the state file
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.7
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by s7r):

 * cc: s7r (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] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

2017-05-31 Thread Tor Bug Tracker & Wiki

#22400: We bootstrap from different primary guards when we start with a non-live
consensus and not enough guards in the state file
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.7
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by asn):

 * cc: asn (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] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

2017-05-25 Thread Tor Bug Tracker & Wiki

#22400: We bootstrap from different primary guards when we start with a non-live
consensus and not enough guards in the state file
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.7
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Old description:

> I started my Tor client (0.3.1.1-alpha (git-ab9976b7245f05a9)) with these
> three guards (and only these three guards) in my state file:
> {{{
> Guard in=default rsa_id=BB119A5A4D5DA2BBB7B796ECC50E3C0F1D4FD910
> nickname=onslaught sampled_on=2017-04-29T09:28:05 sampled_by=0.3.1.0
> -alpha-dev listed=1 confirmed_on=2017-05-02T22:48:40 confirmed_idx=1
> Guard in=default rsa_id=7369A0E14C59B11D78357EC5AFE573A259264BBD
> nickname=yono1 sampled_on=2017-05-02T20:44:35 sampled_by=0.3.1.0-alpha-
> dev listed=1 confirmed_on=2017-04-25T13:14:11 confirmed_idx=0
> pb_use_attempts=3.00 pb_use_successes=3.00
> pb_circ_attempts=105.00 pb_circ_successes=105.00
> pb_successful_circuits_closed=95.00 pb_collapsed_circuits=10.00
> pb_timeouts=8.00
> Guard in=default rsa_id=62DA0256BBC28992D41CBAFB549FFD7C9B846A99
> nickname=IRejectTorFoundatnN sampled_on=2017-05-21T02:25:50
> sampled_by=0.3.1.0-alpha-dev listed=1 confirmed_on=2017-05-23T22:28:05
> confirmed_idx=2
> }}}
>
> I figured that since there were three, and they were all confirmed, they
> would be my primary guards.
>
> Also, my cached-microdesc-consensus file was about a day old.
>
> When Tor starts, it says
> {{{
> May 25 20:58:06.155 [info] sampled_guards_update_from_consensus(): No
> live consensus; can't update sampled entry guards.
> }}}
> Ok, great, it's not going to go deleting or modifying any of my guards
> before it's even tried to load my consensus file from disk. Makes sense.
>
> Then it goes through to update my three guards to say that they're not
> working:
> {{{
> May 25 20:58:06.155 [debug] entry_guard_set_filtered_flags(): Updated
> sampled guard onslaught ($BB119A5A4D5DA2BBB7B796ECC50E3C0F1D4FD910):
> filtered=0; reachable_filtered=0.
> May 25 20:58:06.155 [debug] entry_guard_set_filtered_flags(): Updated
> sampled guard yono1 ($7369A0E14C59B11D78357EC5AFE573A259264BBD):
> filtered=0; reachable_filtered=0.
> May 25 20:58:06.156 [debug] entry_guard_set_filtered_flags(): Updated
> sampled guard IRejectTorFoundatnN
> ($62DA0256BBC28992D41CBAFB549FFD7C9B846A99): filtered=0;
> reachable_filtered=0.
> }}}
> I'm guessing that happened because of entry_guards_update_filtered_sets()
> which got called from entry_guards_update_all(), but there are several
> possible paths to that function so I'm not sure which one it was. Maybe
> it's decided they're all down, since it hasn't even loaded a consensus
> yet, so they're all missing from the nonexistent consensus?
>
> Then we get to:
> {{{
> May 25 20:58:06.156 [info] sample_reachable_filtered_entry_guards():
> Trying to sample a reachable guard: We know of 0 in the USABLE_FILTERED
> set.
> May 25 20:58:06.156 [info] sample_reachable_filtered_entry_guards():
> (That isn't enough. Trying to expand the sample.)
> May 25 20:58:06.156 [info] entry_guards_expand_sample(): Expanding the
> sample guard set. We have 3 guards in the sample, and 0 eligible guards
> to extend it with.
> May 25 20:58:06.156 [info] entry_guards_expand_sample(): Not expanding
> the guard sample any further; just ran out of eligible guards
> May 25 20:58:06.156 [info] sample_reachable_filtered_entry_guards():
> (After filters [b], we have 0 guards to consider.)
> }}}
> Ok, great, we refuse to expand the guard list now. That's good because we
> don't have any consensus loaded yet.
>
> Then I finish loading the state file, and load other stuff from my
> datadirectory, like the cached-microdesc-consensus file:
> {{{
> May 25 20:58:06.644 [info] A consensus needs 5 good signatures from
> recognized authorities for us to accept it. This one has 8 (dannenberg
> tor26 longclaw maatuska moria1 dizum gabelmoo Faravahar).
> May 25 20:58:06.797 [info] microdesc_cache_reload(): Reloaded
> microdescriptor cache. Found 7298 descriptors.
> May 25 20:58:06.812 [info]
> update_consensus_networkstatus_fetch_time_impl(): No live microdesc
> consensus; we should fetch one immediately.
> May 25 20:58:06.812 [info] cell_ewma_set_scale_factor(): Enabled
> cell_ewma algorithm because of value in CircuitPriorityHalflifeMsec in
> consensus; scale factor is 0.793701 per 10 seconds
> May 25 20:58:07.046 [info] networkstatus_set_current_consensus(): Loaded
> an expired consensus. Discarding.
> May 25 20:58:07.046 [info] router_reload_consensus_networkstatus():
> Couldn't load

Re: [tor-bugs] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

2017-05-25 Thread Tor Bug Tracker & Wiki

#22400: We bootstrap from different primary guards when we start with a non-live
consensus and not enough guards in the state file
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.7
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [comment:4 teor]:
 > Replying to [ticket:22400 arma]:
 > > And it launches a parallel fetch to an authority too, just like it's
 supposed to:
 > > {{{
 > > May 25 20:58:07.185 [info] directory_send_command(): Downloading
 consensus from 154.35.175.225:443 using /tor/status-vote/current
 /consensus-
 microdesc/0232AF+14C131+23D15D+49015F+D586D1+E8A9C4+ED03BB+EFCBE7.z
 > > }}}
 >
 > No, that's a bug: #20604.
 >
 > There's no need for every client to contact an authority: they didn't in
 0.2.8, and they all worked fine. But when the exponential backoff code was
 merged, there was no provision for a set initial delay, and we couldn't
 define the schedules so that we'd get a short delay without blowing out
 the remaining attempts. So we got this compromise.

 Sorry, I was wrong.

 This happened because we never reset download statuses before we use them.
 See #17750.

--
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] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

2017-05-25 Thread Tor Bug Tracker & Wiki

#22400: We bootstrap from different primary guards when we start with a non-live
consensus and not enough guards in the state file
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.7
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 (It could be argued, though, that it's better to have more load on the
 directory authorities rather than clients waiting for 10 seconds when the
 3 fallbacks they choose are down. Someone else can work that one out!)

--
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] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

2017-05-25 Thread Tor Bug Tracker & Wiki

#22400: We bootstrap from different primary guards when we start with a non-live
consensus and not enough guards in the state file
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.7
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Old description:

> I started my Tor client (0.3.1.1-alpha (git-ab9976b7245f05a9)) with these
> three guards (and only these three guards) in my state file:
> {{{
> Guard in=default rsa_id=BB119A5A4D5DA2BBB7B796ECC50E3C0F1D4FD910
> nickname=onslaught sampled_on=2017-04-29T09:28:05 sampled_by=0.3.1.0
> -alpha-dev listed=1 confirmed_on=2017-05-02T22:48:40 confirmed_idx=1
> Guard in=default rsa_id=7369A0E14C59B11D78357EC5AFE573A259264BBD
> nickname=yono1 sampled_on=2017-05-02T20:44:35 sampled_by=0.3.1.0-alpha-
> dev listed=1 confirmed_on=2017-04-25T13:14:11 confirmed_idx=0
> pb_use_attempts=3.00 pb_use_successes=3.00
> pb_circ_attempts=105.00 pb_circ_successes=105.00
> pb_successful_circuits_closed=95.00 pb_collapsed_circuits=10.00
> pb_timeouts=8.00
> Guard in=default rsa_id=62DA0256BBC28992D41CBAFB549FFD7C9B846A99
> nickname=IRejectTorFoundatnN sampled_on=2017-05-21T02:25:50
> sampled_by=0.3.1.0-alpha-dev listed=1 confirmed_on=2017-05-23T22:28:05
> confirmed_idx=2
> }}}
>
> I figured that since there were three, and they were all confirmed, they
> would be my primary guards.
>
> Also, my cached-microdesc-consensus file was about a day old.
>
> When Tor starts, it says
> {{{
> May 25 20:58:06.155 [info] sampled_guards_update_from_consensus(): No
> live consensus; can't update sampled entry guards.
> }}}
> Ok, great, it's not going to go deleting or modifying any of my guards
> before it's even tried to load my consensus file from disk. Makes sense.
>
> Then it goes through to update my three guards to say that they're not
> working:
> {{{
> May 25 20:58:06.155 [debug] entry_guard_set_filtered_flags(): Updated
> sampled guard onslaught ($BB119A5A4D5DA2BBB7B796ECC50E3C0F1D4FD910):
> filtered=0; reachable_filtered=0.
> May 25 20:58:06.155 [debug] entry_guard_set_filtered_flags(): Updated
> sampled guard yono1 ($7369A0E14C59B11D78357EC5AFE573A259264BBD):
> filtered=0; reachable_filtered=0.
> May 25 20:58:06.156 [debug] entry_guard_set_filtered_flags(): Updated
> sampled guard IRejectTorFoundatnN
> ($62DA0256BBC28992D41CBAFB549FFD7C9B846A99): filtered=0;
> reachable_filtered=0.
> }}}
> I'm guessing that happened because of entry_guards_update_filtered_sets()
> which got called from entry_guards_update_all(), but there are several
> possible paths to that function so I'm not sure which one it was. Maybe
> it's decided they're all down, since it hasn't even loaded a consensus
> yet, so they're all missing from the nonexistent consensus?
>
> Then we get to:
> {{{
> May 25 20:58:06.156 [info] sample_reachable_filtered_entry_guards():
> Trying to sample a reachable guard: We know of 0 in the USABLE_FILTERED
> set.
> May 25 20:58:06.156 [info] sample_reachable_filtered_entry_guards():
> (That isn't enough. Trying to expand the sample.)
> May 25 20:58:06.156 [info] entry_guards_expand_sample(): Expanding the
> sample guard set. We have 3 guards in the sample, and 0 eligible guards
> to extend it with.
> May 25 20:58:06.156 [info] entry_guards_expand_sample(): Not expanding
> the guard sample any further; just ran out of eligible guards
> May 25 20:58:06.156 [info] sample_reachable_filtered_entry_guards():
> (After filters [b], we have 0 guards to consider.)
> }}}
> Ok, great, we refuse to expand the guard list now. That's good because we
> don't have any consensus loaded yet.
>
> Then I finish loading the state file, and load other stuff from my
> datadirectory, like the cached-microdesc-consensus file:
> {{{
> May 25 20:58:06.644 [info] A consensus needs 5 good signatures from
> recognized authorities for us to accept it. This one has 8 (dannenberg
> tor26 longclaw maatuska moria1 dizum gabelmoo Faravahar).
> May 25 20:58:06.797 [info] microdesc_cache_reload(): Reloaded
> microdescriptor cache. Found 7298 descriptors.
> May 25 20:58:06.812 [info]
> update_consensus_networkstatus_fetch_time_impl(): No live microdesc
> consensus; we should fetch one immediately.
> May 25 20:58:06.812 [info] cell_ewma_set_scale_factor(): Enabled
> cell_ewma algorithm because of value in CircuitPriorityHalflifeMsec in
> consensus; scale factor is 0.793701 per 10 seconds
> May 25 20:58:07.046 [info] networkstatus_set_current_consensus(): Loaded
> an expired consensus. Discarding.
> May 25 20:58:07.046 [info] router_reload_consensus_networkstatus():
> Couldn't load

Re: [tor-bugs] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

2017-05-25 Thread Tor Bug Tracker & Wiki

#22400: We bootstrap from different primary guards when we start with a non-live
consensus and not enough guards in the state file
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.7
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Description changed by arma:

Old description:

> I started my Tor client (0.3.1.1-alpha (git-ab9976b7245f05a9)) with these
> three guards (and only these three guards) in my state file:
> {{{
> Guard in=default rsa_id=BB119A5A4D5DA2BBB7B796ECC50E3C0F1D4FD910
> nickname=onslaught sampled_on=2017-04-29T09:28:05 sampled_by=0.3.1.0
> -alpha-dev listed=1 confirmed_on=2017-05-02T22:48:40 confirmed_idx=1
> Guard in=default rsa_id=7369A0E14C59B11D78357EC5AFE573A259264BBD
> nickname=yono1 sampled_on=2017-05-02T20:44:35 sampled_by=0.3.1.0-alpha-
> dev listed=1 confirmed_on=2017-04-25T13:14:11 confirmed_idx=0
> pb_use_attempts=3.00 pb_use_successes=3.00
> pb_circ_attempts=105.00 pb_circ_successes=105.00
> pb_successful_circuits_closed=95.00 pb_collapsed_circuits=10.00
> pb_timeouts=8.00
> Guard in=default rsa_id=62DA0256BBC28992D41CBAFB549FFD7C9B846A99
> nickname=IRejectTorFoundatnN sampled_on=2017-05-21T02:25:50
> sampled_by=0.3.1.0-alpha-dev listed=1 confirmed_on=2017-05-23T22:28:05
> confirmed_idx=2
> }}}
>
> I figured that since there were three, and they were all confirmed, they
> would be my primary guards.
>
> Also, my cached-microdesc-consensus file was about a day old.
>
> When Tor starts, it says
> {{{
> May 25 20:58:06.155 [info] sampled_guards_update_from_consensus(): No
> live consensus; can't update sampled entry guards.
> }}}
> Ok, great, it's not going to go deleting or modifying any of my guards
> before it's even tried to load my consensus file from disk. Makes sense.
>
> Then it goes through to update my three guards to say that they're not
> working:
> {{{
> May 25 20:58:06.155 [debug] entry_guard_set_filtered_flags(): Updated
> sampled guard onslaught ($BB119A5A4D5DA2BBB7B796ECC50E3C0F1D4FD910):
> filtered=0; reachable_filtered=0.
> May 25 20:58:06.155 [debug] entry_guard_set_filtered_flags(): Updated
> sampled guard yono1 ($7369A0E14C59B11D78357EC5AFE573A259264BBD):
> filtered=0; reachable_filtered=0.
> May 25 20:58:06.156 [debug] entry_guard_set_filtered_flags(): Updated
> sampled guard IRejectTorFoundatnN
> ($62DA0256BBC28992D41CBAFB549FFD7C9B846A99): filtered=0;
> reachable_filtered=0.
> }}}
> I'm guessing that happened because of entry_guards_update_filtered_sets()
> which got called from entry_guards_update_all(), but there are several
> possible paths to that function so I'm not sure which one it was. Maybe
> it's decided they're all down, since it hasn't even loaded a consensus
> yet, so they're all missing from the nonexistent consensus?
>
> Then we get to:
> {{{
> May 25 20:58:06.156 [info] sample_reachable_filtered_entry_guards():
> Trying to sample a reachable guard: We know of 0 in the USABLE_FILTERED
> set.
> May 25 20:58:06.156 [info] sample_reachable_filtered_entry_guards():
> (That isn't enough. Trying to expand the sample.)
> May 25 20:58:06.156 [info] entry_guards_expand_sample(): Expanding the
> sample guard set. We have 3 guards in the sample, and 0 eligible guards
> to extend it with.
> May 25 20:58:06.156 [info] entry_guards_expand_sample(): Not expanding
> the guard sample any further; just ran out of eligible guards
> May 25 20:58:06.156 [info] sample_reachable_filtered_entry_guards():
> (After filters [b], we have 0 guards to consider.)
> }}}
> Ok, great, we refuse to expand the guard list now. That's good because we
> don't have any consensus loaded yet.
>
> Then I finish loading the state file, and load other stuff from my
> datadirectory, like the cached-microdesc-consensus file:
> {{{
> May 25 20:58:06.644 [info] A consensus needs 5 good signatures from
> recognized authorities for us to accept it. This one has 8 (dannenberg
> tor26 longclaw maatuska moria1 dizum gabelmoo Faravahar).
> May 25 20:58:06.797 [info] microdesc_cache_reload(): Reloaded
> microdescriptor cache. Found 7298 descriptors.
> May 25 20:58:06.812 [info]
> update_consensus_networkstatus_fetch_time_impl(): No live microdesc
> consensus; we should fetch one immediately.
> May 25 20:58:06.812 [info] cell_ewma_set_scale_factor(): Enabled
> cell_ewma algorithm because of value in CircuitPriorityHalflifeMsec in
> consensus; scale factor is 0.793701 per 10 seconds
> May 25 20:58:07.046 [info] networkstatus_set_current_consensus(): Loaded
> an expired consensus. Discarding.
> May 25 20:58:07.046 [info]

Re: [tor-bugs] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

2017-05-25 Thread Tor Bug Tracker & Wiki

#22400: We bootstrap from different primary guards when we start with a non-live
consensus and not enough guards in the state file
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.7
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Description changed by arma:

Old description:

> I started my Tor client (0.3.1.1-alpha (git-ab9976b7245f05a9)) with these
> three guards (and only these three guards) in my state file:
> {{{
> Guard in=default rsa_id=BB119A5A4D5DA2BBB7B796ECC50E3C0F1D4FD910
> nickname=onslaught sampled_on=2017-04-29T09:28:05 sampled_by=0.3.1.0
> -alpha-dev listed=1 confirmed_on=2017-05-02T22:48:40 confirmed_idx=1
> Guard in=default rsa_id=7369A0E14C59B11D78357EC5AFE573A259264BBD
> nickname=yono1 sampled_on=2017-05-02T20:44:35 sampled_by=0.3.1.0-alpha-
> dev listed=1 confirmed_on=2017-04-25T13:14:11 confirmed_idx=0
> pb_use_attempts=3.00 pb_use_successes=3.00
> pb_circ_attempts=105.00 pb_circ_successes=105.00
> pb_successful_circuits_closed=95.00 pb_collapsed_circuits=10.00
> pb_timeouts=8.00
> Guard in=default rsa_id=62DA0256BBC28992D41CBAFB549FFD7C9B846A99
> nickname=IRejectTorFoundatnN sampled_on=2017-05-21T02:25:50
> sampled_by=0.3.1.0-alpha-dev listed=1 confirmed_on=2017-05-23T22:28:05
> confirmed_idx=2
> }}}
>
> I figured that since there were three, and they were all confirmed, they
> would be my primary guards.
>
> Also, my cached-microdesc-consensus file was about a day old.
>
> When Tor starts, it says
> {{{
> May 25 20:58:06.155 [info] sampled_guards_update_from_consensus(): No
> live consensus; can't update sampled entry guards.
> }}}
> Ok, great, it's not going to go deleting or modifying any of my guards
> before it's even tried to load my consensus file from disk. Makes sense.
>
> Then it goes through to update my three guards to say that they're not
> working:
> {{{
> May 25 20:58:06.155 [debug] entry_guard_set_filtered_flags(): Updated
> sampled guard onslaught ($BB119A5A4D5DA2BBB7B796ECC50E3C0F1D4FD910):
> filtered=0; reachable_filtered=0.
> May 25 20:58:06.155 [debug] entry_guard_set_filtered_flags(): Updated
> sampled guard yono1 ($7369A0E14C59B11D78357EC5AFE573A259264BBD):
> filtered=0; reachable_filtered=0.
> May 25 20:58:06.156 [debug] entry_guard_set_filtered_flags(): Updated
> sampled guard IRejectTorFoundatnN
> ($62DA0256BBC28992D41CBAFB549FFD7C9B846A99): filtered=0;
> reachable_filtered=0.
> }}}
> I'm guessing that happened because of entry_guards_update_filtered_sets()
> which got called from entry_guards_update_all(), but there are several
> possible paths to that function so I'm not sure which one it was. Maybe
> it's decided they're all down, since it hasn't even loaded a consensus
> yet, so they're all missing from the nonexistent consensus?
>
> Then we get to:
> {{{
> May 25 20:58:06.156 [info] sample_reachable_filtered_entry_guards():
> Trying to sample a reachable guard: We know of 0 in the USABLE_FILTERED
> set.
> May 25 20:58:06.156 [info] sample_reachable_filtered_entry_guards():
> (That isn't enough. Trying to expand the sample.)
> May 25 20:58:06.156 [info] entry_guards_expand_sample(): Expanding the
> sample guard set. We have 3 guards in the sample, and 0 eligible guards
> to extend it with.
> May 25 20:58:06.156 [info] entry_guards_expand_sample(): Not expanding
> the guard sample any further; just ran out of eligible guards
> May 25 20:58:06.156 [info] sample_reachable_filtered_entry_guards():
> (After filters [b], we have 0 guards to consider.)
> }}}
> Ok, great, we refuse to expand the guard list now. That's good because we
> don't have any consensus loaded yet.
>
> Then I finish loading the state file, and load other stuff from my
> datadirectory, like the cached-microdesc-consensus file:
> {{{
> May 25 20:58:06.644 [info] A consensus needs 5 good signatures from
> recognized authorities for us to accept it. This one has 8 (dannenberg
> tor26 longclaw maatuska moria1 dizum gabelmoo Faravahar).
> May 25 20:58:06.797 [info] microdesc_cache_reload(): Reloaded
> microdescriptor cache. Found 7298 descriptors.
> May 25 20:58:06.812 [info]
> update_consensus_networkstatus_fetch_time_impl(): No live microdesc
> consensus; we should fetch one immediately.
> May 25 20:58:06.812 [info] cell_ewma_set_scale_factor(): Enabled
> cell_ewma algorithm because of value in CircuitPriorityHalflifeMsec in
> consensus; scale factor is 0.793701 per 10 seconds
> May 25 20:58:07.046 [info] networkstatus_set_current_consensus(): Loaded
> an expired consensus. Discarding.
> May 25 20:58:07.046 [info]

Re: [tor-bugs] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

2017-05-25 Thread Tor Bug Tracker & Wiki

#22400: We bootstrap from different primary guards when we start with a non-live
consensus and not enough guards in the state file
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.7
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Description changed by arma:

Old description:

> I started my Tor client (0.3.1.1-alpha (git-ab9976b7245f05a9)) with these
> three guards (and only these three guards) in my state file:
> {{{
> Guard in=default rsa_id=BB119A5A4D5DA2BBB7B796ECC50E3C0F1D4FD910
> nickname=onslaught sampled_on=2017-04-29T09:28:05 sampled_by=0.3.1.0
> -alpha-dev listed=1 confirmed_on=2017-05-02T22:48:40 confirmed_idx=1
> Guard in=default rsa_id=7369A0E14C59B11D78357EC5AFE573A259264BBD
> nickname=yono1 sampled_on=2017-05-02T20:44:35 sampled_by=0.3.1.0-alpha-
> dev listed=1 confirmed_on=2017-04-25T13:14:11 confirmed_idx=0
> pb_use_attempts=3.00 pb_use_successes=3.00
> pb_circ_attempts=105.00 pb_circ_successes=105.00
> pb_successful_circuits_closed=95.00 pb_collapsed_circuits=10.00
> pb_timeouts=8.00
> Guard in=default rsa_id=62DA0256BBC28992D41CBAFB549FFD7C9B846A99
> nickname=IRejectTorFoundatnN sampled_on=2017-05-21T02:25:50
> sampled_by=0.3.1.0-alpha-dev listed=1 confirmed_on=2017-05-23T22:28:05
> confirmed_idx=2
> }}}
>
> I figured that since there were three, and they were all confirmed, they
> would be my primary guards.
>
> Also, my cached-microdesc-consensus file was about a day old.
>
> When Tor starts, it says
> {{{
> May 25 20:58:06.155 [info] sampled_guards_update_from_consensus(): No
> live consensus; can't update sampled entry guards.
> }}}
> Ok, great, it's not going to go deleting or modifying any of my guards
> before it's even tried to load my consensus file from disk. Makes sense.
>
> Then it goes through to update my three guards to say that they're not
> working:
> {{{
> May 25 20:58:06.155 [debug] entry_guard_set_filtered_flags(): Updated
> sampled guard onslaught ($BB119A5A4D5DA2BBB7B796ECC50E3C0F1D4FD910):
> filtered=0; reachable_filtered=0.
> May 25 20:58:06.155 [debug] entry_guard_set_filtered_flags(): Updated
> sampled guard yono1 ($7369A0E14C59B11D78357EC5AFE573A259264BBD):
> filtered=0; reachable_filtered=0.
> May 25 20:58:06.156 [debug] entry_guard_set_filtered_flags(): Updated
> sampled guard IRejectTorFoundatnN
> ($62DA0256BBC28992D41CBAFB549FFD7C9B846A99): filtered=0;
> reachable_filtered=0.
> }}}
> I'm guessing that happened because of entry_guards_update_filtered_sets()
> which got called from entry_guards_update_all(), but there are several
> possible paths to that function so I'm not sure which one it was. Maybe
> it's decided they're all down, since it hasn't even loaded a consensus
> yet, so they're all missing from the nonexistent consensus?
>
> Then we get to:
> {{{
> May 25 20:58:06.156 [info] sample_reachable_filtered_entry_guards():
> Trying to sample a reachable guard: We know of 0 in the USABLE_FILTERED
> set.
> May 25 20:58:06.156 [info] sample_reachable_filtered_entry_guards():
> (That isn't enough. Trying to expand the sample.)
> May 25 20:58:06.156 [info] entry_guards_expand_sample(): Expanding the
> sample guard set. We have 3 guards in the sample, and 0 eligible guards
> to extend it with.
> May 25 20:58:06.156 [info] entry_guards_expand_sample(): Not expanding
> the guard sample any further; just ran out of eligible guards
> May 25 20:58:06.156 [info] sample_reachable_filtered_entry_guards():
> (After filters [b], we have 0 guards to consider.)
> }}}
> Ok, great, we refuse to expand the guard list now. That's good because we
> don't have any consensus loaded yet.
>
> Then I finish loading the state file, and load other stuff from my
> datadirectory, like the cached-microdesc-consensus file:
> {{{
> May 25 20:58:06.644 [info] A consensus needs 5 good signatures from
> recognized authorities for us to accept it. This one has 8 (dannenberg
> tor26 longclaw maatuska moria1 dizum gabelmoo Faravahar).
> May 25 20:58:06.797 [info] microdesc_cache_reload(): Reloaded
> microdescriptor cache. Found 7298 descriptors.
> May 25 20:58:06.812 [info]
> update_consensus_networkstatus_fetch_time_impl(): No live microdesc
> consensus; we should fetch one immediately.
> May 25 20:58:06.812 [info] cell_ewma_set_scale_factor(): Enabled
> cell_ewma algorithm because of value in CircuitPriorityHalflifeMsec in
> consensus; scale factor is 0.793701 per 10 seconds
> May 25 20:58:07.046 [info] networkstatus_set_current_consensus(): Loaded
> an expired consensus. Discarding.
> May 25 20:58:07.046 [info]

[tor-bugs] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

2017-05-25 Thread Tor Bug Tracker & Wiki

#22400: We bootstrap from different primary guards when we start with a non-live
consensus and not enough guards in the state file
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.7
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 I started my Tor client (0.3.1.1-alpha (git-ab9976b7245f05a9)) with these
 three guards (and only these three guards) in my state file:
 {{{
 Guard in=default rsa_id=BB119A5A4D5DA2BBB7B796ECC50E3C0F1D4FD910
 nickname=onslaught sampled_on=2017-04-29T09:28:05 sampled_by=0.3.1.0
 -alpha-dev listed=1 confirmed_on=2017-05-02T22:48:40 confirmed_idx=1
 Guard in=default rsa_id=7369A0E14C59B11D78357EC5AFE573A259264BBD
 nickname=yono1 sampled_on=2017-05-02T20:44:35 sampled_by=0.3.1.0-alpha-dev
 listed=1 confirmed_on=2017-04-25T13:14:11 confirmed_idx=0
 pb_use_attempts=3.00 pb_use_successes=3.00
 pb_circ_attempts=105.00 pb_circ_successes=105.00
 pb_successful_circuits_closed=95.00 pb_collapsed_circuits=10.00
 pb_timeouts=8.00
 Guard in=default rsa_id=62DA0256BBC28992D41CBAFB549FFD7C9B846A99
 nickname=IRejectTorFoundatnN sampled_on=2017-05-21T02:25:50
 sampled_by=0.3.1.0-alpha-dev listed=1 confirmed_on=2017-05-23T22:28:05
 confirmed_idx=2
 }}}

 I figured that since there were three, and they were all confirmed, they
 would be my primary guards.

 Also, my cached-microdesc-consensus file was about a day old.

 When Tor starts, it says
 {{{
 May 25 20:58:06.155 [info] sampled_guards_update_from_consensus(): No live
 consensus; can't update sampled entry guards.
 }}}
 Ok, great, it's not going to go deleting or modifying any of my guards
 before it's even tried to load my consensus file from disk. Makes sense.

 Then it goes through to update my three guards to say that they're not
 working:
 {{{
 May 25 20:58:06.155 [debug] entry_guard_set_filtered_flags(): Updated
 sampled guard onslaught ($BB119A5A4D5DA2BBB7B796ECC50E3C0F1D4FD910):
 filtered=0; reachable_filtered=0.
 May 25 20:58:06.155 [debug] entry_guard_set_filtered_flags(): Updated
 sampled guard yono1 ($7369A0E14C59B11D78357EC5AFE573A259264BBD):
 filtered=0; reachable_filtered=0.
 May 25 20:58:06.156 [debug] entry_guard_set_filtered_flags(): Updated
 sampled guard IRejectTorFoundatnN
 ($62DA0256BBC28992D41CBAFB549FFD7C9B846A99): filtered=0;
 reachable_filtered=0.
 }}}
 I'm guessing that happened because of entry_guards_update_filtered_sets()
 which got called from entry_guards_update_all(), but there are several
 possible paths to that function so I'm not sure which one it was. Maybe
 it's decided they're all down, since it hasn't even loaded a consensus
 yet, so they're all missing from the nonexistent consensus?

 Then we get to:
 {{{
 May 25 20:58:06.156 [info] sample_reachable_filtered_entry_guards():
 Trying to sample a reachable guard: We know of 0 in the USABLE_FILTERED
 set.
 May 25 20:58:06.156 [info] sample_reachable_filtered_entry_guards():
 (That isn't enough. Trying to expand the sample.)
 May 25 20:58:06.156 [info] entry_guards_expand_sample(): Expanding the
 sample guard set. We have 3 guards in the sample, and 0 eligible guards to
 extend it with.
 May 25 20:58:06.156 [info] entry_guards_expand_sample(): Not expanding the
 guard sample any further; just ran out of eligible guards
 May 25 20:58:06.156 [info] sample_reachable_filtered_entry_guards():
 (After filters [b], we have 0 guards to consider.)
 }}}
 Ok, great, we refuse to expand the guard list now. That's good because we
 don't have any consensus loaded yet.

 Then I finish loading the state file, and load other stuff from my
 datadirectory, like the cached-microdesc-consensus file:
 {{{
 May 25 20:58:06.644 [info] A consensus needs 5 good signatures from
 recognized authorities for us to accept it. This one has 8 (dannenberg
 tor26 longclaw maatuska moria1 dizum gabelmoo Faravahar).
 May 25 20:58:06.797 [info] microdesc_cache_reload(): Reloaded
 microdescriptor cache. Found 7298 descriptors.
 May 25 20:58:06.812 [info]
 update_consensus_networkstatus_fetch_time_impl(): No live microdesc
 consensus; we should fetch one immediately.
 May 25 20:58:06.812 [info] cell_ewma_set_scale_factor(): Enabled cell_ewma
 algorithm because of value in CircuitPriorityHalflifeMsec in consensus;
 scale factor is 0.793701 per 10 seconds
 May 25 20:58:07.046 [info] networkstatus_set_current_consensus(): Loaded
 an expired consensus. Discarding.
 May 25 20:58:07.046 [info] router_reload_consensus_networkstatus():
 Couldn't load unverified consensus microdesc networkstatus from cache
 }}}
 Ok, fine, it's expired so we discarded it, no problem.

 {{{
 May

Re: [tor-bugs] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

Re: [tor-bugs] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

Re: [tor-bugs] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

Re: [tor-bugs] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

Re: [tor-bugs] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

Re: [tor-bugs] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

Re: [tor-bugs] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

Re: [tor-bugs] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

Re: [tor-bugs] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

Re: [tor-bugs] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

Re: [tor-bugs] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

Re: [tor-bugs] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

Re: [tor-bugs] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

Re: [tor-bugs] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

Re: [tor-bugs] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

Re: [tor-bugs] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

Re: [tor-bugs] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

Re: [tor-bugs] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

Re: [tor-bugs] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

Re: [tor-bugs] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

Re: [tor-bugs] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

Re: [tor-bugs] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

Re: [tor-bugs] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

Re: [tor-bugs] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

Re: [tor-bugs] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

[tor-bugs] #22400 [Core Tor/Tor]: We bootstrap from different primary guards when we start with a non-live consensus and not enough guards in the state file

26 matches

Site Navigation

Mail list logo

Footer information