Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2022-03-22T13:25:53Zhttps://gitlab.torproject.org/legacy/trac/-/issues/18517meek is broken in Tor Browser 6.0a32022-03-22T13:25:53ZGeorg Koppenmeek is broken in Tor Browser 6.0a3meek does not work any longer in Tor Browser 6.0a3. It seems this is caused by an underlying bug in tor. After some amount of testing and bisecting commit 23b088907fd23da417f5caf2b7b5f664f317ef4a is the first that introduces the new beha...meek does not work any longer in Tor Browser 6.0a3. It seems this is caused by an underlying bug in tor. After some amount of testing and bisecting commit 23b088907fd23da417f5caf2b7b5f664f317ef4a is the first that introduces the new behavior. Trying to start meek with it results in
```
Mar 10 13:50:53.000 [notice] Ignoring directory request, since no bridge nodes are available yet.
Mar 10 13:50:54.000 [notice] Delaying directory fetches: No running bridges
```
and nothing thereafter: the startup is stalled.Tor: 0.2.8.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/24708Make the fallback script search harder for python2020-06-13T16:06:15ZteorMake the fallback script search harder for pythonSome OSs don't put python in /usr/bin. pastly will tell you this.Some OSs don't put python in /usr/bin. pastly will tell you this.Tor: 0.3.3.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/20945Avoid an error in the fallback script when a fallback doesn't have any uptime2020-06-13T16:05:58ZteorAvoid an error in the fallback script when a fallback doesn't have any uptimeSometimes, the fallback generation script doesn't add attributes to the
fallbacks in the list. If this happens, log an error, and avoid selecting
that fallback.
Solution in #18828.Sometimes, the fallback generation script doesn't add attributes to the
fallbacks in the list. If this happens, log an error, and avoid selecting
that fallback.
Solution in #18828.teorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/20177When checking existing fallbacks, report those fallbacks at warning log level2020-06-13T16:05:46ZteorWhen checking existing fallbacks, report those fallbacks at warning log levelWhen the fallback script excludes some relays, it only logs at info level. This is usually what we want, but when checking existing fallbacks, it would be great to see any message about those fallbacks at WARNING log level.
This would m...When the fallback script excludes some relays, it only logs at info level. This is usually what we want, but when checking existing fallbacks, it would be great to see any message about those fallbacks at WARNING log level.
This would make it easier to work out why fallbacks are broken.Tor: unspecifiedhaxxpophaxxpophttps://gitlab.torproject.org/legacy/trac/-/issues/20175Allow the fallback script to ignore temporary IPv6 addresses2020-06-13T16:05:45ZteorAllow the fallback script to ignore temporary IPv6 addressesWhen updateFallbackDirs.py checks relay addresses, it makes sure that the IPv4 and IPv6 addresses and ports match the relay's whitelist entry.
If a relay's IPv6 address is temporary, it should not be included in the whitelist.
But this...When updateFallbackDirs.py checks relay addresses, it makes sure that the IPv4 and IPv6 addresses and ports match the relay's whitelist entry.
If a relay's IPv6 address is temporary, it should not be included in the whitelist.
But this means the relay will never be selected, because its descriptor has an IPv6 address, and that address doesn't match the (missing) address in the whitelist.
We should add a way to say ipv6=ignored or something.Tor: unspecifiedhaxxpophaxxpophttps://gitlab.torproject.org/legacy/trac/-/issues/20174Automate checking existing fallbacks2020-06-13T16:05:45ZteorAutomate checking existing fallbacksI use a manual process to check existing fallbacks. It would be great if the updateFallbackDirs.py script would automatically read src/or/fallback_dirs.inc, and check each fallback for errors.
For details, see:
https://trac.torproject.o...I use a manual process to check existing fallbacks. It would be great if the updateFallbackDirs.py script would automatically read src/or/fallback_dirs.inc, and check each fallback for errors.
For details, see:
https://trac.torproject.org/projects/tor/wiki/doc/UpdatingFallbackDirectoryMirrors
I think it can go in 0.3.0Tor: 0.3.0.x-finalhaxxpophaxxpophttps://gitlab.torproject.org/legacy/trac/-/issues/18348Tor conflates IPv4 Dir port with IPv6 OR Port2020-06-13T16:03:34ZMatthew FinkelTor conflates IPv4 Dir port with IPv6 OR PortSince #17840 tor prefers IPv6 addresses for client connections when they're available. This is a significant improvement but is not always correct in the network as it is now. Unfortunately, this affects a relays dirconns, too. The prima...Since #17840 tor prefers IPv6 addresses for client connections when they're available. This is a significant improvement but is not always correct in the network as it is now. Unfortunately, this affects a relays dirconns, too. The primary problem arises when a relay attempt a descriptor upload/fetch with a directory authority with an IPv6 OR port.
Currently all configuration options allow configuring IPv6 OR ports, but none specify dir ports. When a client attempts a dir port connection, it implicitly assumes the dir port is listening on the same ip address as the OR port.
Currently most of the dir auths Dir ports are only listening on their ipv4 address, including the dir auths with ipv6 OR addresses. An easy (but not necessary correct) solution is Dir Auth Op configure their dirauths so they accept ipv6 connections on the dir port. A better solution is tor knows when a dir port is ipv4 or ipv6 and chooses the correct corresponding ip address.
Now, as a relay, in fascist_firewall_allows_dir_server() we choose the destination's ipv4 address. However, when we subsequently call directory_choose_address_routerstatus() we don't remember which address we prefer:
```
} else {
/* We use an IPv6 address if we have one and we prefer it.
* Use the preferred address and port if they are reachable, otherwise,
* use the alternate address and port (if any).
*/
have_or = fascist_firewall_choose_address_rs(status,
FIREWALL_OR_CONNECTION, 0,
use_or_ap);
}
have_dir = fascist_firewall_choose_address_rs(status,
FIREWALL_DIR_CONNECTION, 0,
use_dir_ap);
```
Therefore directory_initiate_command_rend() uses the ipv6 address by default.
As an example (with additional debug messages):
```
Feb 19 16:57:33.000 [info] router_upload_dir_desc_to_dirservers: Uploading relay descriptor to directory authorities
Feb 19 16:57:33.000 [info] directory_post_to_dirservers: Uploading an extrainfo too (length 980)
Feb 19 16:57:33.000 [debug] directory_initiate_command_rend: anonymized 0, use_begindir 0.
Feb 19 16:57:33.000 [debug] directory_initiate_command_rend: Initiating server descriptor upload
Feb 19 16:57:33.000 [debug] connection_connect: Connecting to [scrubbed]:9131.
Feb 19 16:57:33.000 [debug] connection_connect_sockaddr: Connection to socket in progress (sock 32).
Feb 19 16:57:33.000 [debug] connection_add_impl: new conn type Directory, socket 32, address 128.31.0.39, n_conns 36.
Feb 19 16:57:33.000 [info] directory_post_to_dirservers: Uploading an extrainfo too (length 980)
Feb 19 16:57:33.000 [debug] directory_initiate_command_rend: anonymized 0, use_begindir 0.
Feb 19 16:57:33.000 [debug] directory_initiate_command_rend: Initiating server descriptor upload
Feb 19 16:57:33.000 [debug] connection_connect: Connecting to [scrubbed]:80.
Feb 19 16:57:33.000 [debug] connection_connect_sockaddr: Connection to socket in progress (sock 33).
Feb 19 16:57:33.000 [debug] connection_add_impl: new conn type Directory, socket 33, address 2001:858:2:2:aabb:0:563b:1526, n_conns 37.
...
Feb 19 16:57:33.000 [debug] conn_read_callback: socket 33 wants to read.
Feb 19 16:57:33.000 [debug] connection_handle_read_impl: Closing conn after error: Connection refused (61)
Feb 19 16:57:33.000 [info] connection_close_immediate: fd 33, type Directory, state connecting, 3298 bytes on outbuf.
Feb 19 16:57:33.000 [debug] conn_close_if_marked: Cleaning up connection (fd -1).
Feb 19 16:57:33.000 [info] connection_dir_request_failed: Setting dir 2001:858:2:2:aabb:0:563b:1526 as down after failed request.
Feb 19 16:57:33.000 [debug] router_set_status: Setting 86.59.21.38 as running: 0
Feb 19 16:57:33.000 [debug] router_set_status: Marking router $847B1F850344D7876491A54892F904934E4EB85D~tor26 at 86.59.21.38 as down.
Feb 19 16:57:33.000 [debug] connection_remove: removing socket -1 (type Directory), n_conns now 47
```
(this issue is only in master, not in any released version)
To make matters worse (and the reason I found this), eventually after most of the ipv6-enabled dir auths are marked as down due to the connection being refused, relays later get this scary thing:
```
Feb 19 09:26:53.000 [warn] router_picked_poor_directory_log: Bug: Firewall denied all OR and Dir addresses for all relays when searching for a directo
ry. (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: Node search initiated by. Stack trace: (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x1157ff8 <log_backtrace+0x48> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x10af99c <hid_serv_responsible_for_desc_id+0xebc> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x10a6ae6 <router_pick_trusteddirserver+0x76> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x1126333 <directory_get_from_dirserver+0x293> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x10ad4ba <launch_descriptor_downloads+0x4ba> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x10ad27a <launch_descriptor_downloads+0x27a> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x10adbcb <update_consensus_router_descriptor_downloads+0x6cb> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x10ac856 <update_all_descriptor_downloads+0x66> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x10602c8 <directory_info_has_arrived+0x48> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x1128a40 <connection_dir_reached_eof+0x1160> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x110810b <connection_handle_read+0xb3b> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x105f044 <connection_add_impl+0x214> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x801aa538e <event_base_loop+0x81e> at /usr/local/lib/libevent-2.0.so.5 (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x1060cc5 <do_main_loop+0x5c5> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x1062fcf <tor_main+0xdf> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x105ed49 <main+0x19> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
Feb 19 09:26:53.000 [warn] Bug: 0x105ec41 <_start+0x1a1> at /usr/local/bin/tor (on Tor 0.2.8.1-alpha-dev 1f679d4ae11cd976)
```
Because we already asked the useful dir auths for descriptors and those requests are still outstanding, so we don't have any viable directories remaining. (Ignore the mention of hid_serv_responsible_for_desc_id+0xbfb, it is actually router_pick_trusteddirserver_impl()).Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/33782Increases TEST_CONN_FD_INIT to make tests working on GitHub Actions2020-06-13T15:52:43ZTracIncreases TEST_CONN_FD_INIT to make tests working on GitHub ActionsWith the current value, which is 50; it will cause some tests to fail on GitHub Actions:
```
hs_client/e2e_rend_circuit_setup_legacy: [forking] Mar 31 17:01:17.348 [warn] tor_bug_occurred_(): Bug: src/lib/net/socket.c:237: tor_close_soc...With the current value, which is 50; it will cause some tests to fail on GitHub Actions:
```
hs_client/e2e_rend_circuit_setup_legacy: [forking] Mar 31 17:01:17.348 [warn] tor_bug_occurred_(): Bug: src/lib/net/socket.c:237: tor_close_socket__real: Non-fatal assertion n_sockets_open >= 0 failed. (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: Tor 0.4.2.5: Non-fatal assertion n_sockets_open >= 0 failed in tor_close_socket__real at src/lib/net/socket.c:237. Stack trace: (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(log_backtrace_impl+0x56) [0x55d2831c7696] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(tor_bug_occurred_+0x17f) [0x55d2831c2fcf] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(tor_close_socket__real+0xd7) [0x55d2831ba3f7] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(connection_free_minimal+0x1c7) [0x55d28302a507] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(+0x2d5dff) [0x55d282e91dff] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(+0x444c66) [0x55d283000c66] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(testcase_run_one+0x2f1) [0x55d283000fb1] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(tinytest_main+0x10c) [0x55d28300156c] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(main+0x2a0) [0x55d282cad9f0] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7) [0x7f65fdf83b97] (on Tor 0.4.2.5 )
Mar 31 17:01:17.349 [warn] Bug: ./src/test/test(_start+0x2a) [0x55d282cadb1a] (on Tor 0.4.2.5 )
[e2e_rend_circuit_setup_legacy FAILED]
```
The reason is because of a process running in GitHub Actions doing something that caused a lot of file descriptors to open. So, when Tor is trying to close a fake socket it ends up closing a real one that was opened by GitHub Actions.
I already tried with 100 and it does not work. So I tried 200 and it works.
**Trac**:
**Username**: ultimaweaponTor: 0.4.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/27096Stop relying on $HOME being set in the unit tests2020-06-13T15:29:15ZteorStop relying on $HOME being set in the unit testsWhen I test Tor with $HOME unset, I see the following error:
```
options/validate__uname_for_server: [forking]
FAIL ../src/test/test_options.c:507: expected log to not contain entries Captured logs:
1. warn: "Couldn\'t find $HOME...When I test Tor with $HOME unset, I see the following error:
```
options/validate__uname_for_server: [forking]
FAIL ../src/test/test_options.c:507: expected log to not contain entries Captured logs:
1. warn: "Couldn\'t find $HOME environment variable while expanding \"~/.tor\"; defaulting to \"\".\n"
2. warn: "Default DataDirectory is \"~/.tor\". This expands to \"/.tor\", which is probably not what you want. Using \"/usr/local/var/tor\" instead\n"
[validate__uname_for_server FAILED]
```
This test has been around since 0.2.8.1-alpha.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/24681Make the default fallback weight in Tor 10.02020-06-13T15:19:15ZteorMake the default fallback weight in Tor 10.0This is a follow-up to #24679.
* update the default weight in parse_dir_fallback_line() to 10.0
* update the man page to reflect the new default
10.0 gives us:
* 0.5% clients bootstrapping off an authority when all fallbacks are up, * ...This is a follow-up to #24679.
* update the default weight in parse_dir_fallback_line() to 10.0
* update the man page to reflect the new default
10.0 gives us:
* 0.5% clients bootstrapping off an authority when all fallbacks are up, * 2% when 25% are down (our replacement threshold)
* 7% when 40% are down (our worst case scenario)Tor: 0.3.3.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/23975Make node_get_pref_ipv6_orport() check addresses in the right order2020-06-13T15:18:27ZteorMake node_get_pref_ipv6_orport() check addresses in the right ordernode_get_pref_ipv6_orport() and node_get_prim_orport() check addresses in the following order:
* routerinfo / descriptor (modified by rewrite_bridge_address_for_node())
* routerstatus / consensus
* microdesc
Clients, bridge clients, an...node_get_pref_ipv6_orport() and node_get_prim_orport() check addresses in the following order:
* routerinfo / descriptor (modified by rewrite_bridge_address_for_node())
* routerstatus / consensus
* microdesc
Clients, bridge clients, and relays usually get the correct address from node_get_pref_ipv6_orport() and node_get_prim_orport(), whether they are using microdescriptors or not.
But there are a few cases when this breaks:
* bridge clients should only check routerinfo for configured bridges
* all clients and relays that use microdescs should never check full descriptors (and vice versa, except for the bridge case)
* all clients and relays that use full descriptors should ignore the IPv6 address in the descriptor
* all clients and relays that use microdescriptors should ignore the IPv6 address in the microdescriptor, when using a consensus method that puts IPv6 addresses in the microdesc consensus, otherwise they should use the microdescriptorTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/24006IPv6-only Tor2web has never actually connected to rend points over IPv62020-06-13T15:16:21ZteorIPv6-only Tor2web has never actually connected to rend points over IPv6This code should pass 1 to extend_info_from_node() when running Tor2web, and it should fall back to a 3-hop path if the node is NULL:
```
const node_t *node =
choose_good_exit_server(circ->base_.purpose, state->need_uptime,
...This code should pass 1 to extend_info_from_node() when running Tor2web, and it should fall back to a 3-hop path if the node is NULL:
```
const node_t *node =
choose_good_exit_server(circ->base_.purpose, state->need_uptime,
state->need_capacity, state->is_internal,
is_hs_v3_rp_circuit);
if (!node) {
log_warn(LD_CIRC,"Failed to choose an exit server");
return -1;
}
exit_ei = extend_info_from_node(node, 0);
if (BUG(exit_ei == NULL))
return -1;
```
I don't think we'll fix this, but I'm logging it for the record.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/23470Avoid relays resolving their own address on every download status check2020-06-13T15:13:31ZteorAvoid relays resolving their own address on every download status checkMy branch 21789-mitigate has a fix that avoids relays doing useless resolves every time they check a download status. (And clients never do those resolves, because they're clients.)My branch 21789-mitigate has a fix that avoids relays doing useless resolves every time they check a download status. (And clients never do those resolves, because they're clients.)Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/23415sample_laplace_distribution() should take multiple random inputs2020-06-13T15:13:20Zteorsample_laplace_distribution() should take multiple random inputsCurrently, sample_laplace_distribution() takes a random double as input, and then extracts the following random values:
* a random sign
* a random value in (0.0, 1.0]
This reduces the precision of the result. For details, see:
https://t...Currently, sample_laplace_distribution() takes a random double as input, and then extracts the following random values:
* a random sign
* a random value in (0.0, 1.0]
This reduces the precision of the result. For details, see:
https://trac.torproject.org/projects/tor/ticket/23061#comment:32
Instead, the function could take a random boolean sign and p, and the transform becomes:
```
result = mu - b * (sign ? 1.0 : -1.0)
* tor_mathlog(1.0 - p);
```
This would increase the precision by one bit, plus whatever precision is lost in `2.0 * fabs(p - 0.5)`.
This may have been introduced in dad5eb7.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/17750Make bootstrapping clients wait before trying an authority2020-06-13T15:13:07ZteorMake bootstrapping clients wait before trying an authorityIf this happens, 0 (or uninitialised data) is used instead of the zeroth schedule item. (This matters most for bridges, which have schedules that start at 60 rather than 0.)
I wonder if any of the existing Tor code does this?
We could ...If this happens, 0 (or uninitialised data) is used instead of the zeroth schedule item. (This matters most for bridges, which have schedules that start at 60 rather than 0.)
I wonder if any of the existing Tor code does this?
We could set a flag in download_status_t to 1 in download_status_reset, then assert it's set in the low-level functions that take a download_status_t:
* find_dl_schedule_and_len
* download_status_increment_failure
* (not download_status_reset, it sets the flag)
* download_status_get_n_failures
* download_status_get_next_attempt_atTor: 0.3.2.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/22760Fix extra-info flags on fallbacks2020-06-13T15:10:54ZteorFix extra-info flags on fallbacksSee the first comment for details.See the first comment for details.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/21720Update Directory Server Options section for automatic DirCache2020-06-13T15:07:17ZteorUpdate Directory Server Options section for automatic DirCacheThis section header is wrong:
```
DIRECTORY SERVER OPTIONS
The following options are useful only for directory servers (that is,
if DirPort is non-zero):
```
It should read:
```
DIRECTORY SERVER OPTIONS
The followin...This section header is wrong:
```
DIRECTORY SERVER OPTIONS
The following options are useful only for directory servers (that is,
if DirPort is non-zero):
```
It should read:
```
DIRECTORY SERVER OPTIONS
The following options are useful only for directory servers:
(Relays with enough bandwidth automatically become directory
servers, see DirCache for details.)
```Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/21506Client with current microdesc consensus but no descriptors chooses down fallb...2020-06-13T15:06:30ZteorClient with current microdesc consensus but no descriptors chooses down fallback every timeTor 0.2.9.9 doesn't have the fix for a similar issue in #20996, but 0.3.0.2-alpha does.
But this issue is different from that issue: the client downloads the consensus, then tries the same fallback (a down fallback) every time.
This re...Tor 0.2.9.9 doesn't have the fix for a similar issue in #20996, but 0.3.0.2-alpha does.
But this issue is different from that issue: the client downloads the consensus, then tries the same fallback (a down fallback) every time.
This really shouldn't happen: the client should choose a different relay every time.
My guess is that this relay is chosen because it's down, and all the up relay descriptors are unavailable. This is pathological behaviour.
I think we fixed it in 0.3.0.2-alpha with the patch to #20996, but I'm logging this bug just in case.
http://pastebin.ca/3769463Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/20887DIRCACHE_MIN_MEM_MB does not stringify on FreeBSD, we should use %d instead2020-06-13T15:04:02ZteorDIRCACHE_MIN_MEM_MB does not stringify on FreeBSD, we should use %d insteadA FreeBSD relay operator reports the message:
```
[WARN] Being a directory cache (default) with less than DIRCACHE_MIN_MB_BANDWIDTH MB of memory is not recommended and may consume most of the available resources, consider disabling this ...A FreeBSD relay operator reports the message:
```
[WARN] Being a directory cache (default) with less than DIRCACHE_MIN_MB_BANDWIDTH MB of memory is not recommended and may consume most of the available resources, consider disabling this functionality by setting the DirCache option to 0
```
So we should print the macro value the same way we do every other value, using "%d" in the string, and passing it as an argument.
(This macro changed name in #20684.)Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/20684DIRCACHE_MIN_MB_BANDWIDTH is actually used for RAM2020-06-13T15:03:27ZteorDIRCACHE_MIN_MB_BANDWIDTH is actually used for RAMWe should change DIRCACHE_MIN_BANDWIDTH and DIRCACHE_MIN_MB_BANDWIDTH to end in *_MEM, as they are only ever used for memory, not bandwidth.
Introduced in commit 997f779 in tor-0.2.8.1-alpha.We should change DIRCACHE_MIN_BANDWIDTH and DIRCACHE_MIN_MB_BANDWIDTH to end in *_MEM, as they are only ever used for memory, not bandwidth.
Introduced in commit 997f779 in tor-0.2.8.1-alpha.Tor: 0.3.0.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.org