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

[teor]

> On 5 Jun 2017, at 15:53, David Fifield <david at bamsoftware.com> wrote:
> 
> On Mon, Jun 05, 2017 at 03:15:08PM +1000, teor wrote:
>> 
>>> On 5 Jun 2017, at 15:06, David Fifield <david at bamsoftware.com> wrote:
>>> 
>>> 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']
>>> 	[]
>>> 	[]
>> 
>> I think the documentation at:
>> https://stem.torproject.org/api/descriptor/remote.html#stem.descriptor.remote.Query
>> is out of date: as far as I know, newer stem versions try fallback
>> directories rather than authorities.
>> 
>> Even if that's not the case, stem will choose a random authority for
>> you, which will (8/9 times) tell you that it knows nothing about any
>> bridge extra infos. (I don't think authorities cache bridge extra
>> infos.)
>> 
>> Try passing Bifroest's address and DirPort to the endpoints= argument to
>> get_extrainfo_descriptors():
>> https://stem.torproject.org/api/descriptor/remote.html#stem.descriptor.remote.Query
> 
> Thanks again for your suggestions. Passing endpoints= doesn't seem to do
> anything.
> 	>>> import stem.descriptor.remote
> 	>>> BIFROEST = ("37.218.247.217", 80)
> 	>>> print list(stem.descriptor.remote.get_server_descriptors("C8CBDB2464FC9804A69531437BCF2BE31FDD2EE4", endpoints=(BIFROEST,)))
> 	[]
> It also doesn't work when trying the fingerprint of another default
> bridge, or of one I just got from bridge.torproject.org.
> ...

At this point, you are deep in the internals of stem, the control spec,
the dir spec, and their various implementations in Tor.

Atagar might be able to help with the stem side of things.
I'd encourage you to open a ticket for the bridges that aren't
reporting, and we'll try to reproduce and diagnose.

Can you get logs (and torrcs) from those bridges to confirm whether
they think they are producing extra info descriptors?

T

--
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org
------------------------------------------------------------------------



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20170605/3b30dbe7/attachment.sig>