[tor-dev] Default bridges that are not publishing statistics
teor2345 at gmail.com
Mon Jun 5 04:37:00 UTC 2017
> On 2 Jun 2017, at 08:20, David Fifield <david at bamsoftware.com> wrote:
> On Wed, May 24, 2017 at 09:31:45PM -0700, David Fifield wrote:
>> On Sat, May 06, 2017 at 09:25:11AM -0700, David Fifield wrote:
>>> Okay, thanks. It still doesn't fully make sense to me, because while
>>> some of the default bridges are in Atlas, not all of them are (for
>>> example the two from https://bugs.torproject.org/21917). I don't think
>>> it's possible that they haven't gotten *any* client traffic.
>>> I wonder if it has something to do with the tor version number?
>> I checked all the other default bridges and all of them but 2 are
>> publishing statistics:
>> C8CBDB2464FC9804A69531437BCF2BE31FDD2EE4 cymrubridge31
>> 0BAC39417268B96B9F514E7F63FA6FBA1A788955 cymrubridge33
>> I will contact the operators and ask them to try setting
>> "AssumeReachable 1".
> The operator of these bridges set "AssumeReachable 1" and the bridges
> still are not publishing statistics ("No Tor relays or bridges matched
> your query :("):
> According to the operator, the bridges are running version 0.2.9.10, so
> my hypothesis about it having something to do with old version numbers
> is wrong.
> I tried downloading one of the bridge's bridge-extra-info descriptors
> (which would contain information about how many connections it has had),
> but I can't quite make it work. Using this torrc file:
> DownloadExtraInfo 1
> FetchUselessDescriptors 1
These options only make tor clients fetch relay extra info descriptors.
But that's not really clear in the man page:
I logged this bug so we clarify that:
> And this Stem script:
> from stem.control import Controller
> with Controller.from_port(port = 9051) as controller:
> print controller.get_server_descriptor("C8CBDB2464FC9804A69531437BCF2BE31FDD2EE4")
> I can get the bridge-server-descriptor, but not the bridge-extra-info.
> Here are some lines from bridge-server-descriptor:
> platform Tor 0.2.9.10 on Linux
> proto Cons=1-2 Desc=1-2 DirCache=1 HSDir=1 HSIntro=3 HSRend=1-2 Link=1-4 LinkAuth=1 Microdesc=1-2 Relay=1-2
> published 2017-06-01 21:19:10
> fingerprint C8CB DB24 64FC 9804 A695 3143 7BCF 2BE3 1FDD 2EE4
> uptime 613949
> bandwidth 1073741824 1073741824 5628404
> extra-info-digest 8B5F0BD647B3C4AF2C57F148FF6A1FB8B695B0AE 398ZHFBxUpTRfLxv+pSMY3BGMUYlzogXMG40dhjPgnA
You asked your bridge for its server descriptor and it gave it to you.
Did you try:
Since your bridge knows its own extra info descriptor, it should serve it to you.
I don't know how to find a server that caches *all* bridge extra infos.
Maybe you should try running these queries against the bridge authority?
(How does OnionOO do it?)
> (Furthermore, with the torrc shown above, tor doesn't save *any*
> extra-info descriptors, despite the presence of "DownloadExtraInfo 1"
> and "FetchUselessDescriptors 1".
This is because your bridge is your directory guard.
If you want to fetch relay extra infos through your bridge, you need to
configure it to download and serve relay extra infos. I'm not sure how to do
that (maybe DirCache 1?), so I opened this ticket:
> The datadir contains cached-certs,
> cached-consensus, and cached-descriptors, but no cached-extrainfo. Only
> after I change "UseBridges 1" to "UseBridges 0" does the
> cached-extrainfo file appear--but then of course it doesn't contain any
> information on bridges.)
That's because your client selects a directory mirror that caches extra
infos for relays.
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
xmpp: teor at torproject dot org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 801 bytes
Desc: Message signed with OpenPGP
More information about the tor-dev