Snowflake statistics appear to be broken from something plus mid-June

https://metrics.torproject.org/userstats-bridge-transport.html?start=2018-04-14&end=2018-07-13&transport=snowflake

Trac:
Username: TracTorProjectSucksRightNow

added component::circumvention/snowflake priority::medium reporter::TracTorProjectSucksRightNow resolution::wontfix severity::normal status::closed type::defect labels

I'm not sure what's wrong. I checked and there were not any configuration changes on the bridge in June. It's missing from Onionoo too: https://metrics.torproject.org/rs.html#details/5481936581E23D2D178105D44DB6915AB06BFB7F

The bridge is still producing stats locally:

# cat /var/lib/tor/stats/bridge-stats 
bridge-stats-end 2018-07-14 05:36:29 (86400 s)
bridge-ips cn=8,in=8,ma=8
bridge-ip-versions v4=8,v6=0
bridge-ip-transports snowflake=8

It may have something to do with #26771 (moved), which is a change of bridge authority. Apparently there was something wrong with the previous bridge authority, Bifroest. But I don't know if it could have caused this problem. https://lists.torproject.org/pipermail/tor-announce/2018-July/000162.html

I've added this line to the torrc, but I don't think it will help. I believe the bridge authority is only for BridgeDB purposes, not for metrics collecting.

AlternateBridgeAuthority Serge orport=9001 bridge 66.111.2.131:9030 BA44 A889 E64B 93FA A2B1 14E0 2C2A 279A 8555 C533

In May 2017, we had the same problem of the Snowflake bridge not publishing statistics. Then, we worked around it by setting AssumeReachable 1. Two other default bridges, cymrubridge31 and cymrubridge33, were not—and still are not :(—publishing statistics, and no one was ever able to determine the cause. Maybe we are being affected by the same thing again. https://lists.torproject.org/pipermail/tor-dev/2017-May/012241.html https://lists.torproject.org/pipermail/tor-dev/2017-June/012291.html (thread continues)

Replying to dcf:

I've added this line to the torrc, but I don't think it will help. I believe the bridge authority is only for BridgeDB purposes, not for metrics collecting.

I think it's both -- I believe the way the pipeline works is that your bridge publishes its extrainfo descriptor to the bridge authority, which syncs it to bridgedb, which syncs it to the metrics data set, and from there it works its way to onionoo and to relay-search.

There is a new line on the Snowflake metrics graph: https://metrics.torproject.org/userstats-bridge-transport.html?start=2018-04-14&end=2018-07-20&transport=snowflake

All rare transports seem to follow this pattern: https://metrics.torproject.org/userstats-bridge-transport.html?start=2018-04-14&end=2018-07-20&transport=obfs2&transport=websocket&transport=fte&transport=scramblesuit&transport=snowflake

Replying to teor:

All rare transports seem to follow this pattern: https://metrics.torproject.org/userstats-bridge-transport.html?start=2018-04-14&end=2018-07-20&transport=obfs2&transport=websocket&transport=fte&transport=scramblesuit&transport=snowflake

I don't think it's rare transports, but rather bridges in general. See for example the gap between 2018-07-06 and 2018-07-15 here, across all transports: https://metrics.torproject.org/userstats-bridge-country.html

The question in this ticket is not why there is no data in the middle of July, but why there is no data in the middle of June. Snowflake does differ from the other transports in that effect.

I guess these missing days of metrics will remain a mystery.

I've noted it on the Metrics Timeline.

Trac:
Status: new to closed
Resolution: N/A to wontfix

closed

moved to tpo/anti-censorship/pluggable-transports/snowflake#26783 (closed)