[tor-bugs] #27811 [Core Tor/Tor]: Eventual inability to connect to a HS from a client that lists most countries in ExcludeNodes

[Tor Bug Tracker & Wiki]

#27811: Eventual inability to connect to a HS from a client that lists most
countries in ExcludeNodes
------------------------------+------------------------------
 Reporter:  jchevali          |          Owner:  (none)
     Type:  defect            |         Status:  new
 Priority:  Medium            |      Component:  Core Tor/Tor
  Version:  Tor: unspecified  |       Severity:  Normal
 Keywords:                    |  Actual Points:
Parent ID:                    |         Points:
 Reviewer:                    |        Sponsor:
------------------------------+------------------------------
 My v3 hidden services become unavailable after a while to a client with
 lots of countries listed in ExcludeNodes (I can't recall what used to
 happen to v2 services).

 The set up is as follows:

 - I have multiple HS in a server which are copies of each other and
 similar in every respect, except for the keys and hostnames

 - I have a client connecting to these which has lots of countries listed
 in ExcludeNodes; in fact it excludes most countries in the world, but not
 to the extent of making tor unusable

 For a while after this is set up, I'm able to use all of these services
 from the client.  But then one day one of those will fail to connect.
 There's a wait of many seconds while tor is busy, and ultimately it will
 fail the request.  If I retry, often it'll take just as long to fail
 again, but it reaches a point that after a number of failures it will
 start to fail instantly.

 Meanwhile, the other, similar services are still accessible to this
 client.  Also a browser connected to this tor bundle can browse the web,
 etc.

 I used to think there was something wrong with the service that failed so
 I attempted to redefine it and restart it.  I did this until I found that
 the problem was the client.  The client with lots of countries in
 ExcludeNodes reaches a point where it is unable to continue processing
 this service.  The only way for this client to start working correctly
 again is to comment out the ExcludeNodes directive in torrc and restart
 the client (a HUP signal does not suffice), then after reinstating
 ExcludeNodes and restarting the client the hidden service will be
 accessible again... until some unspecified future date.

 I should add in case it's relevant that the client is accessing the tor
 network through bridges.  These are good bridges and are in good
 condition.

 I wonder if it is a case of, with the passage of time, the descriptors
 database on the client side losing quality and becoming unable to support
 these operations.  Because I believe that ExcludedNodes worked correctly
 at runtime, whether the database has had many countries excluded for a
 number of days or the database's just been refreshed.  But if something is
 missing from the database maybe after a few days the software can't run
 all the permutations (to hit the ones that will allow it to connect).
 Maybe the problem is that the upkeeping and refilling of this database at
 all other times (while tor was already loaded but I was still not trying
 to access the hidden service), under ExcludeNodes conditions, is unable to
 refill the database properly... but then this condition only becomes
 apparent later, at HS connection time.  (Though I'm not a Tor expert so
 forgive me if I'm not making sense).

 Anyhow, I can't think how I could check what's in the descriptors
 database.  I've tried replacing it with another tor bundle installation
 that didn't have this problem (and the state file) but I'm not able to
 complete such a test yet.  All I know is the difference between a
 successful connection and an unsuccessful one (which I obtained by adding
 SETEVENTS INFO to a control connection).  During a successful connection
 there's only about a hundred lines logged and it connects.  During an
 unsuccessful connection lots more info messages are logged, like so,

 {{{
 650 INFO extend_info_from_node():
 Not including the ed25519 ID for $(ID)~(NAME) at (IP),
 since it won't be able to authenticate it
 }}}

 intermixed with messages issued by origin_circuit_new() and
 rep_hist_note_used_internal() talking about seconds of predictive building
 remaining.  And it fails to connect.

 Perhaps there is a threshold of ExcludeNodes above which the conditions
 for the fulfilling of requests starves the client database of information
 and degrades it and makes the client incapable of doing its work, and
 perhaps my own setting for this option has exceeded the threshold (I have
 excluded most countries in the world except my own and those that have
 borders with it).  What I can't get however is why this condition is never
 apparent as the client initially tries to use the service, only becoming
 apparent several days later.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/27811>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online