Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:50:35Zhttps://gitlab.torproject.org/legacy/trac/-/issues/33120Resolve TROVE-2020-0022020-06-13T15:50:35ZNick MathewsonResolve TROVE-2020-002This is the description I posted in the changelog:
```
TROVE-2020-002 is a vulnerability affecting
all released Tor instances since 0.2.1.5-alpha. Using this
vulnerability, an attacker could cause Tor instances to consume a huge
...This is the description I posted in the changelog:
```
TROVE-2020-002 is a vulnerability affecting
all released Tor instances since 0.2.1.5-alpha. Using this
vulnerability, an attacker could cause Tor instances to consume a huge
amount of CPU, disrupting their operations for several seconds or
minutes. This attack could be launched by anybody against a relay, or
by a directory cache against any client that had connected to it. The
attacker could launch this attack as much as they wanted, thereby
disrupting service or creating patterns that could aid in traffic
analysis. This issue was found by OSS-Fuzz, and is also tracked
as CVE-2020-10592.
```
I will post a more detailed analysis in a week or so.
This issue is fixed in today's Tor releases: 0.3.5.10, 0.4.1.9, 0.4.2.7, and 0.4.3.3-alpha.Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/33076Graph consensus and vote information from Rob's experiments2022-03-04T12:51:36ZMike PerryGraph consensus and vote information from Rob's experimentsThis is a ticket for the work to graph the historical onionperf data from Rob's relay flooding experiment.
Some discussion threads:
https://lists.torproject.org/pipermail/tor-scaling/2019-December/000077.html
https://lists.torproject.or...This is a ticket for the work to graph the historical onionperf data from Rob's relay flooding experiment.
Some discussion threads:
https://lists.torproject.org/pipermail/tor-scaling/2019-December/000077.html
https://lists.torproject.org/pipermail/tor-scaling/2020-January/000081.html
Basically, we want to have a standard way to graph results from key metrics from before, during, and after the experiment.
In this case, we want CDF-TTFB, CDF-DL from onionperf results.
We also want CDF-Relay-Stream-Capacity and CDF-Relay-Utilization for the consensus, as well as from the votes, to see if the votes from TorFlow drastically differ from sbws during the experiment.
https://trac.torproject.org/projects/tor/wiki/org/roadmaps/CoreTor/PerformanceMetrics
**Update from June 10, 2020: We finished the CDF-TTFB and CDF-DL portions by adding these graphs to OnionPerf's visualize mode. The remaining parts are the CDF-Relay-* graphs that are based on consensuses and votes. Keep this in mind when reading comments up to June 10, 2020.**https://gitlab.torproject.org/legacy/trac/-/issues/33065metrics dirbytes graph either underreports or leaves out dir auths?2020-06-13T18:15:31ZRoger Dingledinemetrics dirbytes graph either underreports or leaves out dir auths?https://metrics.torproject.org/dirbytes.html
shows that on average about 1gbit/s is spent serving directory information.
But the investigations in #33018 show that moria1 by itself is pushing about 135mbit/s, and I hear gabelmoo is doin...https://metrics.torproject.org/dirbytes.html
shows that on average about 1gbit/s is spent serving directory information.
But the investigations in #33018 show that moria1 by itself is pushing about 135mbit/s, and I hear gabelmoo is doing even more than that.
The text under the graph says "directory mirrors", so maybe we are leaving out dir auths in this graph? In that case, it would be cool to change it to one of those layered graphs so you can see how much of the total is dir auths and how much of the total are other relays.
Or maybe we're somehow not adding up the right things? Step zero is to spot-check the current data and the current graphs and become convinced that indeed we're presenting the right data.
Originally reported in
https://trac.torproject.org/projects/tor/ticket/33018#comment:3Karsten LoesingKarsten Loesinghttps://gitlab.torproject.org/legacy/trac/-/issues/32938Have a way to test throughput of snowflake proxy2020-06-13T18:21:25ZCecylia BocovichHave a way to test throughput of snowflake proxyA common question from snowflake proxy volunteers is whether or not their proxy is working (see comment 11 on #31109). It would be great to have some kind of bandwidth test for proxy owners to see whether or not their proxy is reachable ...A common question from snowflake proxy volunteers is whether or not their proxy is working (see comment 11 on #31109). It would be great to have some kind of bandwidth test for proxy owners to see whether or not their proxy is reachable from a remote probe point. This might also help us find and diagnose problems with existing proxies.
Some notes:
- we can't ask the broker to assign us a specific proxy at the moment so this test would likely be separate from the broker (unless we add an entirely new feature which I'm hesitant to do)
- we'll have to protect this service from abuse somehow, probably by rate-limiting. See some discussion on #31874. It would be best to engineer a way so that only a proxy owner can run the test on their proxy.Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/legacy/trac/-/issues/32711Gitlab repository is full and can't be updated2020-06-21T18:05:58ZCecylia BocovichGitlab repository is full and can't be updatedThe [current script](https://gitweb.torproject.org/gettor.git/tree/scripts/update_files?id=d3ac24f6af2f2bfffe66abade0376f801ac2e240) for updating the gitlab gettor repository with new Tor Browser binaries fails because the repository has...The [current script](https://gitweb.torproject.org/gettor.git/tree/scripts/update_files?id=d3ac24f6af2f2bfffe66abade0376f801ac2e240) for updating the gitlab gettor repository with new Tor Browser binaries fails because the repository has reached the storage limit size.
We should update this script with something that works for GitLab (note: we can't move to releases as in Github).Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/legacy/trac/-/issues/31646Update abicheck to require newer libstdc++.so.62020-06-16T01:07:16ZboklmUpdate abicheck to require newer libstdc++.so.6We should update `projects/firefox/abicheck.cc` to use features only provided by more recent versions of `libstdc++.so.6`.
Currently it only requires `GLIBCXX_3.4.22`:
```
$ strings tor-browser_en-US/Browser/abicheck | grep GLIBCXX_
GLI...We should update `projects/firefox/abicheck.cc` to use features only provided by more recent versions of `libstdc++.so.6`.
Currently it only requires `GLIBCXX_3.4.22`:
```
$ strings tor-browser_en-US/Browser/abicheck | grep GLIBCXX_
GLIBCXX_3.4
GLIBCXX_3.4.22
GLIBCXX_3.4.21
```
https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.htmlhttps://gitlab.torproject.org/legacy/trac/-/issues/31240Make confparse able to handle multiple config_format_t objects at once2020-06-13T15:43:49ZNick MathewsonMake confparse able to handle multiple config_format_t objects at onceBefore we can move on to #30866 and have the responsibility for configuration formats spread across modules, we need to have the confparse code able to handle multiple configuration objects and formats as if they were one.
I'm going to ...Before we can move on to #30866 and have the responsibility for configuration formats spread across modules, we need to have the confparse code able to handle multiple configuration objects and formats as if they were one.
I'm going to do this by introducing a "configuration manager" type that knows about a bunch of config_format_t objects. The configuration objects will be collected under a single top-level configuration object. (This approach lets us keep backward compatibility with a lot of the existing options management code.)Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/30889Eliminate some uses of lower-level control protocol output functions2020-06-13T15:42:36ZTaylor YuEliminate some uses of lower-level control protocol output functionsContinuing the work of #30007, refactor more control.c stuff to stop using lower-level control protocol output functions like `connection_write_str_to_buf()`, `connection_printf_to_buf()`, and `connection_buf_add()`.Continuing the work of #30007, refactor more control.c stuff to stop using lower-level control protocol output functions like `connection_write_str_to_buf()`, `connection_printf_to_buf()`, and `connection_buf_add()`.Tor: 0.4.2.x-finalTaylor YuTaylor Yuhttps://gitlab.torproject.org/legacy/trac/-/issues/30864Move variable manipulation code out of confparse.c2020-06-13T15:42:30ZNick MathewsonMove variable manipulation code out of confparse.cThere is some code in confparse.c for messing with arbitrary variables that ought to become general-purpose and go into lib/. This is a first step towards splitting config.c into reasonable pieces.There is some code in confparse.c for messing with arbitrary variables that ought to become general-purpose and go into lib/. This is a first step towards splitting config.c into reasonable pieces.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/30832Fix tor-browser tbb-tests2020-06-16T01:04:56ZAlex CatarineuFix tor-browser tbb-testsWith current rebased tor-browser ESR68 branch I can only run tbb-tests (with `run-tbb-tests` script) when `pref("network.file.path_blacklist", "/net")` is removed and `pref("extensions.torbutton.use_nontor_proxy", true);` is set, apart f...With current rebased tor-browser ESR68 branch I can only run tbb-tests (with `run-tbb-tests` script) when `pref("network.file.path_blacklist", "/net")` is removed and `pref("extensions.torbutton.use_nontor_proxy", true);` is set, apart from disabling tor-launcher. The second pref disables the domain isolator, which makes sense since it expects SOCKS5 proxies, but mochitests override that. For the other pref, not sure why `network.file.path_blacklist` needs to be unset (at least for Linux).
We could put these prefs in `testing/marionette/prefs/marionette.js` so that tests can be run (unless there is a simpler way to get the tests tor run that I'm missing).Alex CatarineuAlex Catarineuhttps://gitlab.torproject.org/legacy/trac/-/issues/30091Unify parsing code for control.c2020-06-13T15:41:38ZNick MathewsonUnify parsing code for control.cTor: 0.4.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/29729Work out which networks to run in Chutney's CI2020-06-13T13:30:47ZteorWork out which networks to run in Chutney's CIWork out which networks to run, and if they should have separate jobs.
We don't need to test all the networks, just the ones that test chutney features. In particular, we don't need a tor version vs chutney network matrix: that should g...Work out which networks to run, and if they should have separate jobs.
We don't need to test all the networks, just the ones that test chutney features. In particular, we don't need a tor version vs chutney network matrix: that should go in the tor branch CI, not the chutney CI.
The default network should test as many of tor/chutney's features as possible. If this network breaks on a particular tor version, we look at that Tor version's CI to see which particular networks have broken.
Then we want a separate job for each separate feature:
* a bridge network from "make test-network-all"
* an onion service v2 and v3 network from "make test-network-all"
* an IPv6 network from "make test-network-all"
We can add other networks as needed:
* when we add new features to chutney, like PTs
* if we break existing features without breaking chutney's CI
* if we break tor's CI without breaking chutney's CIteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/29204Inspect circuit queue during padding decisions2020-06-13T15:37:17ZMike PerryInspect circuit queue during padding decisionsWe need to inspect the circuit queue or the channel outbuf in some way during padding decisions. The problem is that if a guard stops reading on a channel, and padding keeps getting scheduled by the middle, it will overflow the circuit q...We need to inspect the circuit queue or the channel outbuf in some way during padding decisions. The problem is that if a guard stops reading on a channel, and padding keeps getting scheduled by the middle, it will overflow the circuit queue and/or outbuf for the channel and eventually oom.
Ideally, we would make our padding decision based on the EWMA values for the circuit rather than just checking if there were queued cells in the outbuf, but at minimum we need some kind of throttling so we don't keep adding cells to an circuit queue or outbuf above a certain length.
We may also want to use the circuit queue activity to update our last packet sent timers..Tor: 0.4.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/29034circuit: Cleanup an HS circuit when it is being re-purposed2020-06-13T15:42:10ZDavid Gouletdgoulet@torproject.orgcircuit: Cleanup an HS circuit when it is being re-purposedMike found out that when an IP/RP circuit fails to build in the right amount of time (for instance through `circuit_expire_building()`), it is re-purposed to become a measurement circuit.
The issue is that those HS circuits are set in t...Mike found out that when an IP/RP circuit fails to build in the right amount of time (for instance through `circuit_expire_building()`), it is re-purposed to become a measurement circuit.
The issue is that those HS circuits are set in the HS circuitmap and have an `hs_ident` or `rend_data` set to them that should really not linger in the circuit object if the circuit is not an HS one anymore.
Offenders: `circuit_build_times_mark_circ_as_measurement_only()` and `pathbias_send_usable_probe()`.
Solution:
`circuit_change_purpose()` is probably the right place to make a callback within the HS subsystem specific to cleaning up a circuit for a purpose change. I think we need a new function that specifically does that and not use `hs_circ_cleanup()` since it won't remove the ident.
Lingering circuits in the HS circuitmap is bad and this bug could probably explain some of the issues we had with clients unable to establish connections because the IP auth key wouldn't match the one in the circuit ident.
I strongly believe this should be backported up to 0.3.5 at the very least.Tor: 0.3.5.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/29023prop289: Implement a fast PRNG2020-06-13T15:36:29ZDavid Gouletdgoulet@torproject.orgprop289: Implement a fast PRNGIn order to add randomness to each relay cell, we require a very fast PRNG. This ticket is for the implementation of such a feature so we can use it for prop289.
The ticket that adds randomness is #26871.In order to add randomness to each relay cell, we require a very fast PRNG. This ticket is for the implementation of such a feature so we can use it for prop289.
The ticket that adds randomness is #26871.Tor: 0.4.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/28848Document Snowflake broker implementation2020-06-13T18:19:22ZAlexander Færøyahf@torproject.orgDocument Snowflake broker implementationWe should document how the current Snowflake implementation distributes Snowflake proxies to clients that is in need of them.
Once we have specified how the current implementation works, we should figure out if there are things we would...We should document how the current Snowflake implementation distributes Snowflake proxies to clients that is in need of them.
Once we have specified how the current implementation works, we should figure out if there are things we would like to change before we can start shipping Snowflake in an alpha state to users.
1) Look at broker code in the Snowflake repository.
2) Document current behavior with long-polling clients waiting to get handed a proxy.
3) Let's discuss if this design have any weaknesses we would like to address.
One weakness here could be that currently the broker nor client DOES NOT pass information about which bridge/relay to connect to, but this bridge/relay host is hardcoded in both the Go and JS proxy code.Alexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/27800Non-fatal assertion !(old) failed in node_add_to_ed25519_map2020-06-13T15:33:00ZStefani BanerianNon-fatal assertion !(old) failed in node_add_to_ed25519_mapthis error showed up in my logs today:
(happened on the directory authority `bastet`)
```
[warn] tor_bug_occurred_(): Bug: ../src/or/nodelist.c:297: node_add_to_ed25519_map: Non-fatal assertion !(old) failed. (on Tor 0.3.4.8 )
[warn] ...this error showed up in my logs today:
(happened on the directory authority `bastet`)
```
[warn] tor_bug_occurred_(): Bug: ../src/or/nodelist.c:297: node_add_to_ed25519_map: Non-fatal assertion !(old) failed. (on Tor 0.3.4.8 )
[warn] Bug: Non-fatal assertion !(old) failed in node_add_to_ed25519_map at ../src/or/nodelist.c:297. Stack trace: (on Tor 0.3.4.8 )
[warn] Bug: /usr/bin/tor(log_backtrace+0x44) [0x560fb19f0354] (on Tor 0.3.4.8 )
[warn] Bug: /usr/bin/tor(tor_bug_occurred_+0xb9) [0x560fb1a0b2f9] (on Tor 0.3.4.8 )
[warn] Bug: /usr/bin/tor(+0x648b1) [0x560fb18cc8b1] (on Tor 0.3.4.8 )
[warn] Bug: /usr/bin/tor(nodelist_set_routerinfo+0x13f) [0x560fb18ce9ef] (on Tor 0.3.4.8 )
[warn] Bug: /usr/bin/tor(+0x9d7ec) [0x560fb19057ec] (on Tor 0.3.4.8 )
[warn] Bug: /usr/bin/tor(router_add_to_routerlist+0x814) [0x560fb190bb94] (on Tor 0.3.4.8 )
[warn] Bug: /usr/bin/tor(dirserv_add_descriptor+0x228) [0x560fb19aefa8] (on Tor 0.3.4.8 )
[warn] Bug: /usr/bin/tor(dirserv_add_multiple_descriptors+0x154) [0x560fb19af294] (on Tor 0.3.4.8 )
[warn] Bug: /usr/bin/tor(connection_dir_process_inbuf+0xabc) [0x560fb19a494c] (on Tor 0.3.4.8 )
[warn] Bug: /usr/bin/tor(connection_handle_read+0xa27) [0x560fb197d717] (on Tor 0.3.4.8 )
[warn] Bug: /usr/bin/tor(+0x53afe) [0x560fb18bbafe] (on Tor 0.3.4.8 )
[warn] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x6a0) [0x7fefd7df25a0] (on Tor 0.3.4.8 )
[warn] Bug: /usr/bin/tor(do_main_loop+0x265) [0x560fb18bde95] (on Tor 0.3.4.8 )
[warn] Bug: /usr/bin/tor(tor_run_main+0x1175) [0x560fb18c0685] (on Tor 0.3.4.8 )
[warn] Bug: /usr/bin/tor(tor_main+0x3a) [0x560fb18b84ba] (on Tor 0.3.4.8 )
[warn] Bug: /usr/bin/tor(main+0x19) [0x560fb18b8229] (on Tor 0.3.4.8 )
[warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7fefd664e2e1] (on Tor 0.3.4.8 )
[warn] Bug: /usr/bin/tor(_start+0x2a) [0x560fb18b827a] (on Tor 0.3.4.8 )
```Tor: 0.3.5.x-finalTaylor YuTaylor Yuhttps://gitlab.torproject.org/legacy/trac/-/issues/27604Relocating the Tor Browser directory is broken with Tor Browser 82020-06-16T00:50:51ZGeorg KoppenRelocating the Tor Browser directory is broken with Tor Browser 8In Tor Browser 7 users were able to extract Tor Browser in directory `foo` run it and copy it over to `bar` and run it. Starting with Tor Browser 8 this does not seem to be possible anymore. See, for instance, the respective report on ou...In Tor Browser 7 users were able to extract Tor Browser in directory `foo` run it and copy it over to `bar` and run it. Starting with Tor Browser 8 this does not seem to be possible anymore. See, for instance, the respective report on our blog: https://blog.torproject.org/comment/277011#comment-277011.https://gitlab.torproject.org/legacy/trac/-/issues/27359Store family lists more efficiently2020-06-13T15:33:35ZNick MathewsonStore family lists more efficientlyLooking at the analysis, our storage for family lists accounted for 1.3MB out of 24.9MB total allocation. That's around 5% of our total allocation, not counting malloc overhead.
Fortunately, this will be pretty easy to fix.Looking at the analysis, our storage for family lists accounted for 1.3MB out of 24.9MB total allocation. That's around 5% of our total allocation, not counting malloc overhead.
Fortunately, this will be pretty easy to fix.Tor: 0.4.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/22789Tor 0.3.1.4-alpha crash on OpenBSD-current2020-06-13T15:11:01ZfredzupyTor 0.3.1.4-alpha crash on OpenBSD-currentHi,
After a few hours running, my new freshly compiled Tor 0.3.1.4-alpha has crashed with this message in log :
Jul 1 05:06:47 ethnao Tor[94685]: tor_assertion_failed_(): Bug: src/common/compat.c:2597: tor_inet_pton: Assertion next !...Hi,
After a few hours running, my new freshly compiled Tor 0.3.1.4-alpha has crashed with this message in log :
Jul 1 05:06:47 ethnao Tor[94685]: tor_assertion_failed_(): Bug: src/common/compat.c:2597: tor_inet_pton: Assertion next != src failed; aborting. (on Tor 0.3.1.4-alpha fab91a290ded3e74)
Jul 1 05:06:47 ethnao Tor[94685]: Bug: Assertion next != src failed in tor_inet_pton at src/common/compat.c:2597. (Stack trace not available) (on Tor 0.3.1.4-alpha fab91a290ded3e74)
Things I've done before :
$ ./configure
$ make
$ make test
$ doas src/or/tor -f /etc/tor/torrc
Then put some load on the Tor process with some random http request.
Logs with context :
Jul 1 05:06:02 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $0DA9BD201766EDB19F57F49F1A013A8A5432C008~PhantomTrain4 at 65.19.167.131. Retrying on a new circuit.
Jul 1 05:06:03 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $0DA9BD201766EDB19F57F49F1A013A8A5432C008~PhantomTrain4 at 65.19.167.131. Retrying on a new circuit.
Jul 1 05:06:04 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $0DA9BD201766EDB19F57F49F1A013A8A5432C008~PhantomTrain4 at 65.19.167.131. Retrying on a new circuit.
Jul 1 05:06:07 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $379FB450010D17078B3766C2273303C358C3A442~aurora at 176.126.252.12. Retrying on a new circuit.
Jul 1 05:06:11 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $379FB450010D17078B3766C2273303C358C3A442~aurora at 176.126.252.12. Retrying on a new circuit.
Jul 1 05:06:12 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $379FB450010D17078B3766C2273303C358C3A442~aurora at 176.126.252.12. Retrying on a new circuit.
Jul 1 05:06:15 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $379FB450010D17078B3766C2273303C358C3A442~aurora at 176.126.252.12. Retrying on a new circuit.
Jul 1 05:06:17 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $379FB450010D17078B3766C2273303C358C3A442~aurora at 176.126.252.12. Retrying on a new circuit.
Jul 1 05:06:17 ethnao Tor[94685]: Tried for 133 seconds to get a connection to [scrubbed]:80. Giving up.
Jul 1 05:06:18 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $379FB450010D17078B3766C2273303C358C3A442~aurora at 176.126.252.12. Retrying on a new circuit.
Jul 1 05:06:18 ethnao Tor[94685]: Tried for 125 seconds to get a connection to [scrubbed]:80. Giving up.
Jul 1 05:06:19 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $379FB450010D17078B3766C2273303C358C3A442~aurora at 176.126.252.12. Retrying on a new circuit.
Jul 1 05:06:21 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $14F92FF956105932E9DEC5B82A7778A0B1BD9A52~hessel0 at 109.163.234.2. Retrying on a new circuit.
Jul 1 05:06:22 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $14F92FF956105932E9DEC5B82A7778A0B1BD9A52~hessel0 at 109.163.234.2. Retrying on a new circuit.
Jul 1 05:06:22 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $14F92FF956105932E9DEC5B82A7778A0B1BD9A52~hessel0 at 109.163.234.2. Retrying on a new circuit.
Jul 1 05:06:26 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $14F92FF956105932E9DEC5B82A7778A0B1BD9A52~hessel0 at 109.163.234.2. Retrying on a new circuit.
Jul 1 05:06:27 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $14F92FF956105932E9DEC5B82A7778A0B1BD9A52~hessel0 at 109.163.234.2. Retrying on a new circuit.
Jul 1 05:06:30 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $14F92FF956105932E9DEC5B82A7778A0B1BD9A52~hessel0 at 109.163.234.2. Retrying on a new circuit.
Jul 1 05:06:34 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $14F92FF956105932E9DEC5B82A7778A0B1BD9A52~hessel0 at 109.163.234.2. Retrying on a new circuit.
Jul 1 05:06:36 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $E444FE133F55B6FFD338337AA42BA199581E2C4B~spacitospacito2 at 51.15.52.230. Retrying on a new circuit.
Jul 1 05:06:38 ethnao Tor[94685]: We tried for 16 seconds to connect to '[scrubbed]' using exit $E444FE133F55B6FFD338337AA42BA199581E2C4B~spacitospacito2 at 51.15.52.230. Retrying on a new circuit.
Jul 1 05:06:38 ethnao Tor[94685]: We tried for 16 seconds to connect to '[scrubbed]' using exit $E444FE133F55B6FFD338337AA42BA199581E2C4B~spacitospacito2 at 51.15.52.230. Retrying on a new circuit.
Jul 1 05:06:41 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $E444FE133F55B6FFD338337AA42BA199581E2C4B~spacitospacito2 at 51.15.52.230. Retrying on a new circuit.
Jul 1 05:06:41 ethnao Tor[94685]: Tried for 125 seconds to get a connection to [scrubbed]:80. Giving up.
Jul 1 05:06:42 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $E444FE133F55B6FFD338337AA42BA199581E2C4B~spacitospacito2 at 51.15.52.230. Retrying on a new circuit.
Jul 1 05:06:45 ethnao Tor[94685]: We tried for 15 seconds to connect to '[scrubbed]' using exit $E444FE133F55B6FFD338337AA42BA199581E2C4B~spacitospacito2 at 51.15.52.230. Retrying on a new circuit.
Jul 1 05:06:47 ethnao Tor[94685]: tor_assertion_failed_(): Bug: src/common/compat.c:2597: tor_inet_pton: Assertion next != src failed; aborting. (on Tor 0.3.1.4-alpha fab91a290ded3e74)
Jul 1 05:06:47 ethnao Tor[94685]: Bug: Assertion next != src failed in tor_inet_pton at src/common/compat.c:2597. (Stack trace not available) (on Tor 0.3.1.4-alpha fab91a290ded3e74)Tor: 0.3.1.x-finalNick MathewsonNick Mathewson