The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T13:54:33Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24769Increase client idle and connection timeouts to reduce network load2020-06-27T13:54:33ZteorIncrease client idle and connection timeouts to reduce network loadThese changes were introduced in d5a151a in 0.3.1.1.
Maybe we should:
* revert the changes, or increase the values
* make consensus parameters for them
```
+/** If we haven't yet decided on a good timeout value for circuit
+ * building...These changes were introduced in d5a151a in 0.3.1.1.
Maybe we should:
* revert the changes, or increase the values
* make consensus parameters for them
```
+/** If we haven't yet decided on a good timeout value for circuit
+ * building, we close idle circuits aggressively so we can get more
+ * data points. */
+#define IDLE_TIMEOUT_WHILE_LEARNING (1*60)
```
```
-/** If we haven't yet decided on a good timeout value for circuit
- * building, we close idles circuits aggressively so we can get more
- * data points. */
-#define IDLE_TIMEOUT_WHILE_LEARNING (10*60)
```
```
+#define CONNTIMEOUT_CLIENTS_BASE 180 // 3 to 4.5 min
+ timeout = CONNTIMEOUT_CLIENTS_BASE
+ + crypto_rand_int(CONNTIMEOUT_CLIENTS_BASE/2);
```Tor: 0.3.3.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24767All relays are constantly connecting to down relays and failing over and over2022-10-11T23:40:02ZRoger DingledineAll relays are constantly connecting to down relays and failing over and overStarlight at
https://lists.torproject.org/pipermail/tor-relays/2017-December/014001.html
points out that when a relay is receiving many extend cells to extend circuits to a relay that's down, it will try over and over to make a new conne...Starlight at
https://lists.torproject.org/pipermail/tor-relays/2017-December/014001.html
points out that when a relay is receiving many extend cells to extend circuits to a relay that's down, it will try over and over to make a new connection to that next relay:
```
650 ORCONN $5E2975B380F6E908AFB29E0D8D0B967AF73B41C2~WombleNode01 LAUNCHED ID=61580092
650 ORCONN $5E2975B380F6E908AFB29E0D8D0B967AF73B41C2~WombleNode01 FAILED REASON=CONNECTREFUSED NCIRCS=4 ID=61580092
650 ORCONN $5E2975B380F6E908AFB29E0D8D0B967AF73B41C2~WombleNode01 LAUNCHED ID=61580095
650 ORCONN $5E2975B380F6E908AFB29E0D8D0B967AF73B41C2~WombleNode01 FAILED REASON=CONNECTREFUSED NCIRCS=3 ID=61580095
650 ORCONN $5E2975B380F6E908AFB29E0D8D0B967AF73B41C2~WombleNode01 LAUNCHED ID=61580098
[...]
```
It seems to me that if just a moment ago you tried to connect to a relay and you failed for reason connectrefused, then maybe you already know what the answer is going to be for other circuits that show up in that second.
How long should we cache the answer for? And, are there any anonymity implications to this design change? (We already batch circuit extend requests as they're waiting for the connect request to finish or fail, so I think whatever the anonymity implications are, maybe we already have them?)Tor: 0.3.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/24765What version of Rust does Tor require for 0.3.2?2021-07-22T16:21:37ZteorWhat version of Rust does Tor require for 0.3.2?On legacy/trac#24761, Sebastian says that we require Rust ~~1.14~~, but I can't see that documented anywhere.
We should document it:
* in the release notes
* in the wiki: https://trac.torproject.org/projects/tor/wiki/RustInTor
And poin...On legacy/trac#24761, Sebastian says that we require Rust ~~1.14~~, but I can't see that documented anywhere.
We should document it:
* in the release notes
* in the wiki: https://trac.torproject.org/projects/tor/wiki/RustInTor
And point to it from:
* https://gitweb.torproject.org/tor.git/tree/doc/HACKING/GettingStartedRust.md
And document the nightly/feature thing in our coding standards:
* https://gitweb.torproject.org/tor.git/tree/doc/HACKING/CodingStandardsRust.mdTor: 0.3.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24764OSX 10.13.2 (17C88) - Instant crash on startup2020-06-27T13:54:34ZTracOSX 10.13.2 (17C88) - Instant crash on startupWith the latest torbrowser, I get an instant crash as soon as it starts.
There is nothing in the log.
I did the usual uninstall / wipe data files / reinstall / reboot / etc.
When I start the browser, I get this error in the console, ...With the latest torbrowser, I get an instant crash as soon as it starts.
There is nothing in the log.
I did the usual uninstall / wipe data files / reinstall / reboot / etc.
When I start the browser, I get this error in the console, from EmojiFunctionRowIM_Extension:
<NSXPCConnection: 0x60c000105850> connection from pid 5063: Exception caught during decoding of received message, dropping incoming message.
Exception: Exception while decoding argument 0 (legacy/trac#2 of invocation):
<NSInvocation: 0x60400007d040>
return value: {v} void
target: {@} 0x0
selector: {:} null
argument 2: {{?=d@@@@{CGRect={CGPoint=dd}{CGSize=dd}}ccc@@@Ic}} <00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000>
argument 3: {@?} 0x0 (block)
Exception: decodeObjectForKey: class "TitlebarAndBackgroundColor" not loaded or does not exist
I do not know if this is what is bringing the browser down, but I only see that error when I try to launch the browser.
I tried to disable the emoji touchbar service, which created some unrelated odd problems, but that didn't change anything.
**Trac**:
**Username**: thomasd3https://gitlab.torproject.org/tpo/core/tor/-/issues/24763Tor make check FAIL: src/test/test (on OSX)2020-06-27T13:54:34ZTracTor make check FAIL: src/test/test (on OSX)I try to make tor from source following this https://trac.torproject.org/projects/tor/wiki/doc/MacBuild#ObtainingaRecentlibevent.
1) reinstall libevent
2) reinstall openssl
3) download tor-0.3.2.8-rc source
4) ./configure --prefix=/us...I try to make tor from source following this https://trac.torproject.org/projects/tor/wiki/doc/MacBuild#ObtainingaRecentlibevent.
1) reinstall libevent
2) reinstall openssl
3) download tor-0.3.2.8-rc source
4) ./configure --prefix=/usr/local/tor --with-openssl-dir=/usr/local/ssl --with-libevent-dir=/usr/local/lib && make
5) make check
After this I get:
```
FAIL: src/test/test
```
Why it could be?
Maybe because hardware acceleration is disabled in openssl configuration? Or it doesn't matter especially for tor?
**Trac**:
**Username**: lL__Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24762tor_remove_file() should ignore NULL filenames2020-06-27T13:54:34Zteortor_remove_file() should ignore NULL filenamesOtherwise, tor logs warnings on my macOS box that look like:
```
Couldn't unlink (null): Bad address
```Otherwise, tor logs warnings on my macOS box that look like:
```
Couldn't unlink (null): Bad address
```Tor: 0.3.3.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24761rust: protover.rs needs retain_hash_collection to build with older rustc vers...2020-06-27T13:54:34Zteorrust: protover.rs needs retain_hash_collection to build with older rustc versionsI was using rustc 1.19.0-nightly on master and received the following warning:
```
Compiling protover v0.0.1 (file:///Users/twilsonb/tor/tor-rust/src/rust/protover)
error: use of unstable library feature 'retain_hash_collection' (see ...I was using rustc 1.19.0-nightly on master and received the following warning:
```
Compiling protover v0.0.1 (file:///Users/twilsonb/tor/tor-rust/src/rust/protover)
error: use of unstable library feature 'retain_hash_collection' (see issue #36648)
--> protover/protover.rs:259:10
|
259 | vers.retain(|x| !supported_versions.contains(x));
| ^^^^^^
|
= help: add #![feature(retain_hash_collection)] to the crate attributes to enable
```
When I added the feature declaration, everything worked fine and the tests passed.Tor: 0.3.2.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24759(Sandbox) Caught a bad syscall attempt (syscall socket)2020-06-27T13:54:34ZTrac(Sandbox) Caught a bad syscall attempt (syscall socket)Hi,
With the following torrc I experience the subsequent trace:
```
Sandbox 1
DataDirectory /tmp/tmp2z5k8mqz
SocksPort 32609
ControlSocket /tmp/tmp2z5k8mqz/control_socket
CookieAuthentication 1
CookieAuthFile /tmp/tmp2z5k8mqz/cookie
Av...Hi,
With the following torrc I experience the subsequent trace:
```
Sandbox 1
DataDirectory /tmp/tmp2z5k8mqz
SocksPort 32609
ControlSocket /tmp/tmp2z5k8mqz/control_socket
CookieAuthentication 1
CookieAuthFile /tmp/tmp2z5k8mqz/cookie
AvoidDiskWrites 1
Log notice stdout
GeoIPFile /usr/share/tor/geoip
GeoIPv6File /usr/share/tor/geoip6
```
```
[user@host tmp2z5k8mqz]$ tor -f torrc
Dec 29 10:24:05.125 [notice] Tor 0.3.1.9 (git-727d3f1b5e6eeda7) running on Linux with Libevent 2.0.22-stable, OpenSSL 1.1.0g-fips, Zlib 1.2.11, Liblzma N/A, and Libzstd N/A.
Dec 29 10:24:05.125 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Dec 29 10:24:05.125 [notice] Read configuration file "/tmp/tmp2z5k8mqz/torrc".
Dec 29 10:24:05.128 [notice] Opening Socks listener on 127.0.0.1:32609
Dec 29 10:24:05.128 [notice] Opening Control listener on /tmp/tmp2z5k8mqz/control_socket
Dec 29 10:24:05.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
Dec 29 10:24:05.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
Dec 29 10:24:05.000 [notice] Bootstrapped 0%: Starting
Dec 29 10:24:06.000 [notice] Starting with guard context "default"
Dec 29 10:24:06.000 [notice] Bootstrapped 5%: Connecting to directory server
============================================================ T= 1514503447
(Sandbox) Caught a bad syscall attempt (syscall socket)
tor(+0x1853fa)[0x56068ff303fa]
/lib64/libc.so.6(socket+0x7)[0x7893d9664fb7]
/lib64/libc.so.6(socket+0x7)[0x7893d9664fb7]
/lib64/libc.so.6(+0x12e3fa)[0x7893d96813fa]
/lib64/libc.so.6(+0x12e4f1)[0x7893d96814f1]
/lib64/libc.so.6(getifaddrs+0x10)[0x7893d9682230]
tor(get_interface_addresses_raw+0x3c)[0x56068ff13eec]
tor(get_interface_address6_list+0x30)[0x56068ff14620]
tor(get_interface_address6+0x45)[0x56068ff14875]
tor(+0x109378)[0x56068feb4378]
tor(connection_handle_write+0x2e)[0x56068feb44ae]
tor(+0x4d5ce)[0x56068fdf85ce]
/lib64/libevent-2.0.so.5(event_base_loop+0x7a9)[0x7893da6943f9]
tor(do_main_loop+0x29d)[0x56068fdf978d]
tor(tor_main+0xe25)[0x56068fdfc5a5]
tor(main+0x19)[0x56068fdf5009]
/lib64/libc.so.6(__libc_start_main+0xea)[0x7893d957388a]
tor(_start+0x2a)[0x56068fdf505a]
```
It of course works with Sandbox 0.
Is there something in my config that is incompatible with the Sandbox mode?
Maybe related to 16579 except syslog is not the issue here.
Thanks!
**Trac**:
**Username**: mig5Tor: 0.3.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24754Remove unnecessary heap allocations in Rust protover implementation.2020-06-27T13:54:35ZTracRemove unnecessary heap allocations in Rust protover implementation.https://github.com/frewsxcv/tor/compare/frewsxcv-protover-heap?expand=1
This is my first Tor patch! 🎉
I was working towards https://trac.torproject.org/projects/tor/ticket/24030 and noticed we do some unnecessary heap allocations via `...https://github.com/frewsxcv/tor/compare/frewsxcv-protover-heap?expand=1
This is my first Tor patch! 🎉
I was working towards https://trac.torproject.org/projects/tor/ticket/24030 and noticed we do some unnecessary heap allocations via `collect`.
Even though this is a small change I'm mostly opening to see what the review/merge process is like. Also curious if small patches like this should be folded into larger patches as separate commits, or if it's okay to open individual tickets for them. If there's anything I'm doing wrong, let me know – I've done virtually no open source work outside of GitHub and am new to this Trac-based workflow.
**Trac**:
**Username**: frewsxcvTor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24748First IP address in my Tor Circuit is always STATIC2020-06-27T13:54:35ZTracFirst IP address in my Tor Circuit is always STATICFirst IP address in my Tor Circuit is always set to: 185.180.231.76 Russia. I am a victim of #MeToo at a very powerful institution. After reporting sexual harassment, sexual assault, and other illegal issues, the institution made up m...First IP address in my Tor Circuit is always set to: 185.180.231.76 Russia. I am a victim of #MeToo at a very powerful institution. After reporting sexual harassment, sexual assault, and other illegal issues, the institution made up many lies about me and called in favors from all of their powerful cronies. I am still being harassed. They have managed to get these powerful cronies to track all of my email, electronic communications, phone, snail mail, etc. I am notifying the TOR Project of this because I believe that making my first IP Address static in my circuit is at their request. I have never done anything wrong in my whole life. I am a victim. I am notifying you of this and requesting that you stop cooperating with all who ask you to harass me. I am an innocent victim #MeToo. Please stop revictimizing me. You have a legal choice. What they are asking of you is based on lies - absolutely no truth; therefore, their request is illegal.
**Trac**:
**Username**: toruser123https://gitlab.torproject.org/tpo/core/tor/-/issues/24745Run fuzzing with floating point exceptions turned on2022-09-01T21:31:34ZteorRun fuzzing with floating point exceptions turned onWe should turn on the invalid operation, division by zero, and overflow floating point exceptions when we're fuzzing, to detect more bugs:
https://randomascii.wordpress.com/2012/04/21/exceptional-floating-point/
(Although Tor doesn't u...We should turn on the invalid operation, division by zero, and overflow floating point exceptions when we're fuzzing, to detect more bugs:
https://randomascii.wordpress.com/2012/04/21/exceptional-floating-point/
(Although Tor doesn't use very much floating point, so we might not find anything.)https://gitlab.torproject.org/tpo/core/tor/-/issues/24741Consider redacting usernames in notice level logs2022-06-17T13:33:01ZteorConsider redacting usernames in notice level logsmacOS uses a person's first and last name as their username by default.
(I'm not sure what Windows or other unix systems do.)
This means that logs can contain a user's full name, and sometimes (at info level?) their IP address.
We shou...macOS uses a person's first and last name as their username by default.
(I'm not sure what Windows or other unix systems do.)
This means that logs can contain a user's full name, and sometimes (at info level?) their IP address.
We should think about the risks here, particularly for users that post logs to the bug tracker.https://gitlab.torproject.org/tpo/core/tor/-/issues/24740Tor launches two requests for authority certificates on first bootstrap2020-06-27T13:54:35ZteorTor launches two requests for authority certificates on first bootstrapWhen tor first bootstraps, it launches two requests for authority certificates:
* one is the hinted request that goes to the directory it downloaded the consensus from (ticket?)
* one is a scheduled request that goes to a random director...When tor first bootstraps, it launches two requests for authority certificates:
* one is the hinted request that goes to the directory it downloaded the consensus from (ticket?)
* one is a scheduled request that goes to a random directory
We should delay the first scheduled request slightly (5s?) to allow the first request to complete.
This might be as easy as changing the first number in the authority certificate schedule from 0 to 5.
I thought we avoided fetching certificates if another fetch was in progress: clearly that doesn't happen, and maybe we don't want it to, because we don't want to wait a whole 10 seconds for it to timeout.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24738Abort trap: 6 after installation Mac OS 10.13.12020-07-28T16:23:00ZTracAbort trap: 6 after installation Mac OS 10.13.1I want to install Tor from source for Mac OS 10.13.1.
I downloaded tor-0.3.19 from your site. (I also tried these steps with tor-0.3.2.8-rc, tor-0.2.8.17, tor-0.2.5.14, tor-0.2.9.13, loaded from here https://dist.torproject.org/)
I did:
...I want to install Tor from source for Mac OS 10.13.1.
I downloaded tor-0.3.19 from your site. (I also tried these steps with tor-0.3.2.8-rc, tor-0.2.8.17, tor-0.2.5.14, tor-0.2.9.13, loaded from here https://dist.torproject.org/)
I did:
1) ./configure && make
2) make install
No errors appeared.
After that I tried to execute tor by typing **tor** in terminal.
I got:
{{{
Dec 24 21:20:54.192 [notice] Tor 0.3.1.9 (git-727d3f1b5e6eeda7) running on Darwin with Libevent 2.0.22-stable, OpenSSL LibreSSL 2.2.7, Zlib 1.2.11, Liblzma 5.2.3, and Libzstd N/A.
Dec 24 21:20:54.192 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Dec 24 21:20:54.193 [notice] Read configuration file "/usr/local/etc/tor/torrc".
Dec 24 21:20:54.198 [warn] Warning from libevent: kq_init: detected broken kqueue; not using.: Invalid argument
Dec 24 21:20:54.199 [notice] Opening Socks listener on 127.0.0.1:9050
Dec 24 21:20:54.000 [notice] Parsing GEOIP IPv4 file /usr/local/share/tor/geoip.
Dec 24 21:20:54.000 [notice] Parsing GEOIP IPv6 file /usr/local/share/tor/geoip6.
Dec 24 21:20:54.000 [notice] We were built to run on a 64-bit CPU, with OpenSSL 1.0.1 or later, but with a version of OpenSSL that apparently lacks accelerated support for the NIST P-224 and P-256 groups. Building openssl with such support (using the enable-ec_nistp_64_gcc_128 option when configuring it) would make ECDH much faster.
============================================================ T= 1514139655
Tor 0.3.1.9 (git-727d3f1b5e6eeda7) died: Caught signal 11
0 tor 0x0000000109d30c8e crash_handler + 46
1 libsystem_platform.dylib 0x00007fff511cff5a _sigtramp + 26
2 libssl.35.dylib 0x00007fff50a9e732 SSL_CTX_new + 242
3 tor 0x0000000109d5a874 tor_tls_context_init_one + 228
4 tor 0x0000000109d5a65b tor_tls_context_init + 283
5 tor 0x0000000109d04edc init_keys_client + 108
6 tor 0x0000000109d05028 init_keys + 72
7 tor 0x0000000109cbebe0 do_main_loop + 560
8 tor 0x0000000109cc142c tor_main + 172
9 tor 0x0000000109c108eb main + 27
10 libdyld.dylib 0x00007fff50f4f145 start + 1
11 ??? 0x0000000000000001 0x0 + 1
Abort trap: 6}}}
What did I do wrong ?
What is this strange error ?
How can I avoid it ?
Please, help me, I very need Tor working.
**Trac**:
**Username**: lL__Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24737Recommend a MaxMemInQueues value in the Tor man page2022-06-24T14:43:24ZstarlightRecommend a MaxMemInQueues value in the Tor man pagedue to recent DOS attacks much incorrect advice has been tossed around on tor-relays regarding the application of `MaxMemInQueues`
many seem to believe that MaxMemInQueues should be set to 75-80% of available memory but this is painfull...due to recent DOS attacks much incorrect advice has been tossed around on tor-relays regarding the application of `MaxMemInQueues`
many seem to believe that MaxMemInQueues should be set to 75-80% of available memory but this is painfully (in the sense of OOM crashes) incorrect
proper advice is to set MaxMemInQueues to 45% of physical memory available for the instance, assuming DisableAllSwap=1 is also in effect; 40% is a safer, more conservative value
one of my relays configured with MaxMemInQueues=1024MB recently emitted
```
We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.)
Removed 1063029792 bytes by killing 1 circuits; 21806 circuits remain alive. Also killed 0 non-linked directory connections.
```
after which the tor daemon was observed to consume precisely 2GB per /proc/<tor-pid>/status:VmRSS
the aforementioned incorrect advice was followed in legacy/trac#22255 and the operator continues to experience OOM failures
another mitigation is to establish conservative linux memory management with the sysctl settings
vm.overcommit_memory = 2
vm.overcommit_ratio = X
where X is set such that /proc/memifo:CommitLimit is approximately 80% of physical memory (90% if 16GB or more is present)
The settings will prevent sparse-memory applications from running (e.g. ASAN instrumented code), but is appropriate for dedicated tor relays systems. Effectively disables OOM killer and should result in graceful memory exhaustion behavior, though I have not investigated tor daemon response in the face of malloc() fails returning null pointers.https://gitlab.torproject.org/tpo/core/tor/-/issues/24736Clear the address when fascist_firewall_choose_address_base() can't find an a...2021-08-23T15:17:07ZteorClear the address when fascist_firewall_choose_address_base() can't find an addressWe should do this as a precaution, so we're not re-using an uninitialised address.
This is similar to legacy/trac#23874.We should do this as a precaution, so we're not re-using an uninitialised address.
This is similar to legacy/trac#23874.Tor: 0.2.9.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24735Always check for the null address when calling address functions2020-07-28T16:11:11ZteorAlways check for the null address when calling address functionsThese address functions have never had return values:
* node_get_prim_dirport()
* node_get_pref_ipv6_orport()
We should make sure we always check for the null address when we call them.These address functions have never had return values:
* node_get_prim_dirport()
* node_get_pref_ipv6_orport()
We should make sure we always check for the null address when we call them.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24734Remove the return value of fascist_firewall_choose_address_node()2020-06-27T13:54:36ZteorRemove the return value of fascist_firewall_choose_address_node()Let's check for the null address instead.Let's check for the null address instead.Tor: 0.3.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/24733Loading ifc.ifc_buf using the new tor_free() causes undefined behaviour on x8...2020-06-27T13:54:36ZteorLoading ifc.ifc_buf using the new tor_free() causes undefined behaviour on x86_64 macOSOn macOS x86+64, the new tor_free() from legacy/trac#24337 loads ifc.ifc_buf, which leads to undefined behaviour. ifc.ifc_buf is a `char *` which should be aligned to a multiple 8 bytes, but it is always aligned at 8-bytes (ifc on the st...On macOS x86+64, the new tor_free() from legacy/trac#24337 loads ifc.ifc_buf, which leads to undefined behaviour. ifc.ifc_buf is a `char *` which should be aligned to a multiple 8 bytes, but it is always aligned at 8-bytes (ifc on the stack) plus 4 bytes (ifc_len and pragma pack(4)).
This bug was caused by legacy/trac#24337, which has been merged to master (0.3.3.0-alpha-dev), and Apple's 32/64 bit kernel data structure compatibility code.
It was discovered using our unit tests and clang's address sanitizer.Tor: 0.3.3.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24732Remove unused IPv6 DirPort code2021-09-16T14:31:18ZteorRemove unused IPv6 DirPort codeIPv6 DirPorts aren't used by Tor: clients use IPv4/IPv6 ORPorts, and relays use IPv4 DirPorts (and IPv4 ORPorts).
There is code that implements this algorithm in commit 36ba50c820 of my bug23975_tree branch.IPv6 DirPorts aren't used by Tor: clients use IPv4/IPv6 ORPorts, and relays use IPv4 DirPorts (and IPv4 ORPorts).
There is code that implements this algorithm in commit 36ba50c820 of my bug23975_tree branch.