Thanks for your informative reply.
On Mon, Jun 05, 2017 at 02:37:00PM +1000, teor wrote:
On 2 Jun 2017, at 08:20, David Fifield david@bamsoftware.com wrote:
... And this Stem script: from stem.control import Controller with Controller.from_port(port = 9051) as controller: controller.authenticate() 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: print controller.get_extrainfo_descriptors("8B5F0BD647B3C4AF2C57F148FF6A1FB8B695B0AE")
https://stem.torproject.org/api/descriptor/remote.html#stem.descriptor.remot...
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?
get_extrainfo_descriptors doesn't work as a method of stem.control.Controller: AttributeError: 'Controller' object has no attribute 'get_extrainfo_descriptors'
Calling get_extrainfo_descriptors from stem.descriptor.remote returns an empty list. (499D92E08769BFC0B7941C74031335B9EC9E9BAE is the new extra-info-digest I got from running just now.) import stem.descriptor.remote print list(stem.descriptor.remote.get_authorities()) print list(stem.descriptor.remote.get_server_descriptors("C8CBDB2464FC9804A69531437BCF2BE31FDD2EE4")) print list(stem.descriptor.remote.get_extrainfo_descriptors("499D92E08769BFC0B7941C74031335B9EC9E9BAE")) This is the output. Bifroest is in the get_authorities list, so I assume it's querying the bridge authority somewhere in there. ['maatuska', 'tor26', 'Bifroest', 'longclaw', 'dizum', 'gabelmoo', 'moria1', 'dannenberg', 'Faravahar'] [] []
(How does OnionOO do it?)
I thought that Onionoo was getting extrainfos from Collector. I assumed that was the reason why Onionoo doesn't work for the two bridges in question, because they aren't in Collector.
(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: https://trac.torproject.org/projects/tor/ticket/22492
I'm not really interested in fetching extrainfos through the bridge. I was only trying to do that for the bridge itself, in order to see how much traffic the bridge is getting. I thought if Stem couldn't do it, I might be able to pull the answer out of tor's state directory. Actually I suspected that the bridge would not cache extrainfos for other bridges, but I thought it might at least return its own extrainfo.
What I'm trying to understand is why these two bridges are behaving differently than other default bridges, even though as far as I know they are configured the same way (obfs4 is the only open port, ORport is firewalled shut). I'm concerned that we are undercounting the number of obfs4 users while these bridges are not reporting statistics.