Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2021-02-17T09:23:04Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32165On first boot, Tor mistakenly tells me "The current consensus has no exit nodes"2021-02-17T09:23:04ZRoger DingledineOn first boot, Tor mistakenly tells me "The current consensus has no exit nodes"Starting up 0.4.3.0-alpha-dev (git-71daad1692bc3f24) without any cached-* files in my DataDirectory, I get:
```
Oct 20 04:44:56.026 [notice] Bootstrapped 30% (loading_status): Loading networkstatus consensus
Oct 20 04:44:56.636 [notice] ...Starting up 0.4.3.0-alpha-dev (git-71daad1692bc3f24) without any cached-* files in my DataDirectory, I get:
```
Oct 20 04:44:56.026 [notice] Bootstrapped 30% (loading_status): Loading networkstatus consensus
Oct 20 04:44:56.636 [notice] I learned some more directory information, but not enough to build a circuit: We have no usable consensus.
Oct 20 04:44:56.758 [notice] Bootstrapped 40% (loading_keys): Loading authority key certs
Oct 20 04:44:56.936 [notice] The current consensus has no exit nodes. Tor can only build internal paths, such as paths to onion services.
Oct 20 04:44:56.936 [notice] Bootstrapped 45% (requesting_descriptors): Asking for relay descriptors
Oct 20 04:44:56.936 [notice] I learned some more directory information, but not enough to build a circuit: We need more microdescriptors: we have 0/5841, and can only build 0% of likely paths. (We have 0% of guards bw, 0% of midpoint bw, and 0% of end bw (no exits in consensus, using mid) = 0% of path bw.)
Oct 20 04:44:57.337 [notice] Bootstrapped 50% (loading_descriptors): Loading relay descriptors
Oct 20 04:44:57.592 [notice] The current consensus contains exit nodes. Tor can build exit and internal paths.
Oct 20 04:44:58.178 [notice] Bootstrapped 58% (loading_descriptors): Loading relay descriptors
```
It's that "The current consensus has no exit nodes." line that is out of place.https://gitlab.torproject.org/tpo/core/tor/-/issues/19069When DisableNetwork is 1 but !circuit_enough_testing_circs(), we can still la...2022-06-24T16:12:14ZRoger DingledineWhen DisableNetwork is 1 but !circuit_enough_testing_circs(), we can still launch circuitsIn consider_testing_reachability(), we check
```
if (test_or && (!orport_reachable || !circuit_enough_testing_circs())) {
```
Once legacy/trac#18616 is merged, the first function will return 1 for orport_reachable when DisableNetwork ...In consider_testing_reachability(), we check
```
if (test_or && (!orport_reachable || !circuit_enough_testing_circs())) {
```
Once legacy/trac#18616 is merged, the first function will return 1 for orport_reachable when DisableNetwork is 1, so that bug will go away.
But it will remain the case that if !circuit_enough_testing_circs(), we will proceed to call circuit_launch_by_extend_info(), even when DisableNetwork is 1.
There are four places that call consider_testing_reachability():
* circuitbuild.c:circuit_send_next_onion_skin()
* circuituse.c:circuit_testing_opened()
* main.c:directory_info_has_arrived()
* main.c:check_for_reachability_bw_callback()
I think the middle two are safe, since they shouldn't happen while DisableNetwork is set.
I think the first one is iffy, since it's called from a bunch of places so I'm not sure, but given the name I hope it doesn't get called during DisableNetwork.
And I think the fourth one is bad news, since it gets called periodically and doesn't check DisableNetwork.https://gitlab.torproject.org/tpo/core/tor/-/issues/16844Slow clients can't bootstrap because they expire their consensus fetch but th...2023-04-10T15:03:45ZRoger DingledineSlow clients can't bootstrap because they expire their consensus fetch but then receive all the bytes from it anyway, making them expire their next fetch, putting them in a terrible loopIf you start your Tor client with no cached directory info, and on a slow (high latency) link, you get:
```
$ tail -f tordebug-log|grep connected
Aug 09 16:17:12.299 [info] circuit_handle_first_hop(): Next router is $7EA6EAD6FD83083C538...If you start your Tor client with no cached directory info, and on a slow (high latency) link, you get:
```
$ tail -f tordebug-log|grep connected
Aug 09 16:17:12.299 [info] circuit_handle_first_hop(): Next router is $7EA6EAD6FD83083C538F44038BBFA077587DD755~7EA6EAD6FD83083C538 at 194.109.206.212: Not connected. Connecting.
Aug 09 16:17:12.826 [info] connection_edge_process_relay_cell_not_open(): 'connected' received for circid 2747423797 streamid 16685 after 0 seconds.
Aug 09 16:21:57.298 [info] circuit_handle_first_hop(): Next router is $9695DFC35FFEB861329B9F1AB04C46397020CE31~9695DFC35FFEB861329 at 128.31.0.39: Not connected. Connecting.
Aug 09 16:21:59.099 [info] connection_edge_process_relay_cell_not_open(): 'connected' received for circid 4248917890 streamid 42612 after 1 seconds.
Aug 09 16:22:09.711 [info] circuit_handle_first_hop(): Next router is $332CD489177F202570A7021328A17A91BF823889~332CD489177F202570A at 192.150.94.49: Not connected. Connecting.
Aug 09 16:22:09.711 [info] circuit_handle_first_hop(): Next router is $90E9E44FD74B98F87F7573F917AE4AF651B86B4C~90E9E44FD74B98F87F7 at 5.102.146.106: Not connected. Connecting.
Aug 09 16:22:09.712 [info] circuit_handle_first_hop(): Next router is $547C1CDB516798EC66A01F04A5884DCE1A151919~547C1CDB516798EC66A at 87.72.85.217: Not connected. Connecting.
Aug 09 16:22:12.499 [info] connection_edge_process_relay_cell_not_open(): 'connected' received for circid 2850575558 streamid 43745 after 0 seconds.
Aug 09 16:23:33.901 [info] connection_edge_process_relay_cell(): 'connected' received on circid 2850575558 for streamid 43746, no conn attached anymore. Ignoring.
Aug 09 16:24:11.599 [info] connection_edge_process_relay_cell_not_open(): 'connected' received for circid 4148503990 streamid 17036 after 0 seconds.
Aug 09 16:25:34.306 [info] connection_edge_process_relay_cell(): 'connected' received on circid 4148503990 for streamid 17037, no conn attached anymore. Ignoring.
Aug 09 16:26:29.559 [info] connection_edge_process_relay_cell_not_open(): 'connected' received for circid 2948078868 streamid 42748 after 0 seconds.
[...]
```
Oh hey, what's this "no conn attached anymore" issue?
```
$ grep 43746 tordebug-log
Aug 09 16:22:12.302 [info] connection_ap_handshake_send_begin(): Sending relay cell 1 on circ 2850575558 to begin stream 43746.
Aug 09 16:22:22.299 [debug] circuit_detach_stream(): Removing stream 43746 from circ 2850575558
Aug 09 16:23:33.901 [debug] connection_edge_process_relay_cell(): Now seen 1433 relay cells here (command 4, stream 43746).
Aug 09 16:23:33.901 [info] connection_edge_process_relay_cell(): 'connected' received on circid 2850575558 for streamid 43746, no conn attached anymore. Ignoring.
Aug 09 16:23:35.799 [debug] connection_edge_process_relay_cell(): Now seen 1434 relay cells here (command 2, stream 43746).
Aug 09 16:23:35.799 [info] connection_edge_process_relay_cell(): data cell dropped, unknown stream (streamid 43746).
[...]
```
We're hitting the 10-second stream timeout in connection_ap_expire_beginning(), and detaching the stream from the circuit, and presumably trying it again elsewhere.
But that last line above, "data cell dropped", is especially bad news for us -- we get the whole answer, and ignore it all, since we sent an 'end' cell changing our mind but the answer was already coming at us.
This situation comes up because of the optimistic data feature -- we get the answer to our request bundled with the 'connected' cell, which is a feature except in the case where we canceled (and then forgot about) the stream.
For people trying to bootstrap their Tor on a low-bandwidth high-latency network connection, I bet this landmine will be especially frustrating, since you will be clogging your network connection with directory information that you will discard, which in turn will delay the receipt of the other directory information.
You can reproduce the bug on your own, even if you have a great network connection, by starting your Tor with "bandwidthrate 2000 bandwidthburst 5000".https://gitlab.torproject.org/tpo/core/tor/-/issues/15661Same "non-loopback address" notice is printed twice2022-02-07T19:39:00Zyurivict271Same "non-loopback address" notice is printed twiceThe following command line produces each notice twice.
This is not a big deal, but something is wrong in the code and needs to be fixed.
```
/usr/local/bin/tor --ignore-missing-torrc -f /no/file --PidFile /var/tmp/vbox-to-tor/tap7/tor....The following command line produces each notice twice.
This is not a big deal, but something is wrong in the code and needs to be fixed.
```
/usr/local/bin/tor --ignore-missing-torrc -f /no/file --PidFile /var/tmp/vbox-to-tor/tap7/tor.pid --RunAsDaemon 1 --DataDirectory /var/tmp/vbox-to-tor/tap7/data --+Log "notice file /var/tmp/vbox-to-tor/tap7/tor.log" --DNSPort 53 --DNSListenAddress 172.16.7.1 --TransPort 9030 --TransListenAddress 172.16.7.1 --SocksPort 0
```
```
Apr 12 21:38:09.478 [notice] Tor v0.2.6.6 (git-bb8c4e69ca5c8bca) running on FreeBSD with Libevent 2.0.22-stable, OpenSSL 1.0.2a and Zlib 1.2.8.
Apr 12 21:38:09.478 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Apr 12 21:38:09.478 [notice] Configuration file "/no/file" not present, using reasonable defaults.
Apr 12 21:38:09.483 [notice] You configured a non-loopback address '172.16.7.1:53' for DNSPort. This allows everybody on your local network to use your machine as a proxy. Make sure this is what you wanted.
Apr 12 21:38:09.483 [notice] You configured a non-loopback address '172.16.7.1:9030' for TransPort. This allows everybody on your local network to use your machine as a proxy. Make sure this is what you wanted.
Apr 12 21:38:09.484 [notice] You configured a non-loopback address '172.16.7.1:53' for DNSPort. This allows everybody on your local network to use your machine as a proxy. Make sure this is what you wanted.
Apr 12 21:38:09.485 [notice] You configured a non-loopback address '172.16.7.1:9030' for TransPort. This allows everybody on your local network to use your machine as a proxy. Make sure this is what you wanted.
Apr 12 21:38:09.485 [notice] Opening DNS listener on 172.16.7.1:53
Apr 12 21:38:09.485 [notice] Opening Transparent pf/netfilter listener on 172.16.7.1:9030
Apr 12 21:38:09.485 [warn] Fixing permissions on directory /var/tmp/vbox-to-tor/tap7/data
```