Re: [tor-dev] Default bridges that are not publishing statistics

[David Fifield <david@xxxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxx> 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.remote.DescriptorDownloader.get_extrainfo_descriptors
> 
> 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.
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev