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/F2044413DAC2E02E3D6BCF4735A19BCA1DE97281

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