[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-bugs] #27811 [Core Tor/Tor]: Eventual inability to connect to a HS from a client that lists most countries in ExcludeNodes
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs