7

Tor maintains a descriptor store which keeps all the descriptors it knows about. New descriptors enter the store after being downloaded, old descriptors get expired when they haven't been referenced and are outdated. The client regularly fetches a new consensus document and fetches all the descriptors that it doesn't have and that are referenced in the ...


4

Check out: https://collector.torproject.org/archive/relay-descriptors/consensuses/ and the main page (https://collector.torproject.org/) for more info.


3

Remove the tor instances your not using so there gone and not just hibernating. There is no way to remove them your self from the consensus. They will automaticly dissapear after about a week of no activity.


3

Good and detailed question, but you're misunderstanding a key point about descriptors. A descriptor doesn't change, once you've downloaded it you don't update it. This is guaranteed by using hashes - if a new descriptor is generated, it will have a new hash value, so the new descriptor is fetched. The check every 10 seconds just means that we'll try to fetch ...


3

There are 9 directory authorities which are hard-coded into the Tor software. Following please find addresses and some additional information about these directory authorites: https://atlas.torproject.org/#search/flag:authority


3

You can easily fetch the consensus with... https://stem.torproject.org/api/descriptor/remote.html https://stem.torproject.org/tutorials/mirror_mirror_on_the_wall.html For an example of a script that compares a couple authorities see... https://stem.torproject.org/tutorials/examples/compare_flags.html That said, please don't hit the authorities every five ...


3

Near the top of this page: Consensus Health, in the Signatures section, you will find a 'consensus' (and 'vote') link for each Directory Authority. These link directly to http://ip.of.the.relay:dirport/tor/status-vote/current/consensus.


3

As far as I see it the answer is in the source code. ;-) The file main.c has a function run_scheduled_events. The comment to this function says: Perform regular maintenance tasks. This function gets run once per second by second_elapsed_callback(). Within the source code there is a list of things which this function does. As far as I see it item 2c ...


2

As far as I know it is still possible to do those kind of attacks against the network. However Tor tries to detect bad relays and block them from participating in the network. So there is a high chance that your research doesn't lead to satisfactory results. Tor has created a Research Safety Board. You can ask them for advice on how to best conduct your ...


2

Tor automatically builds the fastest circuits possible for you by attempting to see how much bandwidth is available for each node. It doesn't rely on the client supplied Bandwidth value but actually tries to test the node by building various circuits and timing the requests. Sometimes those tests are inconclusive, never get run, or just come up with bad ...


2

No it does not. (..and neither does the OR traffic.) The idea that 'traffic counts towards consensus weight' is not how it works. As I understand (from the linked document), the bandwidth is measured by building a circuit through the relay and transferring a file through it (and measuring how long that takes). So the consensus weight is not determined any ...


2

From what I gathered, I have not found anything that point that a client periodically fetch the consensus file. On the other hand, consensus files do expire, and when that happens the client will request the latest version. If you set TestingTorNetwork in torrc to 1, one of the properties tested will be the frequency of fetching the consensus file. The ...


2

Every client that doesn't get its consensus from some other source (clients that use bridges get theirs from the bridge they connect to) will have to connect to the Directory Authorities once at first startup, and again if they're offline for a day or longer. Tor metrics should take this into account when calculating user numbers.


1

As far as I remember consensus documents are downloaded from the directory guards. Currently, every client has three guards but that's subject to change. I believe you never download the full consensus but rather only what is needed to build a circuit. (e.g. what is necessary to pick a random path through the network.) I looked at directory protocol some ...


1

"How did it get there" No idea. "what is it" It looks like a Tor network consensus document "why did it delete my PHP file" It's a plain text file, it couldn't have. "how do I prevent this from happening again?" Since no one has any idea how it happened, no one knows.


1

It is just normal. It means Tor client did not finish fetching consensus, and as soon as it finishes, it starts to build circuits.


1

I would have to say that having a dynamic ip can hurt your relay in the metrics over a static ip. While I cant pick out specifics I can give you the links to the tor-relay email discussions which took place recently with some great info and much more up to date then the trac issue https://lists.torproject.org/pipermail/tor-relays/2016-December/thread.html ...


1

Thanks for running a relay. (: Clients choose which relays to use based on their consensus weight. The consensus weight is assigned by the directory authorities after measuring the throughput for your relay. There are a number of things that can impact the speed at which your relay can be used, including the CPU speed, CPU architecture, the network ...


1

I'm not entirely sure what you mean by 'the identity of a router retrieved from the consensus'. But a few guesses: https://consensus-health.torproject.org/consensus-health.html will show the same data as the consensus, but in a friendly format. In particular, in the gigantic table, the left-most column contains a short identifier, and underneath it in ...


1

The default directory authorities are located (as of version 0.2.8.0-alpha-dev (git-d015c70a118e4357)) in file or/config.c: /** List of default directory authorities */ static const char *default_authorities[] = { "moria1 orport=9101 " "v3ident=D586D18309DED4CD6D57C18FDB97EFA96D330566 " "128.31.0.39:9131 9695 DFC3 5FFE B861 329B 9F1A B04C 4639 ...


1

The votes themselves are also hosted at https://collector.torproject.org/archive/relay-descriptors/votes/ where they can be downloaded directly.


1

Looking at the votes for the individual directory authorities, it appears that gabelmoo and longclaw don't have Measured lines for your relay. moria1 and tor26 measure your node just fine. I worry that there's nothing you can do on your end to fix it, as it is a problem with the bandwidth authorities measurement code. I'm gabelmoo's operator and I'll try to ...


1

It could be two things: While you have a gigabit capacity, the network measures bandwidth based on the averaging of connections. So it's possible that a group of circuits could use you at gigabit capacity but if you average out the peak usage with the disconnects and non-usage, you won't see it as gigabit. This doesn't explain why it's only a few Mb though. ...


Only top voted, non community-wiki answers of a minimum length are eligible