Re: [tor-dev] Default bridges that are not publishing statistics
> 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 Hi teor, minor correction: you link to the DescriptorDownloader's method but cite it as being part of Controller. This is why David didn't find it later. The Controller can fetch some descriptor types. For instance... https://stem.torproject.org/api/control.html#stem.control.Controller.get_server_descriptor https://stem.torproject.org/tutorials/mirror_mirror_on_the_wall.html#can-i-get-descriptors-from-the-tor-process However, the Controller doesn't provide extrainfo descriptors. This is for a couple reasons... 1. The control protocol only allows it to be retrieved by the descriptor digest rather than relay fingerprint, which is a pita... https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n562 2. This isn't what you want anyway. Fetching decriptors from the tor process only gets you the cached descriptors which isn't what folks generally want. So you're right that the DescriptorDownloader is the way to go. > 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? Bridge descriptors are not public like normal descriptors. To work of course the tor client can retrieve it if you know the bridge address but beyond that I think the only thing available is the sanitized descriptors from CollecTor... https://collector.torproject.org/recent/bridge-descriptors/ > 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. Unfortunately it doesn't. I had to revert that because they lack extrainfo docs... https://gitweb.torproject.org/stem.git/commit/?id=758f632 > 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,))) > [] For what it's worth stem has authority information so this can also be done with... >>> import stem.descriptor.remote >>> bifroest = stem.descriptor.remote.get_authorities()['Bifroest'] >>> print >>> list(stem.descriptor.remote.get_server_descriptors("C8CBDB2464FC9804A69531437BCF2BE31FDD2EE4", >>> endpoints=((bifroest.address, bifroest.dir_port),))) > It also doesn't work when trying the fingerprint of another default > bridge, or of one I just got from bridge.torproject.org. Alas, this is getting into areas I'm not too familiar with. To prevent enumaration I'm sure bridges are handled specially. > Atagar might be able to help with the stem side of things. Happy to help if there's any other stem questions. Cheers! -Damian ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Default bridges that are not publishing statistics
On Mon, Jun 05, 2017 at 11:51:04PM +1000, teor wrote: > > Can you get logs (and torrcs) from those bridges to confirm whether > they think they are producing extra info descriptors? I've asked the operator but not gotten a reply yet. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Default bridges that are not publishing statistics
> On 5 Jun 2017, at 15:53, David Fifield wrote: > > On Mon, Jun 05, 2017 at 03:15:08PM +1000, teor wrote: >> >>> On 5 Jun 2017, at 15:06, David Fifield 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 signature.asc Description: Message signed with OpenPGP ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev