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 :("): https://atlas.torproject.org/#details/C8CBDB2464FC9804A69531437BCF2BE31FDD2E... https://atlas.torproject.org/#details/0BAC39417268B96B9F514E7F63FA6FBA1A7889...
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.
Roger suspects that the reason the bridges haven't reported any statistics is because they haven't received any connections. That possibility seems unlikely to me, because they are default bridges shipping in Tor Browser, and additionally I have an hourly test running that makes an obfs4 connection and builds a circuit.
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: UseMicroDescriptors 0 DownloadExtraInfo 1 FetchUselessDescriptors 1 ClientTransportPlugin obfs4 exec /usr/bin/obfs4proxy ControlPort 9051 CookieAuthentication 1 UseBridges 1 Bridge obfs4 38.229.1.78:80 C8CBDB2464FC9804A69531437BCF2BE31FDD2EE4 cert=Hmyfd2ev46gGY7NoVxA9ngrPF2zCZtzskRTzoWXbxNkzeVnGFPWmrTtILRyqCTjHR+s9dg iat-mode=1 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
(Furthermore, with the torrc shown above, tor doesn't save *any* extra-info descriptors, despite the presence of "DownloadExtraInfo 1" and "FetchUselessDescriptors 1". 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.)