Write and run a clique reachability test.

It would be useful to know what the full inter-relay connectivity graph looks like, and how far it differs from the "every relay can always reach every other relay" ideal.

https://www.sba-research.org/wp-content/uploads/publications/NavigaTor_preprint.pdf

This should be something doable with stem, and ideally we can run it periodically/automatically, and use it to do things like reject relays that have extremely poor connectivity.

changed milestone to %Tor: unspecified

added component::core tor/tor milestone::Tor: unspecified network-health priority::medium severity::normal status::new stem tooling type::task version::tor unspecified labels

Yes please!

This was one of the original goals of Torflow.

And I feel like somebody did a test of this more recently, but I don't remember who and can't find the ticket. I am cc'ing two usual suspects in case they remember.

Trac:
Cc: N/A to atagar, phw

I've also done some work on this recently. I might even be able to provide the stem script.

Replying to teor:

I've also done some work on this recently. I might even be able to provide the stem script.

Great! Looking forward to it.

There's also this work in progress (not by me): https://github.com/TheTorProject/bwscanner/blob/develop/bwscanner/detect_partitions.py

Some of the issues I ran into when writing a similar script:

• network load - running these tests as fast as you can puts significant load on the network
• what if a relay is down, rather than blocked?
• making ~7000 connections through a single relay might overload it, particularly if it's low-bandwidth, file-descriptor limited, or behind a NAT box
• connection testing is directional - sometimes relay A can initiate a connection to relay B, but relay B can't initiate a connection to relay A. But once they're connected, they can both exchange cells

Oh, and another:

• if you collect timing information, it could be used to analyse relay load or the existence of existing circuits. So best to blur that information out.

And here is something I prepared earlier: https://github.com/teor2345/onion-graph

Trac:
Component: Core Tor to Core Tor/Tor

See also #12131 (moved) for an overlapping ticket.

Trac:
Cc: atagar, phw to atagar, phw, catalyst

the question which specific relays have problems reaching other relays was already answered in #12131 (moved) (three years ago). being the main author of the NavigaTor paper mentioned by the OP, I can say that the code used for answering the question (https://bitbucket.org/ra_/tor-relay-connectivity/) shares some ideas of the NavigaTor code - as said in #12131 (moved). feel free to reuse it. as far as I can remember, there were a couple of relays that had tremendous outbound connection issues (which looked kind of fishy but is probably due to firewall misconfiguerations) - see https://trac.torproject.org/projects/tor/attachment/ticket/12131/bad_outbound_connections.csv.

Missing milestone.

Trac:
Milestone: N/A to Tor: unspecified

just putting a pointer to David's related tor-project ML posting here: https://lists.torproject.org/pipermail/tor-project/2017-October/001492.html

Trac:
Keywords: N/A deleted, network-health added

mentioned in issue #19625 (moved)

moved to tpo/core/tor#19068 (closed)