Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:07:45Zhttps://gitlab.torproject.org/legacy/trac/-/issues/16706Too many connection_edge_process_relay_cell warnings2020-06-13T15:07:45Zs7rToo many connection_edge_process_relay_cell warningsHosting multiple hidden services on a Debian server running Tor 0.2.6.10 (no special setup or config options). I see thousands of such lines in the log files:
```
Jul 31 07:55:39.000 [warn] connection_edge_process_relay_cell (at origin) ...Hosting multiple hidden services on a Debian server running Tor 0.2.6.10 (no special setup or config options). I see thousands of such lines in the log files:
```
Jul 31 07:55:39.000 [warn] connection_edge_process_relay_cell (at origin) failed.
Jul 31 07:57:59.000 [warn] connection_edge_process_relay_cell (at origin) failed.
Jul 31 08:00:36.000 [warn] connection_edge_process_relay_cell (at origin) failed.
Jul 31 08:02:49.000 [warn] connection_edge_process_relay_cell (at origin) failed.
Jul 31 08:05:12.000 [warn] connection_edge_process_relay_cell (at origin) failed.
Jul 31 08:07:30.000 [warn] connection_edge_process_relay_cell (at origin) failed.
Jul 31 08:09:49.000 [warn] connection_edge_process_relay_cell (at origin) failed.
Jul 31 08:12:09.000 [warn] connection_edge_process_relay_cell (at origin) failed.
Jul 31 08:14:30.000 [warn] connection_edge_process_relay_cell (at origin) failed.
Jul 31 08:16:50.000 [warn] connection_edge_process_relay_cell (at origin) failed.
Jul 31 08:19:11.000 [warn] connection_edge_process_relay_cell (at origin) failed.
Jul 31 08:21:45.000 [warn] connection_edge_process_relay_cell (at origin) failed.
Jul 31 08:24:14.000 [warn] connection_edge_process_relay_cell (at origin) failed.
Jul 31 08:26:27.000 [warn] connection_edge_process_relay_cell (at origin) failed.
Jul 31 08:29:01.000 [warn] connection_edge_process_relay_cell (at origin) failed.
Jul 31 08:31:18.000 [warn] connection_edge_process_relay_cell (at origin) failed.
Jul 31 08:33:38.000 [warn] connection_edge_process_relay_cell (at origin) failed.
Jul 31 08:35:58.000 [warn] connection_edge_process_relay_cell (at origin) failed.
```
All hidden services are working and accessible, didn't reload/restart Tor. What is concerning is that there are so so many of these messages in a very short time. #9635 mentioned this as well, but along with other error messages which were indicating a wrong nTor key. Here we only have a single line, heavily repeated at short time intervals.Tor: 0.3.1.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/20307[warn] Remote server sent bogus reason code 650212020-06-13T15:01:58ZRoger Dingledine[warn] Remote server sent bogus reason code 65021On my Tor client running 0.2.9.3-alpha-dev (git-bfaded9143d127cb) on a really crummy network, I got a string of 65 of these lines:
```
Oct 06 16:21:58.020 [warn] Remote server sent bogus reason code 65021
Oct 06 16:21:59.027 [warn] Remot...On my Tor client running 0.2.9.3-alpha-dev (git-bfaded9143d127cb) on a really crummy network, I got a string of 65 of these lines:
```
Oct 06 16:21:58.020 [warn] Remote server sent bogus reason code 65021
Oct 06 16:21:59.027 [warn] Remote server sent bogus reason code 65021
...
```
In fact, I got one of those warns per second for 65 seconds.
But when I look at the more detailed logs for the first one, I see
```
Oct 06 16:21:58.020 [info] circuit_build_failed(): Our circuit failed to get a response from the first hop (62.210.123.24:443). I'm going to try to rotate to a better connection.
Oct 06 16:21:58.020 [info] entry_guard_register_connect_status(): Unable to connect to entry guard 'Alastor' (2EB3C230180694A1E848001E20F36F76A2287039). Marking as unreachable.
Oct 06 16:21:58.020 [warn] Remote server sent bogus reason code 65021
Oct 06 16:21:58.020 [debug] circuit_get_by_circid_channel_impl(): circuit_get_by_circid_channel_impl() returning circuit 0x7fda41028de0 for circ_id 3884794536, channel ID 1 (0x7fda41c62410)
Oct 06 16:21:58.020 [debug] circuitmux_append_destroy_cell(): Cmux at 0x7fda41c625d0 queued a destroy for circ 3884794536, cmux counter is now 1, global counter is now 1
Oct 06 16:21:58.020 [debug] channel_send_destroy(): Sending destroy (circID 3884794536) on channel 0x7fda41c62410 (global ID 1)
```
So it would seem that no "end" cell was received at all. Maybe we are setting END_CIRC_REASON_FLAG_REMOTE somewhere where we shouldn't? Also, what is the mechanism by which the number makes it all the way up to 65021?Tor: 0.2.9.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/20306"Tor cannot connect to the Internet if ReachableAddresses, ReachableORAddress...2020-06-13T15:01:57ZRoger Dingledine"Tor cannot connect to the Internet if ReachableAddresses, ReachableORAddresses, or ReachableDirAddresses reject all addresses. Please accept some addresses in these options." when "FascistFirewall 1" is setI start my Tor client running 0.2.9.3-alpha-dev (git-bfaded9143d127cb) with `FascistFirewall 1`, and it says:
```
Oct 06 15:32:11.620 [notice] Converting FascistFirewall config option to new format: "ReachableDirAddresses *:80"
Oct 06 15...I start my Tor client running 0.2.9.3-alpha-dev (git-bfaded9143d127cb) with `FascistFirewall 1`, and it says:
```
Oct 06 15:32:11.620 [notice] Converting FascistFirewall config option to new format: "ReachableDirAddresses *:80"
Oct 06 15:32:11.620 [notice] Converting FascistFirewall config option to new format: "ReachableORAddresses *:443"
```
which is reasonable, but later it says
```
Oct 06 15:32:11.623 [warn] Tor cannot connect to the Internet if ReachableAddresses, ReachableORAddresses, or ReachableDirAddresses reject all addresses. Please accept some addresses in these options.
```
which is surprising.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/20269bridge users ignore their cached consensus file on startup2020-06-13T15:01:51ZRoger Dingledinebridge users ignore their cached consensus file on startupWhen a client has UseBridges set to 1, and it has a cached microdesc consensus in its datadir, when it starts up it loads that consensus file from disk, and calls `networkstatus_set_current_consensus()` on it.
That function checks
```
...When a client has UseBridges set to 1, and it has a cached microdesc consensus in its datadir, when it starts up it loads that consensus file from disk, and calls `networkstatus_set_current_consensus()` on it.
That function checks
```
if (flav != usable_consensus_flavor() &&
!directory_caches_dir_info(options)) {
/* This consensus is totally boring to us: we won't use it, and we won't
* serve it. Drop it. */
goto done;
}
```
and in this case, `usable_consensus_flavor()` checks `we_use_microdescriptors_for_circuits()` which decides
```
/* If we are configured to use bridges and none of our bridges
* know what a microdescriptor is, the answer is no. */
if (options->UseBridges && !any_bridge_supports_microdescriptors())
return 0;
```
That is, if you have bridges but you haven't marked any of them up yet, then you default to using the old-flavor consensus, so when you read your microdesc-consensus from disk, you quietly discard it. This bug results in bridge users always fetching a new consensus at start, even when they don't need to.
(Bug reported by [a person who was helpful at first but now seems to be trying to distract me and prevent me from fixing Tor bugs].)Tor: 0.3.0.x-finalRoger DingledineRoger Dingledinehttps://gitlab.torproject.org/legacy/trac/-/issues/20267Use -DOPENSSL_SYS_WIN32 on Windows2020-06-13T15:01:50ZteorUse -DOPENSSL_SYS_WIN32 on WindowsTor fails to compile on Windows MinGW/msys with an error about X509_NAME being an integer literal.
This is because OPENSSL_SYS_WIN32 is not defined, but it should be.
When we are on Win32, we should define this preprocessor directive.Tor fails to compile on Windows MinGW/msys with an error about X509_NAME being an integer literal.
This is because OPENSSL_SYS_WIN32 is not defined, but it should be.
When we are on Win32, we should define this preprocessor directive.Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/20070Make address choice failure log message more informative2020-06-13T15:01:07ZteorMake address choice failure log message more informativeLog a more informative message when we fail to find an address for a fallback or authority, because it has a hard-coded IPv6 address, but its descriptor does not have an IPv6 address.Log a more informative message when we fail to find an address for a fallback or authority, because it has a hard-coded IPv6 address, but its descriptor does not have an IPv6 address.Tor: 0.3.0.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/15434Tor dies if you send it a HUP before it read its config, and doesn't take PTs...2020-06-13T14:44:35ZTvdWTor dies if you send it a HUP before it read its config, and doesn't take PTs with itWhen sending tor a HUP before it has read its config, it will die, without killing its PTs. Starting tor again will then result in more PT crashes, as the ports will already be used by previous instances.
```
10149 ? Sl 0:00 ...When sending tor a HUP before it has read its config, it will die, without killing its PTs. Starting tor again will then result in more PT crashes, as the ports will already be used by previous instances.
```
10149 ? Sl 0:00 /usr/bin/obfs4proxy managed
10581 ? Sl 0:01 /usr/bin/tor -f /etc/tor/torrc-node1
10582 ? S 0:00 \_ /usr/bin/python /usr/bin/obfsproxy managed
10583 ? Z 0:00 \_ [obfs4proxy] <defunct>
10584 ? S 0:00 \_ /usr/bin/python /usr/bin/fteproxy --managed --mode server
```Tor: 0.2.7.x-finalRoger DingledineRoger Dingledine