<div dir="ltr"><div>hi Roger et al,</div><div><br></div><div>thanks for your extensive reply, I appreciate this.</div><div>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. <br></div><div><br></div><div>kinds regards, Paul</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">gr. Paul<br></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jun 14, 2020 at 11:58 PM Roger Dingledine <<a href="mailto:arma@torproject.org">arma@torproject.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sun, Jun 14, 2020 at 07:27:55PM +0200, Paul Geurts wrote:<br>
> anything up this weekend?<br>
> <br>
> [image: image.png]<br>
<br>
Yes. There is a mysterious alternative Tor client out there, which is<br>
programmed to do uncompressed directory fetches just from the directory<br>
authorities. It easily overloads directory authorities if they don't use<br>
the defenses we put in for it over the past few months:<br>
<a href="https://bugs.torproject.org/33018" rel="noreferrer" target="_blank">https://bugs.torproject.org/33018</a><br>
<br>
This alternate set of Tor clients recently came back, and you can see<br>
its impact in e.g. the bandwidth graph for gabelmoo:<br>
<a href="https://metrics.torproject.org/rs.html#details/F2044413DAC2E02E3D6BCF4735A19BCA1DE97281" rel="noreferrer" target="_blank">https://metrics.torproject.org/rs.html#details/F2044413DAC2E02E3D6BCF4735A19BCA1DE97281</a><br>
<br>
Now, fortunately, it doesn't ask for directory information in the same<br>
way as any of the Tors that we've ever built, so the fix in #33018 was<br>
to keep answering the Tors that we built, while declining to answer<br>
these other requests when we're low on bandwidth.<br>
<br>
But even still, some of the directory authorities are having trouble<br>
under the load, and the resulting desynchronization means that not every<br>
directory authority succeeds at participating in every consensus round.<br>
<br>
That's probably what you're seeing with the inconsistencies on<br>
<a href="https://consensus-health.torproject.org/" rel="noreferrer" target="_blank">https://consensus-health.torproject.org/</a><br>
<br>
If somebody knows some details of what these other Tor clients actually<br>
are, that would be really helpful to know!<br>
<br>
--Roger<br>
<br>
_______________________________________________<br>
tor-relays mailing list<br>
<a href="mailto:tor-relays@lists.torproject.org" target="_blank">tor-relays@lists.torproject.org</a><br>
<a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays" rel="noreferrer" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays</a><br>
</blockquote></div>