Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2021-11-22T22:51:04Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40300Tor 0.4.5.6 is outputting lots of messages like: Unable to find IPv4 address ...2021-11-22T22:51:04ZerTor 0.4.5.6 is outputting lots of messages like: Unable to find IPv4 address for ORPort 9001Havent seen that one before upgrading to 0.4.5.6
```
$ /home/debian-tor/tor-0.4.5.6/src/app/tor -f /etc/tor/torrc
Feb 16 18:43:19.180 [notice] Tor 0.4.5.6 running on Linux with Libevent 2.0.21-stable, OpenSSL 1.1.0l, Zlib 1.2.8, Liblzm...Havent seen that one before upgrading to 0.4.5.6
```
$ /home/debian-tor/tor-0.4.5.6/src/app/tor -f /etc/tor/torrc
Feb 16 18:43:19.180 [notice] Tor 0.4.5.6 running on Linux with Libevent 2.0.21-stable, OpenSSL 1.1.0l, Zlib 1.2.8, Liblzma 5.2.2, Libzstd 1.1.2 and Glibc 2.24 as libc.
Feb 16 18:43:19.215 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Feb 16 18:43:19.339 [notice] Read configuration file "/etc/tor/torrc".
Feb 16 18:43:19.455 [warn] Skipping obsolete configuration option "AllowSingleHopExits".
Feb 16 18:43:19.459 [warn] Skipping obsolete configuration option "AllowSingleHopCircuits".
Feb 16 18:43:19.491 [warn] You specified a public address '0.0.0.0:5353' for DNSPort. Other people on the Internet might find your computer and use it as an open proxy. Please don't allow this unless you have a good reason.
Feb 16 18:43:19.495 [warn] Configuration port ORPort 9001 superseded by ORPort [<MY IPV6 ADDRESS>]:9001
Feb 16 18:43:19.514 [notice] Based on detected system memory, MaxMemInQueues is set to 324 MB. You can override this by setting MaxMemInQueues by hand.
Feb 16 18:43:19.524 [warn] Tor is currently configured as a relay and a hidden service. That's not very secure: you should probably run your hidden service in a separate Tor process, at least -- see https://bugs.torproject.org/tpo/core/tor/8742.
Feb 16 18:43:19.650 [warn] You specified a public address '0.0.0.0:9050' for SocksPort. Other people on the Internet might find your computer and use it as an open proxy. Please don't allow this unless you have a good reason.
Feb 16 18:43:19.655 [warn] You specified a public address '0.0.0.0:5353' for DNSPort. Other people on the Internet might find your computer and use it as an open proxy. Please don't allow this unless you have a good reason.
Feb 16 18:43:19.658 [warn] Configuration port ORPort 9001 superseded by ORPort [<MY IPV6 ADDRESS>]:9001
Feb 16 18:43:19.660 [notice] Opening Socks listener on 0.0.0.0:9050
Feb 16 18:43:19.663 [notice] Opened Socks listener connection (ready) on 0.0.0.0:9050
Feb 16 18:43:19.665 [notice] Opening DNS listener on 0.0.0.0:5353
Feb 16 18:43:19.683 [notice] Opened DNS listener connection (ready) on 0.0.0.0:5353
Feb 16 18:43:19.683 [notice] Opening Control listener on 127.0.0.1:9051
Feb 16 18:43:19.687 [notice] Opened Control listener connection (ready) on 127.0.0.1:9051
Feb 16 18:43:19.687 [notice] Opening OR listener on 0.0.0.0:9001
Feb 16 18:43:19.687 [notice] Opened OR listener connection (ready) on 0.0.0.0:9001
Feb 16 18:43:19.687 [notice] Opening OR listener on [<MY IPV6 ADDRESS>]:9001
Feb 16 18:43:19.687 [notice] Opened OR listener connection (ready) on [<MY IPV6 ADDRESS>]:9001
Feb 16 18:45:49.000 [notice] Bootstrapped 0% (starting): Starting
Feb 16 18:51:59.000 [notice] Starting with guard context "default"
Feb 16 18:52:02.000 [notice] Bootstrapped 5% (conn): Connecting to a relay
Feb 16 18:52:03.000 [notice] Unable to find IPv4 address for ORPort 9001. You might want to specify IPv4Only to it or set an explicit address or set Address.
Feb 16 18:52:04.000 [notice] Bootstrapped 10% (conn_done): Connected to a relay
Feb 16 18:52:06.000 [notice] Bootstrapped 14% (handshake): Handshaking with a relay
Feb 16 18:52:07.000 [notice] Bootstrapped 15% (handshake_done): Handshake with a relay done
Feb 16 18:52:07.000 [notice] Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits
Feb 16 18:52:07.000 [notice] Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits
Feb 16 18:52:07.000 [notice] Bootstrapped 95% (circuit_create): Establishing a Tor circuit
Feb 16 18:52:09.000 [notice] External address seen and suggested by a directory authority: <MY IPV4 ADDRESS>
Feb 16 18:52:51.000 [notice] Our directory information is no longer up-to-date enough to build circuits: We're missing descriptors for 1/2 of our primary entry guards (total microdescriptors: 6731/6774). That's ok. We will try to fetch missing descriptors soon.
Feb 16 18:52:51.000 [notice] I learned some more directory information, but not enough to build a circuit: We're missing descriptors for 1/2 of our primary entry guards (total microdescriptors: 6731/6774). That's ok. We will try to fetch missing descriptors soon.
Feb 16 18:52:54.000 [notice] External address seen and suggested by a directory authority: <MY IPV6 ADDRESS>
Feb 16 18:52:54.000 [notice] Bootstrapped 100% (done): Done
Feb 16 18:53:59.000 [notice] Now checking whether IPv4 ORPort <MY IPV4 ADDRESS>:9001 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Feb 16 18:54:00.000 [notice] Now checking whether IPv6 ORPort [<MY IPV6 ADDRESS>]:9001 is reachable... (this may take up to 20 minutes -- look for log messages indicating success
Feb 16 18:56:35.000 [notice] Self-testing indicates your ORPort [<MY IPV6 ADDRESS>]:9001 is reachable from the outside. Excellent.
Feb 16 18:57:07.000 [notice] Self-testing indicates your ORPort <MY IPV4 ADDRESS>:9001 is reachable from the outside. Excellent. Publishing server descriptor.
Feb 16 18:57:11.000 [notice] Performing bandwidth self-test...done.
...
Feb 16 19:52:21.000 [notice] Unable to find IPv4 address for ORPort 9001. You might want to specify IPv4Only to it or set an explicit address or set Address. [59 similar message(s) suppressed in last 3540 seconds]
...
```Tor: 0.4.5.7-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40301relay: Reduce compression level when streaming2021-08-11T13:13:11ZDavid Gouletdgoulet@torproject.orgrelay: Reduce compression level when streamingTurns out that most of the time, relays will stream back directory content on the highest compression level which means a lot of CPU for the best compression ratio.
However, in the case of authorities, when under DDoS from clients fetch...Turns out that most of the time, relays will stream back directory content on the highest compression level which means a lot of CPU for the best compression ratio.
However, in the case of authorities, when under DDoS from clients fetching non stop directory documents, it leads to a gigantic amount of CPU time being used on compressing requests that can not be pre-compresssed.
We propose to reduce the compression level, in case of streaming, to the lowest level. Considering that authorities, using Zstd, will see a significant reduction in CPU time but also will still gain on using the highest compression level that Zlib offers.
See https://docs.google.com/spreadsheets/d/1devQlUOzMPStqUl9mPawFWP99xSsRM8xWv7DNcqjFdo/edit#gid=0
Pre-compressed data will still use the current values, only streaming data will be downgraded to lowest ratio.Tor: 0.4.5.7-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40334hs_metrics_service_init: Non-fatal assertion when Tor reloads2021-03-10T20:28:23Zn-thumannhs_metrics_service_init: Non-fatal assertion when Tor reloads### Summary
I noticed that every night when my logs get rotated, a non-fatal assertion appears at the beginning the log.
I can manually trigger this issue but reloading Tor by hand (`sudo systemctl reload tor`).
### What is the current ...### Summary
I noticed that every night when my logs get rotated, a non-fatal assertion appears at the beginning the log.
I can manually trigger this issue but reloading Tor by hand (`sudo systemctl reload tor`).
### What is the current bug behavior?
This bug message just appears, but I could not find any impact yet.
### What is the expected behavior?
This message shouldn't appear, right?
### Environment
- Tor version 0.4.5.6 (`0.4.5.6-1~d10.buster+1`)
- Debian 10
- Installed using apt (via the official Tor repository)
- This Tor instance is a bridge relay
- This Tor instance exposes a v3 HS (Bitcoin Core 0.21.0)
### Relevant logs and/or screenshots
```
Mar 05 00:00:16.000 [notice] Tor 0.4.5.6 opening new log file.
Mar 05 00:00:16.000 [warn] tor_bug_occurred_(): Bug: ../src/feature/hs/hs_metrics.c:154: hs_metrics_service_init: Non-fatal assertion !(service->metrics.store) failed. (on Tor 0.4.5.6 )
Mar 05 00:00:16.000 [warn] Bug: Tor 0.4.5.6: Non-fatal assertion !(service->metrics.store) failed in hs_metrics_service_init at ../src/feature/hs/hs_metrics.c:154. Stack trace: (on Tor 0.4.5.6 )
Mar 05 00:00:17.000 [warn] Bug: /usr/bin/tor(log_backtrace_impl+0x56) [0x56393b37be56] (on Tor 0.4.5.6 )
Mar 05 00:00:17.000 [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0x16c) [0x56393b386fcc] (on Tor 0.4.5.6 )
Mar 05 00:00:17.000 [warn] Bug: /usr/bin/tor(+0x20302b) [0x56393b48f02b] (on Tor 0.4.5.6 )
Mar 05 00:00:17.000 [warn] Bug: /usr/bin/tor(hs_service_load_all_keys+0xd8b) [0x56393b49166b] (on Tor 0.4.5.6 )
Mar 05 00:00:17.000 [warn] Bug: /usr/bin/tor(set_options+0xd36) [0x56393b4103e6] (on Tor 0.4.5.6 )
Mar 05 00:00:17.000 [warn] Bug: /usr/bin/tor(+0x184f2f) [0x56393b410f2f] (on Tor 0.4.5.6 )
Mar 05 00:00:17.000 [warn] Bug: /usr/bin/tor(options_init_from_string+0x14d) [0x56393b4111bd] (on Tor 0.4.5.6 )
Mar 05 00:00:17.000 [warn] Bug: /usr/bin/tor(options_init_from_torrc+0x376) [0x56393b4117e6] (on Tor 0.4.5.6 )
Mar 05 00:00:17.000 [warn] Bug: /usr/bin/tor(+0x649b9) [0x56393b2f09b9] (on Tor 0.4.5.6 )
Mar 05 00:00:17.000 [warn] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x22a6c) [0x7f31454eda6c] (on Tor 0.4.5.6 )
Mar 05 00:00:17.000 [warn] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(event_base_loop+0x5a7) [0x7f31454ee537] (on Tor 0.4.5.6 )
Mar 05 00:00:17.000 [warn] Bug: /usr/bin/tor(do_main_loop+0xff) [0x56393b2f809f] (on Tor 0.4.5.6 )
Mar 05 00:00:17.000 [warn] Bug: /usr/bin/tor(tor_run_main+0x885) [0x56393b2f23f5] (on Tor 0.4.5.6 )
Mar 05 00:00:17.000 [warn] Bug: /usr/bin/tor(tor_main+0x3a) [0x56393b2f02ea] (on Tor 0.4.5.6 )
Mar 05 00:00:17.000 [warn] Bug: /usr/bin/tor(main+0x19) [0x56393b2efea9] (on Tor 0.4.5.6 )
Mar 05 00:00:17.000 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7f3144dc1bbb] (on Tor 0.4.5.6 )
Mar 05 00:00:17.000 [warn] Bug: /usr/bin/tor(_start+0x2a) [0x56393b2efefa] (on Tor 0.4.5.6 )
```
Let me know, if I can help you with any more information :v:Tor: 0.4.5.7-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40309Deprecated mallinfo() warning when building2021-03-01T13:37:18ZDavid Gouletdgoulet@torproject.orgDeprecated mallinfo() warning when buildingI'm using libc 2.33 and this is now showing up when building tor:
```
src/lib/meminfo/meminfo.c: In function ‘tor_log_mallinfo’:
src/lib/meminfo/meminfo.c:49:3: warning: ‘mallinfo’ is deprecated [-Wdeprecated-declarations]
49 | mi ...I'm using libc 2.33 and this is now showing up when building tor:
```
src/lib/meminfo/meminfo.c: In function ‘tor_log_mallinfo’:
src/lib/meminfo/meminfo.c:49:3: warning: ‘mallinfo’ is deprecated [-Wdeprecated-declarations]
49 | mi = mallinfo();
| ^~
In file included from src/lib/meminfo/meminfo.c:25:
/usr/include/malloc.h:118:24: note: declared here
118 | extern struct mallinfo mallinfo (void) __THROW __MALLOC_DEPRECATED;
| ^~~~~~~~
```
... which is a bit annoying when building with `enable-gcc-warnings` that makes it fatal.
Likely reality that we might want to backport this to all supported versions if we want to be able to build them with libc >= 2.33.Tor: 0.4.5.7-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40287Dir auths should stop testing reachability of their DirPort2021-02-22T19:13:53ZRoger DingledineDir auths should stop testing reachability of their DirPortThis is the tiny piece of #40282 that needs to be done soon: we've put patches in place so that relays won't allow exiting to the listed dir auth dirports, yet the dir auths use exactly this technique to test their reachability, and they...This is the tiny piece of #40282 that needs to be done soon: we've put patches in place so that relays won't allow exiting to the listed dir auth dirports, yet the dir auths use exactly this technique to test their reachability, and they currently don't publish their descriptor if they can't find their dirport reachable.
This surprise happened in practice during the "dirport ddos via exits" event, where moria1 kept complaining that its dirport wasn't reachable, and I assume that meant it wasn't ever planning to publish a new descriptor, which meant it would eventually fall out of the consensus (which isn't the end of the world either, since it doesn't need to be in the consensus for most of its functions).
If we were doing #40282 in 0.4.5 and doing the "leave the dirport listed but just stop testing it" version of that ticket, we could just do that and it would accomplish this ticket too. But my guess is that we want to do that ticket for 0.4.6, in which case we need to do some minimal thing in 0.4.5 before we get there?Tor: 0.4.5.7-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.org