Opened 9 years ago

Closed 9 years ago

Last modified 7 years ago

#1959 closed defect (fixed)

entry nodes marked bad if we don't have their descriptor when we parse the consensus

Reported by: arma Owned by: arma
Priority: High Milestone: Tor: 0.2.2.x-final
Component: Core Tor/Tor Version:
Severity: Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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.

Child Tickets

Change History (12)

comment:1 Changed 9 years ago by arma

What a mess. This is related to patches I did for #1090 that made us reload our entry guard list more often than just at boot. I am beginning to think that some of the above analysis is bunk.

First clear thing to fix is that update_router_have_minimum_dir_info() needs to return "no" if EntryNodes is set yet we have no descriptor for any of our entry nodes. The tricky thing about that change is that we haven't really done any entry node list making until have_minimum_dir_info becomes true.

comment:2 Changed 9 years ago by arma

Milestone: Tor: 0.2.2.x-final
Priority: normalmajor

comment:3 Changed 9 years ago by nickm

Status: newneeds_review

I did the EntryNodes trick in branch bug1959_part1 in my public.

comment:4 Changed 9 years ago by arma

bug1959_part1 looks good, and is confirmed to work.

somebody needs to make check-spaces on it though

also, i say we should just check !num_present, and not do any of the "at least one-quarter" business here when considering their entry node descriptors. They asked for a particular path-building set up, and our job is to give them a path if we can.

comment:5 Changed 9 years ago by nickm

will check-spaces, and revise. It seems you want this bikeshed, so I'll paint it to order.

Does this close 1959, or is there a part2?

comment:6 Changed 9 years ago by arma

There is more to come, alas.

I think we're going to need to do an "optimistically retrying" deal with entrynodes too, where if all your entrynodes are down but you get a socks request you put them all up again just in case.

I had a case where I configured one entrynode, and a single circuit attempt to it timed out (I don't know why it didn't answer my create_fast), and then my Tor refused to make circuits for 3 hours until it got the next consensus.

Oh, and the "optimistically retrying" thing doesn't work for bridges either, which I think is related to some of these other vague bugs we have open.

comment:7 Changed 9 years ago by nickm

updated and merged bug1959_part1.

comment:8 Changed 9 years ago by nickm

Owner: set to arma
Status: needs_reviewassigned

Moving out of needs_review; we don't have any more to review here.

comment:9 Changed 9 years ago by nickm

(That is, there is not currently any code under review. What we had, we merged.)

comment:10 in reply to:  6 Changed 9 years ago by arma

Replying to arma:

I had a case where I configured one entrynode, and a single circuit attempt to it timed out (I don't know why it didn't answer my create_fast), and then my Tor refused to make circuits for 3 hours until it got the next consensus.

Should be fixed by #1882.

Oh, and the "optimistically retrying" thing doesn't work for bridges either, which I think is related to some of these other vague bugs we have open.

Should be fixed by #1981.

comment:11 Changed 9 years ago by arma

Resolution: fixed
Status: assignedclosed

Closing this one now that things work for me.

comment:12 Changed 7 years ago by nickm

Component: Tor ClientTor
Note: See TracTickets for help on using tickets.