[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[tor-bugs] #1959 [Tor Client]: entry nodes marked bad if we don't have their descriptor when we parse the consensus

#1959: entry nodes marked bad if we don't have their descriptor when we parse the
consensus
------------------------+---------------------------------------------------
 Reporter:  arma        |       Owner:     
     Type:  defect      |      Status:  new
 Priority:  normal      |   Milestone:     
Component:  Tor Client  |     Version:     
 Keywords:              |      Parent:     
------------------------+---------------------------------------------------
 While reproducing #1389 I set my entrynodes to moria1,ides and set
 strictnodes.

 I started out not having a consensus, and not having a descriptor for
 moria1 or for ides. Then I got a consensus, and got a descriptor for
 moria1 (among others), and that was enough to say I had minimum_dir_info,
 so directory_info_has_arrived() was willing to call
 entry_guards_compute_status():

 {{{
 Sep 21 03:46:11.960 [info] entry_nodes_should_be_added(): EntryNodes
 config option set. Putting configured relays at the front of the entry
 guard list.
 Sep 21 03:46:11.960 [info] entry_guard_set_status(): Entry guard ides
 (F397038ADC51336135E7B80BD99CA3844360292B) is unlisted: marking as
 unusable.
 Sep 21 03:46:11.960 [info] entry_guards_compute_status(): Summary: Entry
 'ides' is reachable, unusable, unlisted, and not live / bad.
 Sep 21 03:46:11.960 [info] entry_guards_compute_status(): Summary: Entry
 'moria1' is reachable, usable, and live.
 Sep 21 03:46:11.960 [info] entry_guards_compute_status():     (1/2 entry
 guards are usable/new)
 Sep 21 03:46:11.960 [info] log_entry_guards(): ides (bad, made-
 contact),moria1 (up made-contact)
 }}}

 But I didn't have ides's descriptor yet, so it got marked as "unlisted":
 {{{
   if (!ri)
     *reason = "unlisted";
 }}}

 Once I do get the descriptor for ides, I never call
 entry_guards_compute_status().

 Presumably I will call it the next time I get a consensus. But that would
 seem to mean that if I set entrynodes to e.g. {de}, then I'll rearrange my
 entrynode set as soon as I get a new consensus, and any new {de} nodes
 will get labelled bad ("unlisted") until 2-4 hours later when I get a
 consensus and I already have their descriptors.

 So the complex hack would be to look through descriptors I get and if any
 of them are in entrynodes, call entry_guards_compute_status() then.

 But sometimes entrynodes can be complex, with the country codes and all.

 So the simple hack is that whenever I get *any* descriptors, I should
 rejuggle my entry guard list.

 Are there any downsides? Hm.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/1959>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs