hi Roger et al,
thanks for your extensive reply, I appreciate this. I am a relatively small relay operator with more of an infrastructure background than a software development background, but nevertheless trying to understand and learn from the bug reports and follow up. So I am afraid I can't help you out on details regarding the tor clients that are putting load on the directory authorities.
kinds regards, Paul
gr. Paul
On Sun, Jun 14, 2020 at 11:58 PM Roger Dingledine arma@torproject.org wrote:
On Sun, Jun 14, 2020 at 07:27:55PM +0200, Paul Geurts wrote:
anything up this weekend?
[image: image.png]
Yes. There is a mysterious alternative Tor client out there, which is programmed to do uncompressed directory fetches just from the directory authorities. It easily overloads directory authorities if they don't use the defenses we put in for it over the past few months: https://bugs.torproject.org/33018
This alternate set of Tor clients recently came back, and you can see its impact in e.g. the bandwidth graph for gabelmoo:
https://metrics.torproject.org/rs.html#details/F2044413DAC2E02E3D6BCF4735A19...
Now, fortunately, it doesn't ask for directory information in the same way as any of the Tors that we've ever built, so the fix in #33018 was to keep answering the Tors that we built, while declining to answer these other requests when we're low on bandwidth.
But even still, some of the directory authorities are having trouble under the load, and the resulting desynchronization means that not every directory authority succeeds at participating in every consensus round.
That's probably what you're seeing with the inconsistencies on https://consensus-health.torproject.org/
If somebody knows some details of what these other Tor clients actually are, that would be really helpful to know!
--Roger
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays