Opened 10 years ago

Closed 10 years ago

Last modified 8 years ago

#1982 closed enhancement (implemented)

Allow IPs or country in EntryNodes

Reported by: arma Owned by:
Priority: Medium Milestone:
Component: Core Tor/Tor Version:
Severity: Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


Right now we block you from setting entrynodes to {de} in options_validate():

  if (options->EntryNodes && !routerset_is_list(options->EntryNodes)) {
    /* XXXX fix this; see entry_guards_prepend_from_config(). */
    REJECT("IPs or countries are not yet supported in EntryNodes.");

with a comment in entry_guards_prepend_from_config() that says:

  /* XXXX022 Now that we allow countries and IP ranges in EntryNodes, this is
   *  potentially an enormous list. For now, we disable such values for
   *  EntryNodes in options_validate(); really, this wants a better solution.
   *  Perhaps we should do this calculation once whenever the list of routers
   *  changes or the entrynodes setting changes.

We actually already do this calculation only when the entrynodes setting changes or when directory_info_has_arrived() gets called. Actually, it's better than that -- we only do the calculation if we make a new circuit *and*, since the last time we made a circuit, entrynodes changed or we got new dir info.

I just took out the check in my local Tor, set my entrynodes to {de}, and things look like they're going ok. Dunno if there is more cpu load compared to normal, since Tor clients are so light.

(Note that we also call count_usable_descriptors() on entrynodes every minute or so now, to ensure that router-have-minimum-dir-info is still accurate.)

Child Tickets

Change History (7)

comment:1 Changed 10 years ago by arma

Status: newneeds_review

See bug1982 in my arma.

I think maybe this should go into 0.2.3.x, in case I'm way wrong about the cpu load.

comment:2 Changed 10 years ago by arma

bug1982_2 is rebased on master (50720a9a4) such that it now compiles for me

comment:3 Changed 10 years ago by arma

On the other hand, the potential cpu load should only show up if you use the feature. So we could put it into 0.2.2.x and still fix it in 0.2.3.x if we need to.

I'm not sure which branch it should go into.

comment:4 Changed 10 years ago by nickm

I favor 0.2.3.x.

comment:5 Changed 10 years ago by nickm

This will conflict slightly with my "nodes" branch (see #1757). I'll tweak it after "nodes" gets merged.

comment:6 Changed 10 years ago by nickm

Resolution: implemented
Status: needs_reviewclosed

Merged. Closing.

comment:7 Changed 8 years ago by nickm

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