The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-07-28T16:11:11Zhttps://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.https://gitlab.torproject.org/tpo/core/tor/-/issues/24731Stop checking routerinfos for addresses when we use microdescs for circuits2022-09-01T21:31:34ZteorStop checking routerinfos for addresses when we use microdescs for circuitsDirectory mirrors and clients that FetchUselessDescriptors check for IPv4 and IPv6 addresses in the following order:
* routerinfos (descriptors)
* routerstatus (consensus)
* microdescriptors
But they should check using the following ord...Directory mirrors and clients that FetchUselessDescriptors check for IPv4 and IPv6 addresses in the following order:
* routerinfos (descriptors)
* routerstatus (consensus)
* microdescriptors
But they should check using the following order:
* bridge routerinfos (descriptors)
* routerstatus (consensus)
If using microdescriptors for circuits:
* microdescriptors
Otherwise:
* routerinfos (descriptors)
There is code that implements this algorithm in commits decb0636e2, 1d1c927b9a, and 4979ec3c17 of my bug23975_tree branch.
But this adds overhead to every address lookup when building circuits.
Maybe we can make it faster by:
* not parsing routerinfos or microdescs if we aren't using them for circuits, or
* putting a canonical address in node_t, updating it whenever ri, rs, or md change, and always using ithttps://gitlab.torproject.org/tpo/core/tor/-/issues/24724SIGNAL NEWNYM does'nt change exitnode2020-06-27T13:54:36ZTracSIGNAL NEWNYM does'nt change exitnodeTor browser bundle v7.0.11
getinfo version
250-version=0.3.1.9 (git-727d3f1b5e6eeda7)
250 OK
SIGNAL NEWNYM
250 OK
getinfo circuit-status
250+circuit-status=
17 BUILT $11EAB5C9137906EF7E6A32365C4B37613698E647~radia3,$DF3EEDE3CEBA425940...Tor browser bundle v7.0.11
getinfo version
250-version=0.3.1.9 (git-727d3f1b5e6eeda7)
250 OK
SIGNAL NEWNYM
250 OK
getinfo circuit-status
250+circuit-status=
17 BUILT $11EAB5C9137906EF7E6A32365C4B37613698E647~radia3,$DF3EEDE3CEBA425940F82E4C2268F4E4015C3010~TORminion,$4273E6D162ED2717A1CF4207A254004CD3F5307B~AccessNow000 BUILD_FLAGS=NEED_CAPACITY,NEED_UPTIME PURPOSE=GENERAL TIME_CREATED=2017-12-23T21:32:52.264187 SOCKS_USERNAME="icanhazip.com" SOCKS_PASSWORD="42b6261600aea1360c4129e7f008b100"
19 BUILT $2F8E20F67D42560022744DF255ADD4F7F154D435~vortor03,$484A10BA2B8D48A5F0216674C8DD50EF27BC32F3~Aerodynamik03,$1AF72E8906E6C49481A791A6F8F84F8DFEBBB2BA~zwiebeltoralf BUILD_FLAGS=NEED_CAPACITY,NEED_UPTIME PURPOSE=GENERAL TIME_CREATED=2017-12-23T21:36:17.264530
20 BUILT $11EAB5C9137906EF7E6A32365C4B37613698E647~radia3,$9285B22F7953D7874604EEE2B470609AD81C74E9~0x3d005,$CEACA34874EAD103D27CA6A7650B16112F12B209~tor4thepeople3 BUILD_FLAGS=NEED_CAPACITY,NEED_UPTIME PURPOSE=GENERAL TIME_CREATED=2017-12-23T21:36:18.264137
21 BUILT $3E54415221B30DCBE27F2F3F6BB69821F3F8D789~orminet,$9AE8EE088FF05B59246E9B31A48B59AD79861D32~seedelmann,$9AA3FF35E7A549D2337E962333D366E102FE4D50~DigiGesTor3e1 BUILD_FLAGS=NEED_CAPACITY,NEED_UPTIME PURPOSE=GENERAL TIME_CREATED=2017-12-23T21:42:14.263937
.
250 OK
SIGNAL NEWNYM
250 OK
getinfo circuit-status
250+circuit-status=
17 BUILT $11EAB5C9137906EF7E6A32365C4B37613698E647~radia3,$DF3EEDE3CEBA425940F82E4C2268F4E4015C3010~TORminion,$4273E6D162ED2717A1CF4207A254004CD3F5307B~AccessNow000 BUILD_FLAGS=NEED_CAPACITY,NEED_UPTIME PURPOSE=GENERAL TIME_CREATED=2017-12-23T21:32:52.264187 SOCKS_USERNAME="icanhazip.com" SOCKS_PASSWORD="42b6261600aea1360c4129e7f008b100"
19 BUILT $2F8E20F67D42560022744DF255ADD4F7F154D435~vortor03,$484A10BA2B8D48A5F0216674C8DD50EF27BC32F3~Aerodynamik03,$1AF72E8906E6C49481A791A6F8F84F8DFEBBB2BA~zwiebeltoralf BUILD_FLAGS=NEED_CAPACITY,NEED_UPTIME PURPOSE=GENERAL TIME_CREATED=2017-12-23T21:36:17.264530
20 BUILT $11EAB5C9137906EF7E6A32365C4B37613698E647~radia3,$9285B22F7953D7874604EEE2B470609AD81C74E9~0x3d005,$CEACA34874EAD103D27CA6A7650B16112F12B209~tor4thepeople3 BUILD_FLAGS=NEED_CAPACITY,NEED_UPTIME PURPOSE=GENERAL TIME_CREATED=2017-12-23T21:36:18.264137
21 BUILT $3E54415221B30DCBE27F2F3F6BB69821F3F8D789~orminet,$9AE8EE088FF05B59246E9B31A48B59AD79861D32~seedelmann,$9AA3FF35E7A549D2337E962333D366E102FE4D50~DigiGesTor3e1 BUILD_FLAGS=NEED_CAPACITY,NEED_UPTIME PURPOSE=GENERAL TIME_CREATED=2017-12-23T21:42:14.263937
**Trac**:
**Username**: dimzon541https://gitlab.torproject.org/tpo/core/tor/-/issues/24715Job for tor.service failed when /var/run is tmpfs2020-06-27T13:54:37ZTracJob for tor.service failed when /var/run is tmpfsISSUE SUMMARY
=============
For this test I'm running Tor 0.3.2.6-alpha (git-87012d076ef58bb9) on Gentoo Linux. On my system, the /var/run/tor directory does not exist, and /var/run is a link to /run which is mounted as tmpfs:
tmpf...ISSUE SUMMARY
=============
For this test I'm running Tor 0.3.2.6-alpha (git-87012d076ef58bb9) on Gentoo Linux. On my system, the /var/run/tor directory does not exist, and /var/run is a link to /run which is mounted as tmpfs:
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
Attempting to start tor using tor.service fails:
vilhelm@sophia ~ $ sudo systemctl restart tor
Job for tor.service failed because the control process exited with error code.
See "systemctl status tor.service" and "journalctl -xe" for details.
vilhelm@sophia ~ $ sudo systemctl status tor.service
● tor.service - Anonymizing overlay network for TCP
Loaded: loaded (/lib/systemd/system/tor.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Wed 2017-12-06 09:08:19 EST; 4s ago
Process: 12244 ExecStart=/usr/bin/tor -f /etc/tor/torrc (code=exited, status=1/FAILURE)
Process: 12243 ExecStartPre=/usr/bin/tor -f /etc/tor/torrc --verify-config (code=exited, status=0/SUCCESS)
Main PID: 12244 (code=exited, status=1/FAILURE)
Dec 06 09:08:19 sophia systemd[1]: tor.service: Service hold-off time over, scheduling restart.
Dec 06 09:08:19 sophia systemd[1]: tor.service: Scheduled restart job, restart counter is at 5.
Dec 06 09:08:19 sophia systemd[1]: Stopped Anonymizing overlay network for TCP.
Dec 06 09:08:19 sophia systemd[1]: tor.service: Start request repeated too quickly.
Dec 06 09:08:19 sophia systemd[1]: tor.service: Failed with result 'exit-code'.
Dec 06 09:08:19 sophia systemd[1]: Failed to start Anonymizing overlay network for TCP.
vilhelm@sophia ~ $ sudo journalctl -xe
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit tor.service has begun starting up.
Dec 06 09:08:18 sophia tor[12243]: Dec 06 09:08:18.595 [notice] Tor 0.3.2.6-alpha (git-87012d076ef58bb9) running on Linux with Libevent 2.1.8-stable, OpenSSL 1.0.2m, Zlib 1.2.11, Liblzma 5.2.3, and Libzstd N/A.
Dec 06 09:08:18 sophia tor[12243]: Dec 06 09:08:18.595 [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 06 09:08:18 sophia tor[12243]: Dec 06 09:08:18.595 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Dec 06 09:08:18 sophia tor[12243]: Dec 06 09:08:18.596 [notice] Read configuration file "/etc/tor/torrc".
Dec 06 09:08:18 sophia tor[12243]: Dec 06 09:08:18.597 [notice] Based on detected system memory, MaxMemInQueues is set to 8192 MB. You can override this by setting MaxMemInQueues by hand.
Dec 06 09:08:18 sophia tor[12243]: Configuration was valid
Dec 06 09:08:19 sophia tor[12244]: Dec 06 09:08:19.036 [notice] Tor 0.3.2.6-alpha (git-87012d076ef58bb9) running on Linux with Libevent 2.1.8-stable, OpenSSL 1.0.2m, Zlib 1.2.11, Liblzma 5.2.3, and Libzstd N/A.
Dec 06 09:08:19 sophia tor[12244]: Dec 06 09:08:19.036 [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 06 09:08:19 sophia tor[12244]: Dec 06 09:08:19.036 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Dec 06 09:08:19 sophia tor[12244]: Dec 06 09:08:19.036 [notice] Read configuration file "/etc/tor/torrc".
Dec 06 09:08:19 sophia tor[12244]: Dec 06 09:08:19.038 [notice] Based on detected system memory, MaxMemInQueues is set to 8192 MB. You can override this by setting MaxMemInQueues by hand.
Dec 06 09:08:19 sophia tor[12244]: Dec 06 09:08:19.038 [notice] Scheduler type KIST has been enabled.
Dec 06 09:08:19 sophia tor[12244]: Dec 06 09:08:19.038 [notice] Opening OR listener on 0.0.0.0:443
Dec 06 09:08:19 sophia tor[12244]: Dec 06 09:08:19.038 [notice] Opening Extended OR listener on 127.0.0.1:0
Dec 06 09:08:19 sophia tor[12244]: Dec 06 09:08:19.038 [notice] Extended OR listener listening on port 35193.
Dec 06 09:08:19 sophia Tor[12244]: Tor 0.3.2.6-alpha (git-87012d076ef58bb9) running on Linux with Libevent 2.1.8-stable, OpenSSL 1.0.2m, Zlib 1.2.11, Liblzma 5.2.3, and Libzstd N/A.
Dec 06 09:08:19 sophia Tor[12244]: Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Dec 06 09:08:19 sophia Tor[12244]: This version is not a stable Tor release. Expect more bugs than usual.
Dec 06 09:08:19 sophia Tor[12244]: Read configuration file "/etc/tor/torrc".
Dec 06 09:08:19 sophia Tor[12244]: Based on detected system memory, MaxMemInQueues is set to 8192 MB. You can override this by setting MaxMemInQueues by hand.
Dec 06 09:08:19 sophia Tor[12244]: Scheduler type KIST has been enabled.
Dec 06 09:08:19 sophia Tor[12244]: Opening OR listener on 0.0.0.0:443
Dec 06 09:08:19 sophia Tor[12244]: Opening Extended OR listener on 127.0.0.1:0
Dec 06 09:08:19 sophia Tor[12244]: Extended OR listener listening on port 35193.
Dec 06 09:08:19 sophia Tor[12244]: Unable to open "/var/run/tor/tor.pid" for writing: No such file or directory
Dec 06 09:08:19 sophia Tor[12244]: Unable to write PIDFile "/var/run/tor/tor.pid"
Dec 06 09:08:19 sophia Tor[12244]: set_options(): Bug: Acting on config options left us in a broken state. Dying. (on Tor 0.3.2.6-alpha 87012d076ef58bb9)
Dec 06 09:08:19 sophia systemd[1]: tor.service: Main process exited, code=exited, status=1/FAILURE
Dec 06 09:08:19 sophia systemd[1]: tor.service: Failed with result 'exit-code'.
Dec 06 09:08:19 sophia systemd[1]: Failed to start Anonymizing overlay network for TCP.
-- Subject: Unit tor.service has failed
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit tor.service has failed.
--
-- The result is RESULT.
Dec 06 09:08:19 sophia systemd[1]: tor.service: Service hold-off time over, scheduling restart.
Dec 06 09:08:19 sophia systemd[1]: tor.service: Scheduled restart job, restart counter is at 5.
Dec 06 09:08:19 sophia systemd[1]: Stopped Anonymizing overlay network for TCP.
-- Subject: Unit tor.service has finished shutting down
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit tor.service has finished shutting down.
Dec 06 09:08:19 sophia systemd[1]: tor.service: Start request repeated too quickly.
Dec 06 09:08:19 sophia systemd[1]: tor.service: Failed with result 'exit-code'.
Dec 06 09:08:19 sophia systemd[1]: Failed to start Anonymizing overlay network for TCP.
-- Subject: Unit tor.service has failed
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit tor.service has failed.
--
-- The result is RESULT.
SUSPECTED CAUSE
===============
The issue appears to result from the missing /var/run/tor directory and a lack of write permission to create the /var/run/tor/tor.pid PIDFile. I can manually create a /var/run/tor directory, but it will be gone if the system restarts since /var/run is tmpfs. The /var/run/tor directory and appropriate permissions should be configured in the tor.service file by default.
PROPOSED SOLUTION
=================
If I add the following lines to the /lib64/systemd/system/tor.service file the issue is resolved:
Group=tor
RuntimeDirectory=tor
RuntimeDirectoryMode=0770
I suggest adding these lines to the Tor source code contrib/dist/tor.service.in file so that the installed tor.service file will have the configuration lines to automatically create a /var/run/tor directory with the necessary permissions.
**Trac**:
**Username**: vilhelmgrayTor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24714rename conn->timestamp_lastwritten to conn->timestamp_lastwritable2021-09-16T14:31:18ZRoger Dingledinerename conn->timestamp_lastwritten to conn->timestamp_lastwritable"lastwritten" sure sounds like we actually flushed something or we actually added a new thing to write.
But actually,
```
time_t timestamp_lastwritten; /**< When was the last time libevent said we
* co..."lastwritten" sure sounds like we actually flushed something or we actually added a new thing to write.
But actually,
```
time_t timestamp_lastwritten; /**< When was the last time libevent said we
* could write? */
```
It seems that we changed our definition of this word somewhere along the line, but we left the old word in place. How confusing.
We might want to change lastread to lastreadable too.Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24712Client builds and timeouts tons of circs to connect to HS2020-07-28T16:12:37ZGeorge KadianakisClient builds and timeouts tons of circs to connect to HSI was testing legacy/trac#23101 by connecting to a few hidden services, and I noticed that my client would create about 7 intro circs and 7 rend circs before finally connecting to a single HS. Apparently it was creating circs and timing ...I was testing legacy/trac#23101 by connecting to a few hidden services, and I noticed that my client would create about 7 intro circs and 7 rend circs before finally connecting to a single HS. Apparently it was creating circs and timing them and then making more.
I'm not sure if this is caused by the current damaged state of the network, but it definitely is not making it better if a single client is causing so many circuits.
I'll be attaching logs in the next comment.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24703Document IPv6Exit in the sample torrcs2020-06-27T13:54:37ZteorDocument IPv6Exit in the sample torrcsWe could backport this to 0.3.2 if we want to get it in the next release.We could backport this to 0.3.2 if we want to get it in the next release.Tor: 0.3.2.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24700sched: With KIST, a channel can be added more than once in the pending list2020-06-27T13:54:37ZDavid Gouletdgoulet@torproject.orgsched: With KIST, a channel can be added more than once in the pending listHere is the flow for this to happen (and it has been observed):
The scheduler flushes 100 bytes onto the outbuf of a channel. Then the channel it put in the re-add list (which is to add back the channel in the pending list at the _end_ ...Here is the flow for this to happen (and it has been observed):
The scheduler flushes 100 bytes onto the outbuf of a channel. Then the channel it put in the re-add list (which is to add back the channel in the pending list at the _end_ of the scheduler loop) because it can't write anymore. Its state is set to `waiting_to_write`.
We then handle the next channel in the main loop but before that we'll try to write to kernel the outbuf of the previous channel which is in the re-add list.
If the outbuf is fully drained, `scheduler_channel_wants_writes()` is called which will add the channel back in the pending list *IF* it is in the `waiting_to_write` state which it is because it was set to that state just before being added to the re-add list.
Scheduler loop ends and we end up with twice the channel in the pending list. This can go on for a while resulting in the same channel being added many more times.
There are two ways to fix that, one quick and one more logical.
1. The quick one is to let the state of the channel in PENDING mode (which is what Vanilla does) before adding it to the re-add list. That way, it won't get added back in the pending list by any callbacks.
2. Originally, the assumption was that KIST takes care of the write on the socket and only KIST. But the reality is different, KIST will trigger writes to the kernel but anything after that, any errors or retry is handled by libevent `write_event` (legacy/trac#24448, and legacy/trac#24449).
So, it doesn't make sense for KIST to reschedule the channel as pending if it is waiting to write on the socket because from that point on, it will be the job of libevent to actually flush it with its `poll(POLLOUT)` feature. Thus the fix is to never add back a channel that is waiting to write.
I personally would like to have (2) for two reasons. First, we would save CPU time and useless syscalls in this fast path. Second, adding a channel that is waiting to write back into the pending list is not really good in terms of priority. It should not get considered for another round in the loop, it should simply wait until the socket has been written since the assumption in (2) is false in the first place.Tor: 0.3.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/24694sched: Use the socket RTT in KIST to compute a more accurate extra space2022-09-01T21:31:34ZDavid Gouletdgoulet@torproject.orgsched: Use the socket RTT in KIST to compute a more accurate extra spaceThis comes from a discussion in legacy/trac#24665 that Yawning started:
Assuming the scheduler is called significantly faster than the RTT of most links (read that as "If 10 ms is lower than the RTT of most if not all links"), you can/s...This comes from a discussion in legacy/trac#24665 that Yawning started:
Assuming the scheduler is called significantly faster than the RTT of most links (read that as "If 10 ms is lower than the RTT of most if not all links"), you can/should reduce sock_buf_size_factor as well, because you aren't going to get a full congestion window worth of ACKs back between scheduler calls in common cases.
There isn't a good "one size fits all" solution. Setting it too low will gimp performance on fast low latency links, setting it too high right now bloats the various buffers. I would personally opt more toward avoiding the latter given all the Fun that's happening.
In the `struct tcp_info` we use in KIST, `tcpi_rtt` gives the smoothed RTT estimate (and `tcpi_rttvar` the RTT variance if you need it), which is probably sufficient to give a better reasonable guess here, as a first pass, I would recommend doing something based on the the scheduler interval to smoothed RTT ratio, with a hard maximum at 1.0.https://gitlab.torproject.org/tpo/core/tor/-/issues/24693Coverity CID 1426750 and CID 1426749: Calling two functions without control2020-06-27T13:54:37ZffmanceraCoverity CID 1426750 and CID 1426749: Calling two functions without controlWe left a memory leak in legacy/trac#23271; We call `get_controller_cookie_file_name()` and `get_ext_or_auth_cookie_file_name()` without control.We left a memory leak in legacy/trac#23271; We call `get_controller_cookie_file_name()` and `get_ext_or_auth_cookie_file_name()` without control.ffmanceraffmancerahttps://gitlab.torproject.org/tpo/core/tor/-/issues/24690Update to December GeoIP2 database2020-06-27T13:54:37ZKarsten LoesingUpdate to December GeoIP2 database[My geoip-2017-12-06 branch](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-2017-12-06) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.5 and all other re...[My geoip-2017-12-06 branch](https://gitweb.torproject.org/karsten/tor.git/log/?h=geoip-2017-12-06) contains the updated `geoip` and `geoip6` files with IPv4 and IPv6 ranges and is supposed to be merged into maint-0.2.5 and all other relevant branches.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24688timing wheels should use 32-bit math on 32-bit platforms2020-06-27T13:54:38ZNick Mathewsontiming wheels should use 32-bit math on 32-bit platformsI think this might help our 32-bit performance a bit.
Not putting this in needs_review yet, since it needs more analysis.
```
diff --git a/src/common/timers.c b/src/common/timers.c
index 93cde7de5fbd4b..3c806b7f4b422a 100644
--- a/src/...I think this might help our 32-bit performance a bit.
Not putting this in needs_review yet, since it needs more analysis.
```
diff --git a/src/common/timers.c b/src/common/timers.c
index 93cde7de5fbd4b..3c806b7f4b422a 100644
--- a/src/common/timers.c
+++ b/src/common/timers.c
@@ -66,6 +66,11 @@ struct timeout_cb {
* above TIMEOUT_MAX can also be super-inefficent. Choosing 5 here sets
* timeout_max to 2^30 ticks, or 29 hours with our value for USEC_PER_TICK */
#define WHEEL_NUM 5
+#if SIZEOF_VOID_P == 4
+/* On 32-bit platforms, we want to override wheel_bit, so that timeout.c will
+ * use 32-bit math. */
+#define WHEEL_BIT 5
+#endif
#include "src/ext/timeouts/timeout.c"
static struct timeouts *global_timeouts = NULL;
```Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24687Tor eats all mbufs on FreeBSD2020-06-27T13:54:38ZTracTor eats all mbufs on FreeBSDI'm running tor relay on FreeBSD 11.1, and not long ago the system started to occasionally stop responding to the network with
kernel: [zone: mbuf_cluster] kern.ipc.nmbclusters limit reached
accompanied with
kernel: sonewconn: pcb 0xf...I'm running tor relay on FreeBSD 11.1, and not long ago the system started to occasionally stop responding to the network with
kernel: [zone: mbuf_cluster] kern.ipc.nmbclusters limit reached
accompanied with
kernel: sonewconn: pcb 0xfffff80003c61570: Listen queue overflow: 193 already in queue awaiting acceptance (211 occurrences)
messages in the logs.
It first happened on Dec 13 and repeated 3 times, the approximate lifetime of the relay is ~1 day.
Seems like a DOS attack which makes tor open a lot of connections and eat all the mbuf space. I don't see any peaks on trafic or pps graphs though, and there are no messages in tor log.
I'm currently trying to gather more information.
**Trac**:
**Username**: AMDmi3Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24681Make the default fallback weight in Tor 10.02020-06-27T13:54:38ZteorMake the default fallback weight in Tor 10.0This is a follow-up to legacy/trac#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...This is a follow-up to legacy/trac#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/tpo/core/tor/-/issues/24677Use ping ::1 on Linux when ping6 ::1 fails2020-06-27T13:54:38ZteorUse ping ::1 on Linux when ping6 ::1 failsTurns out that some Linuxes don't have ping6, but ping ::1 works just fine.
This is a one-line change in Makefile.amTurns out that some Linuxes don't have ping6, but ping ::1 works just fine.
This is a one-line change in Makefile.amTor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24671sched: KISTLite should set an upper limit to write on the outbuf2022-10-11T23:40:02ZDavid Gouletdgoulet@torproject.orgsched: KISTLite should set an upper limit to write on the outbufRight now, for the `KISTLite` scheduler, the write limit on the outbuf for a channel is set to `INT_MAX`. This is crazy high and will bloat the outbuf if the channel is struggling to send out data on the wire or the socket is stuck.
Van...Right now, for the `KISTLite` scheduler, the write limit on the outbuf for a channel is set to `INT_MAX`. This is crazy high and will bloat the outbuf if the channel is struggling to send out data on the wire or the socket is stuck.
Vanilla scheduler uses the `num_cells_writeable()` method to limit the amount it puts on the outbuf which is 32KB maximum.
KIST uses the kernel information for this limit.
This is very important that we actually put a limit in the outbuf because it keeps the cells in the circuit queue and that is handled by our OOM in case of memory pressure.
I suggest we simply use the `channel_num_cells_writeable()` for the upper limit when KISTLite is used.Tor: 0.3.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/24668sched: scheduler_compare_channels() function will never pick a channel with n...2022-09-01T21:31:34ZDavid Gouletdgoulet@torproject.orgsched: scheduler_compare_channels() function will never pick a channel with no active circuits.In the schedulers, scheduler_compare_channels() is used to decide which channel is 'best' to write data from. It delegates to circuitmux_compare_muxes(), which delegates to ewma_cmp_cmux().
But ewma_cmp_cmux() will never prefer a cmux ...In the schedulers, scheduler_compare_channels() is used to decide which channel is 'best' to write data from. It delegates to circuitmux_compare_muxes(), which delegates to ewma_cmp_cmux().
But ewma_cmp_cmux() will never prefer a cmux with no active circuits on it! So a channel without active circuits will never be picked by the scheduler to flush from a circuit, which is what triggers flushing from its destroy queue. So the channel will stay around forever, never flushing.
To fix this one, we probably have to fix ewma_cmp_cmux() to look at destroy cells too (somehow). And we still need to make sure that the scheduler's position in the heap changes when the data considered by scheduler_compare_channels() changes [*].
[*] I'm not convinced that we're even doing this right with the current scheduler_compare_channels() code. :(