Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-07-21T12:04:11Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40025Prop 312: Make relay pick IPv4 or/and IPv6 resolved address in descriptor2020-07-21T12:04:11ZDavid Gouletdgoulet@torproject.orgProp 312: Make relay pick IPv4 or/and IPv6 resolved address in descriptorAt the moment, `router_pick_published_address()` is used to pick the address we'll put in a relay descriptor. It checks at the last resolved address, then attempts to locally find the address and finally attempts to look at what a direct...At the moment, `router_pick_published_address()` is used to pick the address we'll put in a relay descriptor. It checks at the last resolved address, then attempts to locally find the address and finally attempts to look at what a directory server suggested us.
With the work in tor#40022, we now discover our address with the `NETINFO` cell for both IPv4 and IPv6. We should use that.
Thus this ticket means that we need a new interface to query "what address should I use in my descriptor" so it is usable per address family and queries the right caches (that is not the directory guessed IP cache anymore).Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33236Prop 312: 3.2.2. Use Advertised ORPort IPv4 Address in Descriptors2020-07-07T15:02:30ZteorProp 312: 3.2.2. Use Advertised ORPort IPv4 Address in DescriptorsIf the Address option is not set for IPv4 or IPv6, relays (and bridges) should use the first advertised ORPort IPv4 and IPv6 addresses.
Note that relays already use the first advertised IPv6 ORPort address in their descriptors. So we ju...If the Address option is not set for IPv4 or IPv6, relays (and bridges) should use the first advertised ORPort IPv4 and IPv6 addresses.
Note that relays already use the first advertised IPv6 ORPort address in their descriptors. So we just need to preserve that behaviour.
The ORPort address may be a hostname. If it is, tor should try to use it to
resolve an IPv4 and IPv6 address, and open ORPorts on the first available
IPv4 and IPv6 address. Tor should respect the IPv4Only and IPv6Only port
flags, if specified. (Tor currently resolves IPv4 and IPv6 addresses from
hostnames in ORPort lines.)
Relays (and bridges) currently use the first advertised ORPort IPv6 address
as their IPv6 address. We propose to use the first advertised IPv4 ORPort
address in a similar way, for consistency.
Tor currently uses its listener port list to look up its IPv6 ORPort for
its descriptor. We propose that tor's address discovery uses the listener
port list for both IPv4 and IPv6. (And does not attempt to independently
parse or resolve ORPort configs.)
This design decouples ORPort option parsing, ORPort listener opening, and
address discovery. It also implements a form of caching: IPv4 and IPv6
addresses resolved from hostnames are stored in the listener port list,
then used to open listeners. Therefore, tor should continue to use the same
address, while the listener remains open. (See also sections 3.2.7 and
3.2.8.)
For the purposes of address resolution, tor should ignore private
configured ORPort addresses on public tor networks. (Binding to private
ORPort addresses is supported, even on public tor networks, for relays that use NAT to reach the Internet.)
See proposal 312, section 3.2.2, general case:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n306Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33245Prop 312: 3.2.6. Add an AddressDisableIPv6 torrc option2020-07-21T13:02:03ZteorProp 312: 3.2.6. Add an AddressDisableIPv6 torrc optionShould be done after the first IPv6 address guessing feature: legacy/trac#33238
or legacy/trac#33240.
Relays (and bridges) that have a reachable IPv6 address, but that address
is unsuitable for the relay, need to be able to disable IPv6...Should be done after the first IPv6 address guessing feature: legacy/trac#33238
or legacy/trac#33240.
Relays (and bridges) that have a reachable IPv6 address, but that address
is unsuitable for the relay, need to be able to disable IPv6 address
resolution.
Currently, relays are required to have an IPv4 address. So if the guessed
IPv4 address is unsuitable, operators can set the Address option to a
suitable IPv4 address. But IPv6 addresses are optional, so relay operators
may need to disable IPv6 entirely.
We propose a new torrc-only option, AddressDisableIPv6. This option is set
to 0 by default. If the option is set to 1, tor disables IPv6 address
resolution, IPv6 ORPorts, IPv6 reachability checks, and publishing an IPv6
ORPort in its descriptor.
See proposal 312, section 3.2.6:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n498Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40054prop 312: Don't publish IPv6 address if ORPort is IPv4Only2020-07-21T13:03:50ZDavid Gouletdgoulet@torproject.orgprop 312: Don't publish IPv6 address if ORPort is IPv4OnlyNow that tor#40025 is merged, I believe there is an issue for which we assume we'll find an ORPort if we have found an IPv6 address.
In `router_build_fresh_unsigned_routerinfo()`, we should check at the returned value of `router_get_adv...Now that tor#40025 is merged, I believe there is an issue for which we assume we'll find an ORPort if we have found an IPv6 address.
In `router_build_fresh_unsigned_routerinfo()`, we should check at the returned value of `router_get_advertised_or_port_by_af()` and not publish a port value of 0. It is possible for instance if the `ORPort` is `IPv4Only`.Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33246Prop 312: 3.2.7. Automatically Enable an IPv6 ORPort2020-07-22T13:56:19ZteorProp 312: 3.2.7. Automatically Enable an IPv6 ORPortAfter we implement legacy/trac#33233, relays (and bridges) should try to open an IPv6 ORPort.
The ORPort should be opened on the port configured in the relay's ORPort
torrc option. Relay operators can use the IPv4Only and IPv6Only optio...After we implement legacy/trac#33233, relays (and bridges) should try to open an IPv6 ORPort.
The ORPort should be opened on the port configured in the relay's ORPort
torrc option. Relay operators can use the IPv4Only and IPv6Only options
to configure different ports for IPv4 and IPv6.
If the ORPort is auto-detected, there will not be any specific bind
address. (And the detected address may actually be on a NAT box, rather
than the local machine.) Therefore, relays should attempt to bind to all
IPv4 and IPv6 addresses (or all interfaces).
Some operating systems expect applications to bind to IPv4 and IPv6
addresses using separate API calls. Others don't support binding only to
IPv4 or IPv6, and will bind to all addresses whenever there is no specified
IP address (in a single API call). Tor should support both styles of
networking API.
In particular, if binding to all IPv6 addresses fails, relays should still
try to discover their public IPv6 address, and check the reachability of
that address. Some OSes may not support the IPV6_V6ONLY flag, but they may
instead bind to all addresses at runtime. (The tor install may also have
compile-time / runtime flag mismatches.)
See proposal 312, section 3.2.7, IPv6 ORPort part:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n540
Once this ticket is implemented, we should test the different IPv4/IPv6 configs listed in legacy/trac#33235.Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40043relay: Stop using uint32_t addr for IPv4 and move to tor_addr_t2020-07-14T14:45:51ZDavid Gouletdgoulet@torproject.orgrelay: Stop using uint32_t addr for IPv4 and move to tor_addr_tThis is actually pretty big change. Originally, I planned to have it part of tor#40025 but it turns out quite a diff.
The goal is to stop using `uint32_t addr` to represent an IPv4 address and inste
ad standardize it onto `tor_addr_t` s...This is actually pretty big change. Originally, I planned to have it part of tor#40025 but it turns out quite a diff.
The goal is to stop using `uint32_t addr` to represent an IPv4 address and inste
ad standardize it onto `tor_addr_t` so the IPv4 and IPv6 interface are the same.
So many places in the code we convert from `ipv4{h|n}` to `tor_addr_t`, it is not pretty so this ticket is to move every use of those for relay objects (ri, rs, md, etc...).Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40022Prop 312: Relay learn address from NETINFO cell2020-07-14T18:17:12ZDavid Gouletdgoulet@torproject.orgProp 312: Relay learn address from NETINFO cellRelays do not currently use any address information from NETINFO cells.
We should try to learn our address for relays and possibly using `router_new_address_suggestion()` to do so.Relays do not currently use any address information from NETINFO cells.
We should try to learn our address for relays and possibly using `router_new_address_suggestion()` to do so.Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33768Make tor_inet_pton() handle bad addresses consistently on Windows2020-07-09T17:42:27ZteorMake tor_inet_pton() handle bad addresses consistently on Windowstor_inet_pton() handles bad addresses differently on Windows and Linux/macOS.
For example, the address: "2000::1a00::1000:fc098" (two "::") fails this test on Windows, but succeeds on Linux and macOS:
https://github.com/torproject/tor/p...tor_inet_pton() handles bad addresses differently on Windows and Linux/macOS.
For example, the address: "2000::1a00::1000:fc098" (two "::") fails this test on Windows, but succeeds on Linux and macOS:
https://github.com/torproject/tor/pull/1831/commits/05f4f93722d46c0e8f1d09b4dea4bf5d1743d93f#diff-048243cd6d9ed36dda0944181d8ec8abR1729
Let's fix this bug and backport it.
In general, we should make all the functions in this file behave identically:
* zero any out parameters at the start of the function
* zero any out parameters on failureTor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40058ipv6: check_descriptor_ipaddress_changed() should check for IPv6 changes2020-07-22T20:09:50ZDavid Gouletdgoulet@torproject.orgipv6: check_descriptor_ipaddress_changed() should check for IPv6 changesThat function is part of the `check_descriptor` callback run every minute.
It does _not_ look at IPv6.That function is part of the `check_descriptor` callback run every minute.
It does _not_ look at IPv6.Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33247Prop 312: 3.2.7. Publish IPv4 Descriptor on Guessed IPv6 Reachability Failure2020-07-24T17:04:58ZteorProp 312: 3.2.7. Publish IPv4 Descriptor on Guessed IPv6 Reachability FailureDepends on disabling descriptor publication on reachability
failures in legacy/trac#33223.
Should be done after the first IPv6 address guessing feature: legacy/trac#33238
or legacy/trac#33240.
If both reachability checks succeed, relay...Depends on disabling descriptor publication on reachability
failures in legacy/trac#33223.
Should be done after the first IPv6 address guessing feature: legacy/trac#33238
or legacy/trac#33240.
If both reachability checks succeed, relays should publish their IPv4 and IPv6 ORPorts in their descriptor.
If only the IPv4 ORPort check succeeds, and the IPv6 address was guessed
(rather than being explicitly configured), then relays should:
* publish their IPv4 ORPort in their descriptor,
* stop publishing their IPv6 ORPort in their descriptor, and
* log a notice about the failed IPv6 ORPort reachability check.
See proposal 312, section 3.2.7, Guessed IPv6 Reachability Failure part:
https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n567Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33265Prop 313: 6. Update Directory Spec for IPv6 Stats2020-07-13T19:25:02ZteorProp 313: 6. Update Directory Spec for IPv6 StatsWe want to add some IPv6 statistics to extra-info documents in the tor directory protocol.
See proposal 313, section 6, for a draft of this change:
https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-ipv6-stats.txt#n168We want to add some IPv6 statistics to extra-info documents in the tor directory protocol.
See proposal 313, section 6, for a draft of this change:
https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-ipv6-stats.txt#n168Sponsor 55: Improving the Tor network’s IPv6 supportNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33880Confusing "Your relay has a very large number of connections to other relays"...2021-07-09T17:22:52ZRoger DingledineConfusing "Your relay has a very large number of connections to other relays" relay messageA new relay operator reports this complaint in their logs, showing up hourly:
```
Your relay has a very large number of connections to other relays. Is your
outbound address the same as your relay address? Found 13 connections to 8
relay...A new relay operator reports this complaint in their logs, showing up hourly:
```
Your relay has a very large number of connections to other relays. Is your
outbound address the same as your relay address? Found 13 connections to 8
relays. Found 13 current canonical connections, in 0 of which we were a
non-canonical peer. 5 relays had more than 1 connection, 0 had more than 2, and
0 had more than 4 connections.
```
I checked, and their outbound address was the same as their relay address.
Upon investigation, it looks like the redundant connections are to directory authorities.
My theory is that the change from legacy/trac#17592 (which went into 0.3.1.1-alpha, commit d5a151a0) is responsible: while before that canonical relay-to-relay connections would expire after either side first reached its randomized "15 to 22.5 minute" timeout, now they expire after either side reaches its "45 to 75 minute" timeout. And since directory authorities test reachability every 1280 seconds (around 21.3 minutes), that means it is expected that most relays will have duplicate canonical connections with directory authorities.
Possible fixes:
(A) Change the notice-level log to make it clearer that it's not scary, or at least it's not actionable. Maybe that means making it info-level so nobody will see it. Probably not the best option, assuming there *are* cases where we do want relay operators to hear it.
(B) In channel_check_for_duplicates(), change `MIN_RELAY_CONNECTIONS_TO_WARN 5` to a high enough number that even if we have 2 canonical conns per authority, plus a bit more, the log message still doesn't trigger.
(C) In channel_check_for_duplicates(), skip over connections to directory authorities in some way, since we know they will be special.
(D) Make connections to or from directory authorities expire quicker, on the theory that they don't really need the same level of padding protection as other connections.
(E) Your idea here?
I'd be fine with any of B,C,D. Whichever one can be done with an easy, short, and non-invasive patch is my favorite. Maybe that's "B, raise it to 30"? That would make the message trigger when we have connections to more than 30 relays and also we have more than 45 connections open. Or we could pick the more conservative "raise it to 40", on the theory that small numbers are more likely to have edge cases and less indicative of major network problems anyway.
And while we're at it, it might be smart to say in the log message what action we want the relay operator take, e.g. "Please report:".Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40065relay: Setting ORPort [<IPv6>]:auto segfault or uses wrong port2020-07-30T16:50:51ZDavid Gouletdgoulet@torproject.orgrelay: Setting ORPort [<IPv6>]:auto segfault or uses wrong portRelated to https://gitlab.torproject.org/tpo/core/tor/-/issues/32588
With current git master (after all the s55 work), setting this in your torrc will segfault:
```
ORPort 127.0.0.1:9001
ORPort [::1]:auto NoListen
```
The given IPv6 O...Related to https://gitlab.torproject.org/tpo/core/tor/-/issues/32588
With current git master (after all the s55 work), setting this in your torrc will segfault:
```
ORPort 127.0.0.1:9001
ORPort [::1]:auto NoListen
```
The given IPv6 ORPort ends up being crap, on my system: `ORPort [::1]:12845150`.
I've also experienced a segfault once with another configuration:
```
Program received signal SIGSEGV, Segmentation fault.
0x0000555555995463 in remove_duplicate_orports (ports=<optimized out>) at src/feature/relay/relay_config.c:205
205 if (!current->explicit_addr && next->explicit_addr &&
(gdb) bt
#0 0x0000555555995463 in remove_duplicate_orports (ports=<optimized out>) at src/feature/relay/relay_config.c:205
#1 check_and_prune_server_ports (n_low_ports_out=0x7fffffffd1c0, options=0x61d000001e80, ports=0x60200000a6d0) at src/feature/relay/relay_config.c:247
#2 port_parse_ports_relay (options=options@entry=0x61d000001e80, msg=msg@entry=0x7fffffffd840, ports_out=<optimized out>,
have_low_ports_out=have_low_ports_out@entry=0x555555dd11a0 <have_low_ports>) at src/feature/relay/relay_config.c:385
#3 0x00005555559f3312 in parse_ports (options=options@entry=0x61d000001e80, validate_only=validate_only@entry=1, msg=msg@entry=0x7fffffffd840,
n_ports_out=n_ports_out@entry=0x7fffffffd3e0, world_writable_control_socket=world_writable_control_socket@entry=0x7fffffffd3f0) at src/app/config/config.c:6394
#4 0x00005555559f9f0b in options_validate_cb (old_options_=<optimized out>, options_=0x61d000001e80, msg=<optimized out>) at src/app/config/config.c:3125
#5 0x0000555555a9bbdb in config_validate_single (fmt=0x555555cf36c0 <options_format>, old_options=old_options@entry=0x0, options=options@entry=0x61d000001e80,
msg_out=msg_out@entry=0x7fffffffd840) at src/lib/confmgt/confmgt.c:1229
#6 0x0000555555aa0ac0 in config_validate (mgr=0x607000000410, old_options=old_options@entry=0x0, options=options@entry=0x61d000001e80, msg_out=msg_out@entry=0x7fffffffd840)
at src/lib/confmgt/confmgt.c:1302
#7 0x00005555559f8046 in options_validate_and_set (old_options=0x0, new_options=0x61d000001e80, msg_out=0x7fffffffd840) at src/app/config/config.c:2882
#8 0x00005555559f8607 in options_init_from_string (cf_defaults=<optimized out>, cf=<optimized out>, command=command@entry=0, command_arg=command_arg@entry=0x0,
msg=msg@entry=0x7fffffffd840) at src/app/config/config.c:4578
#9 0x00005555559f94b0 in options_init_from_torrc (argc=argc@entry=3, argv=argv@entry=0x6030000325f0) at src/app/config/config.c:4412
#10 0x000055555573d011 in tor_init (argc=argc@entry=3, argv=0x6030000325f0) at src/app/main/main.c:612
#11 0x000055555573dd9c in tor_run_main (tor_cfg=tor_cfg@entry=0x604000000050) at src/app/main/main.c:1287
#12 0x000055555573b34c in tor_main (argc=3, argv=0x7fffffffdde8) at src/feature/api/tor_api.c:164
#13 0x0000555555734390 in main (argc=<optimized out>, argv=<optimized out>) at src/app/main/tor_main.c:32
```
Not sure what is happening but clearly the `auto` is not being handled normally and causing some ripple effects sometimes.Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40060Add IPv6 ORPort config debug logging2020-07-24T16:40:17ZcAdd IPv6 ORPort config debug loggingChild of #32888
I made a pull request on GitHub: [PR 1932](https://github.com/torproject/tor/pull/1932)Child of #32888
I made a pull request on GitHub: [PR 1932](https://github.com/torproject/tor/pull/1932)https://gitlab.torproject.org/tpo/core/tor/-/issues/40068relay: Reachability test is logged every second2020-10-22T15:12:33ZDavid Gouletdgoulet@torproject.orgrelay: Reachability test is logged every secondA relay that auto discovers an IPv6 that is not reachable will attempt to launch a reachability test every second which creates a circuit each time.
From the info logs, it appears we might have a feedback loop between IPv4 bandwidth tes...A relay that auto discovers an IPv6 that is not reachable will attempt to launch a reachability test every second which creates a circuit each time.
From the info logs, it appears we might have a feedback loop between IPv4 bandwidth test and IPv6 reachability test (that should in the end never succeed).
There is this pattern every second:
```
Jul 24 14:11:53.316 [info] router_do_orport_reachability_checks(): Testing bandwidth of my IPv4 ORPort: 66.70.207.168:10001.
Jul 24 14:11:53.316 [info] origin_circuit_new(): Circuit 597 chose an idle timeout of 2445 based on 2330 seconds of predictive building remaining.
Jul 24 14:11:53.321 [info] onion_pick_cpath_exit(): Using requested exit node '$27F3833453C4006DF1E21C6BF62E4FCD8E99DEF2~WhatsGoingOn at 66.70.207.168'
Jul 24 14:11:53.328 [info] extend_info_from_node(): Including Ed25519 ID for $64A0B5722613DDFC2EB84897C550FBF4A096DE0D~NeyamRelay at 51.15.122.103
Jul 24 14:11:53.335 [info] extend_info_from_node(): Including Ed25519 ID for $77A56CB237740E24AEA2D61C8C8936232AFC1BD8~TheEpTicZeus at 54.36.227.247 and [2001:41d0:800:3a7::]
Jul 24 14:11:53.335 [info] circuit_send_first_onion_skin(): First hop: finished sending CREATE cell to '$64A0B5722613DDFC2EB84897C550FBF4A096DE0D~NeyamRelay at 51.15.122.103'
Jul 24 14:11:53.335 [info] router_do_orport_reachability_checks(): Testing reachability of my IPv6 ORPort: [<IPv6>]:10001.
Jul 24 14:11:53.335 [notice] Now checking whether IPv6 ORPort [<IPv6>]:10001 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
```
Might be that `circuit_testing_opened()` keeps on asking for an IPv6 reachability test everytime the IPv4 bandwidth circuit test opens?
Or else there is a feedback loop somehow with `circuit_build_no_more_hops()` that calls `router_do_reachability_checks()` if not all `ORPort` are reachable?
Attaching a snippet of info.log showing that problem.
[info.log](/uploads/570568cf123e728fd2fd053e49d95f03/info.log)Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29113Add IPv4/IPv6 connections to the heartbeat2020-08-25T12:43:39ZteorAdd IPv4/IPv6 connections to the heartbeatWhen we implement IPv6 extends, we'll need to monitor how many IPv4 and IPv6 connections a relay is making, using every combination of:
* IPv4/IPv6
* initiate/accept
We may also want to add the reason that the connection was initiated:
...When we implement IPv6 extends, we'll need to monitor how many IPv4 and IPv6 connections a relay is making, using every combination of:
* IPv4/IPv6
* initiate/accept
We may also want to add the reason that the connection was initiated:
* IPv4/IPv6
* reachability (origin, authorities only) / client (origin, authorities and relay also act as clients) / extend (relays and authorities only)
It's probably safe to also count all reachability circuits, but it might not be safe to count client circuits on clients, or extend circuits. Let's think about the privacy implications before adding these to the heartbeat.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40067relay: IPv4Only ORPort without any IPv6 address configured spam logs2020-11-18T16:45:06ZDavid Gouletdgoulet@torproject.orgrelay: IPv4Only ORPort without any IPv6 address configured spam logsIf you set `ORPort 9001 IPv4Only` and have no ORPort IPv6 address configured, tor now attempts to find the address and if you happen to have a public one set on your interface, this is spammed in the notice log:
```
Jul 24 13:48:34.176 ...If you set `ORPort 9001 IPv4Only` and have no ORPort IPv6 address configured, tor now attempts to find the address and if you happen to have a public one set on your interface, this is spammed in the notice log:
```
Jul 24 13:48:34.176 [notice] Guessed our IP address as [<IPV6>] (source: METHOD=INTERFACE).
```
This is due to `check_descriptor_ipaddress_changed()`. This is because `find_my_address()` finds the address from the interface but none are set in our descriptor (`&my_ri->ipv6_addr`) resulting in this non stop log.
Not sure why this is because `ri->ipv6_addr` should be set to the same that `find_my_address()` finds from the interface...
Need to investigate this one.Tor: 0.4.5.x-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/27736Make sure that Tor doesn't build an IPv4 and an IPv6 connection to the same r...2020-08-07T17:16:00ZteorMake sure that Tor doesn't build an IPv4 and an IPv6 connection to the same relayWhen we implement legacy/trac#17835, Tor will choose between IPv4 and IPv6 at random.
I'm pretty sure that we prefer existing connections to the same relay, even if the chosen address doesn't match.
But I need to read the client code t...When we implement legacy/trac#17835, Tor will choose between IPv4 and IPv6 at random.
I'm pretty sure that we prefer existing connections to the same relay, even if the chosen address doesn't match.
But I need to read the client code to make sure this check is done on clients and relays. And I need to run the new code to make sure we're not doubling the number of connections that Tor clients make.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/7193Tor's sybil protection doesn't consider IPv62021-08-23T15:19:19ZGeorge KadianakisTor's sybil protection doesn't consider IPv6Some bugs:
`get_possible_sybil_list()` doesn't consider IPv6 addresses at all.
~~`clear_status_flags_on_sybil()` doesn't clear `ipv6_addr` (and maybe more flags).~~ Obsoleted by consensus method 24, because it requires the Running flag...Some bugs:
`get_possible_sybil_list()` doesn't consider IPv6 addresses at all.
~~`clear_status_flags_on_sybil()` doesn't clear `ipv6_addr` (and maybe more flags).~~ Obsoleted by consensus method 24, because it requires the Running flag for a router to be in the consensus.
Also, maybe we could add a `log_notice` or `log_info` to mention if and which relays were found to be part of a Sybil attack.
~~Finally (and this is a minor bug), in `get_possible_sybil_list()` we assume that `max_with_same_addr < max_with_same_addr_on_authority`, which is true in the current tor network, but maybe it shouldn't be an inherent property of the source code.~~ Obsoleted by legacy/trac#20960: max_with_same_addr_on_authority has been removed.Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40206Include the IPv6 address in the descriptor that is going to be tested for sel...2021-01-13T14:53:55Zs7rInclude the IPv6 address in the descriptor that is going to be tested for self reachabilityFor IPv4 we log the address for which we test self reachability. Very useful for debugging.
Since we have IPv6 autodiscovery now, and we try hard to better support IPv6 (yey) we should include in this log line also the IPv6 address that...For IPv4 we log the address for which we test self reachability. Very useful for debugging.
Since we have IPv6 autodiscovery now, and we try hard to better support IPv6 (yey) we should include in this log line also the IPv6 address that is going to be tested for self reachability (if one exists of course and the relay/bridge is not IPv4 only).
Relays / bridges are not marked as running by directory authorities if they advertise an IPv6 address but are not reachable on it, so it makes full sense for the operators to know which address is being tested.Tor: 0.4.5.x-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40208New address disovery (IPv4 and IPv6) make it impossible to run a local lan or...2021-02-19T16:28:37Zs7rNew address disovery (IPv4 and IPv6) make it impossible to run a local lan or localhost bridge or relayThere are use cases where one wants to run a bridge or relay on their lan or localhost. This was possible until we changed address autodiscovery behavior using `AssumeReachable 1` and `PublishServerDescriptor 0` torrc options.
Now with ...There are use cases where one wants to run a bridge or relay on their lan or localhost. This was possible until we changed address autodiscovery behavior using `AssumeReachable 1` and `PublishServerDescriptor 0` torrc options.
Now with the latest alpha this is impossible.
- Scenario 1: Set `Address 127.0.0.1` and `ORPort 127.0.0.1:9001` in torrc:
Bridge / relay will start, work for some time, but complain every 60 seconds in the log file:
_Nov 23 17:04:35.000 [warn] Don't know my address while generating descriptor_
_Nov 23 17:05:35.000 [warn] Don't know my address while generating descriptor_
After 24-48 hours it eventually stop building descriptors and become unusuable.
Apparently this config `Address 127.0.0.1` doesn't trigger #40205 but I don't see why.
At debug level I only see:
_[info] address_can_be_used(): Address '127.0.0.1' is a private IP address. Tor relays that use the default DirAuthorities must have public IP addresses._
- Scenario 2: Don't set `Address` and only set `ORPort 127.0.0.1:9001` in torrc:
Bridge / relay will start, but detect the public IP address and warn:
_[warn] The IPv4 ORPort address 127.0.0.1 does not match the descriptor address <public_IPv4_addr>. If you have a static public IPv4 address, use 'Address <IPv4>' and 'OutboundBindAddress <IPv4>'. If you are behind a NAT, use two ORPort lines: 'ORPort <PublicPort> NoListen' and 'ORPort <InternalPort> NoAdvertise'._
If you have a public IPv6 address, it will also trigger #40205 that tries self reachability ignoring `AssumeReachable 1` which will make it stop working (stop building descriptors at all) after some time.
- Scenario 3: Set `Address <public_IPv4_addr>` , `ORPort 127.0.0.1:9001 NoAdvertise` and `ORPort <public_IPv4_addr> NoAdvertise` in torrc:
Bridge / relay will start, but after some time stop building descriptors entirely. It also triggers #40205 and I can't confirm or infirm if the later one makes it stop building descriptors after some time because I couldn't remove IPv6 from this box without breaking something. Depending on future testing when we fix this, I'll deploy separate vms.
Besides fixing #40205 which is the major bug here, we should allow:
- a way to disable IPv4 autodiscovery, IPv6 autodiscovery or both
- a way to run on private nets or local IP addresses v4 and link local or internal use v6 addresses maybe by setting an option like `LocalServer` that tells Tor it's OK to have localhost / lan IP on `ORPort` / `Address` and maybe automatically turn on `PublishServerDescriptor 0` and `AssumeReachable 1` if this is set.Tor: 0.4.5.x-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40205Our IPv6 Autodiscovery breaks AssumeReachable 1 torrc option2020-12-08T19:52:44Zs7rOur IPv6 Autodiscovery breaks AssumeReachable 1 torrc optionWhen last changed our IP autodiscovery code and added IPv6 support, we broke `AssumeReachable 1`
`AssumeReachable 1` tells Tor to skip self reachability tests. However, in the latest alpha, a Tor running with this torrc option, if it al...When last changed our IP autodiscovery code and added IPv6 support, we broke `AssumeReachable 1`
`AssumeReachable 1` tells Tor to skip self reachability tests. However, in the latest alpha, a Tor running with this torrc option, if it also has a working IPv6 address that is not configured in any way in torrc (as `Address` or `ORPort`) will guess the IPv6 address soon after start:
_Guessed our IP address as [public_IPv6_addr] (source: METHOD=INTERFACE)._
and immediately trigger self reachability tests including on the IPv4 address:
_Now checking whether IPv4 ORPort <public_IPv4_addr>:9001 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)_
This has a negative effect, especially on relays or bridges running on localhost / private lan with `AssumeReachable 1` and `PublishServerDescriptor 0` torrc options.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40226Loading statistics from a file for extra-info descriptors does not correctly ...2020-12-21T18:26:10ZKarsten LoesingLoading statistics from a file for extra-info descriptors does not correctly determine the last statistics blockThere's an issue with the recently added IPv6 connection statistics (apparently) not being included in extra-info descriptors, and I believe the reason is a bug in the `load_stats_file` function in `src/feature/relay/router.c`.
For exam...There's an issue with the recently added IPv6 connection statistics (apparently) not being included in extra-info descriptors, and I believe the reason is a bug in the `load_stats_file` function in `src/feature/relay/router.c`.
For example, a `stats/conn-stats` file might look like this:
```
conn-bi-direct 2020-12-13 15:48:53 (86400 s) 12,34,56,78
ipv6-conn-bi-direct 2020-12-14 15:48:53 (86400 s) 21,43,65,87
conn-bi-direct 2020-12-13 15:48:53 (86400 s) 23,45,67,89
ipv6-conn-bi-direct 2020-12-14 15:48:53 (86400 s) 32,54,76,98
```
The extra-info descriptor published by this relay would contain the following line:
```
conn-bi-direct 2020-12-14 15:48:53 (86400 s) 32,54,76,98
```
Note how these are the IPv6 numbers from the last line, not IPv4 numbers.
The bug is that `load_stats_file` finds the last occurrence of `conn-bi-direct`, which is five characters into the last line, and includes the remainder of that line in its extra-info descriptor.
What it should do is find either the last occurence of `\nconn-bi-direct` and include the file from there on (without the newline). Or if there's no such string in the file, check if the file begins with `conn-bi-direct`, and include the whole file.
@dgouletTor: 0.4.5.x-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40243dirauth: IPv6 sybil detection should not use /642021-01-22T19:22:48ZDavid Gouletdgoulet@torproject.orgdirauth: IPv6 sybil detection should not use /64Offending commit is d07f17f67685d75fec8a851b3ae3d157c1e31aa3
Basically, a `/64` is a network given to end users that is the minimum routable on the Internet iirc.
If dirauth sybil protection uses that, then all relays on the same netwo...Offending commit is d07f17f67685d75fec8a851b3ae3d157c1e31aa3
Basically, a `/64` is a network given to end users that is the minimum routable on the Internet iirc.
If dirauth sybil protection uses that, then all relays on the same network won't be able to join the network. At this moment, `moria1` is rejecting 435 relays based on that behavior because at least 3 relays are in the same network and thus all get considered as sybil.
The correct thing to do here I believe is that we should use `/128` as in match the address only, not the network. Path selection is using `/32` here so it is OK to allow multiple relays from the same network as we do in IPv4, just not in the same path.Tor: 0.4.5.x-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/402790.4.5 relay with autodetected unreachable ipv6 port says it's publishing but ...2021-02-12T17:57:54ZRoger Dingledine0.4.5 relay with autodetected unreachable ipv6 port says it's publishing but then doesn'tI restarted an old relay on Tor 0.4.5, and to my surprise, it auto detects some sort of ipv6 address, even though I have an "Address" line listing an IPv4 address explicitly.
```
Feb 06 03:17:57.448 [notice] Now checking whether IPv4 OR...I restarted an old relay on Tor 0.4.5, and to my surprise, it auto detects some sort of ipv6 address, even though I have an "Address" line listing an IPv4 address explicitly.
```
Feb 06 03:17:57.448 [notice] Now checking whether IPv4 ORPort 128.31.0.39:9005 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Feb 06 03:17:57.457 [notice] Now checking whether IPv6 ORPort [2603:400a:ffff:bb8:42a8:f0ff:fe75:6090]:9005 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Feb 06 03:17:58.264 [notice] Self-testing indicates your ORPort 128.31.0.39:9005 is reachable from the outside. Excellent.
Feb 06 03:19:00.478 [notice] Performing bandwidth self-test...done.
```
and then it doesn't find the IPv6 address reachable (not surprising), and it sits there. I was preparing to file a "woah, are we going to lose a lot of relays?" ticket, when 19 minutes later, I get this line:
```
Feb 06 03:37:55.776 [notice] Auto-discovered IPv6 address [2603:400a:ffff:bb8:42a8:f0ff:fe75:6090]:9005 has not been found reachable. However, IPv4 address is reachable. Publishing server descriptor without IPv6 address.
```
Well great!
But then it doesn't actually publish any descriptor.Tor: 0.4.5.x-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://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/40283relay: Don't fail if AF_INET6 family is not supported2021-02-09T16:15:51ZDavid Gouletdgoulet@torproject.orgrelay: Don't fail if AF_INET6 family is not supportedSomeone on tor-relays@ reported that when going from 044 to 045, their config failed to work:
```
ORPort 587
DIRPORT 995
```
with :
```
[notice] Opening OR listener on 0.0.0.0:587
[notice] Opened OR listener connection (ready) on 0.0....Someone on tor-relays@ reported that when going from 044 to 045, their config failed to work:
```
ORPort 587
DIRPORT 995
```
with :
```
[notice] Opening OR listener on 0.0.0.0:587
[notice] Opened OR listener connection (ready) on 0.0.0.0:587
[notice] Opening OR listener on [::]:587
[warn] Socket creation failed: Address family not supported by protocol
[notice] Opening Directory listener on 0.0.0.0:995
[notice] Closing partially-constructed OR listener connection (ready) on
0.0.0.0:587
[notice] Closing partially-constructed Directory listener connection
(ready) on 0.0.0.0:995
```
We should probably not fail this in that implicit case for IPv6 if the address is not supported.Tor: 0.4.5.x-stablehttps://gitlab.torproject.org/tpo/core/tor/-/issues/40296Reverse DNS IPv6 issue?2021-03-23T12:19:46Zh3nkdet3nkReverse DNS IPv6 issue?Not sure if this is related to #40288, but since version 0.4.5.6 I experienced an issue with my Tor relay node not being published.
Received following log warning:
```
Feb 16 03:15:56.000 [warn] The IPv6 ORPort address xxx::bff does no...Not sure if this is related to #40288, but since version 0.4.5.6 I experienced an issue with my Tor relay node not being published.
Received following log warning:
```
Feb 16 03:15:56.000 [warn] The IPv6 ORPort address xxx::bff does not match the descriptor address xxx::bef. If you have a static public IPv4 address, use 'Address <IPv6>' and 'OutboundBindAddress <IPv6>'. If you are behind a NAT, use two ORPort lines: 'ORPort <PublicPort> NoListen' and 'ORPort <InternalPort> NoAdvertise'.
```
However, my ORPort published in torrc config is:
`ORPort [x::bff]:43261`
It is being caused by my reverse DNS on IPv4, which resolves to my domain.
If AAAA for my domain is looked up on it returns the ":bef" address. I fixed this by changing AAAA record for my domain AAAA record to ":bff". Somehow the "auto-detect" feature is looking up reverse DNS and checking the corresponding AAAA record for the domain I guess.
Is this a bug or should I make configuration changes? I would like to be able to revert my AAAA record to ":bef" without it breaking tor node on ":bff".Tor: 0.4.5.x-post-stableGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/core/tor/-/issues/40494tor_assertion_failed_(): Bug: ../src/feature/dirclient/dirclient.c:1257: dire...2021-11-03T13:55:05Zsamip537tor_assertion_failed_(): Bug: ../src/feature/dirclient/dirclient.c:1257: directory_initiate_request: Assertion or_addr_port->port || dir_addr_port->port failed;### Summary
Tor crashes with IPv6 enabled DirPort
### Steps to reproduce:
1. Deploy an LXC Debian 11 container
2. Install Tor on it
3. Comment all Directory hardening things in systemd files related to Tor.
4. Set torrc with the follo...### Summary
Tor crashes with IPv6 enabled DirPort
### Steps to reproduce:
1. Deploy an LXC Debian 11 container
2. Install Tor on it
3. Comment all Directory hardening things in systemd files related to Tor.
4. Set torrc with the following contents:
```
Log notice syslog
RunAsDaemon 1
DataDirectory /var/lib/tor
ORPort 443
ORPort [2001:DB8::1]:443
RelayBandwidthRate 5 MB
RelayBandwidthBurst 10 MB
AccountingMax 5 TB
AccountingStart month 3 15:00
DirPort [2001:DB8::1]:80
ExitPolicy reject *:*
```
5. Have it crash after 3-10 minutes from bandwidth self-test.
### What is the current bug behavior?
The whole Tor client crashes when set with DirPort with IPv6 address in brackets followed by port.
### What is the expected behavior?
It would not crash.
### Environment
- Which version of Tor are you using? 0.4.5.10
- Which operating system are you using? Debian 11, in an LXC container
- Which installation method did you use? Distribution package
### Relevant logs and/or screenshots
```
Oct 22 06:42:35 torrelay systemd[1]: Started Anonymizing overlay network for TCP.
Oct 22 06:42:35 torrelay Tor[6069]: Signaled readiness to systemd
Oct 22 06:42:36 torrelay Tor[6069]: Bootstrapped 5% (conn): Connecting to a relay
Oct 22 06:42:36 torrelay Tor[6069]: Opening Socks listener on /run/tor/socks
Oct 22 06:42:36 torrelay Tor[6069]: Opened Socks listener connection (ready) on /run/tor/socks
Oct 22 06:42:36 torrelay Tor[6069]: Opening Control listener on /run/tor/control
Oct 22 06:42:36 torrelay Tor[6069]: Opened Control listener connection (ready) on /run/tor/control
Oct 22 06:42:36 torrelay Tor[6069]: Unable to find IPv4 address for ORPort 443. You might want to specify IPv6Only to it or set an explicit address or set Address.
Oct 22 06:42:36 torrelay Tor[6069]: Bootstrapped 10% (conn_done): Connected to a relay
Oct 22 06:42:36 torrelay Tor[6069]: Bootstrapped 14% (handshake): Handshaking with a relay
Oct 22 06:42:36 torrelay Tor[6069]: External address seen and suggested by a directory authority: <snip>
Oct 22 06:42:36 torrelay Tor[6069]: Bootstrapped 15% (handshake_done): Handshake with a relay done
Oct 22 06:42:36 torrelay Tor[6069]: Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits
Oct 22 06:42:36 torrelay Tor[6069]: Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits
Oct 22 06:42:36 torrelay Tor[6069]: Bootstrapped 95% (circuit_create): Establishing a Tor circuit
Oct 22 06:42:37 torrelay Tor[6069]: Bootstrapped 100% (done): Done
Oct 22 06:43:36 torrelay Tor[6069]: Not advertising Directory Service support (Reason: AccountingMax enabled)
Oct 22 06:44:36 torrelay Tor[6069]: Now checking whether IPv4 ORPort <snip>:443 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Oct 22 06:44:36 torrelay Tor[6069]: Now checking whether IPv6 ORPort [2001:DB8::1]:443 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Oct 22 06:44:36 torrelay Tor[6069]: Self-testing indicates your ORPort [2001:DB8::1]:443 is reachable from the outside. Excellent.
Oct 22 06:45:37 torrelay Tor[6069]: Self-testing indicates your ORPort <snip>:443 is reachable from the outside. Excellent.
Oct 22 06:45:39 torrelay Tor[6069]: Performing bandwidth self-test...done.
Oct 22 06:48:37 torrelay Tor[6069]: tor_assertion_failed_(): Bug: ../src/feature/dirclient/dirclient.c:1257: directory_initiate_request: Assertion or_addr_port->port || dir_addr_port->port failed; aborting. (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: Tor 0.4.5.10: Assertion or_addr_port->port || dir_addr_port->port failed in directory_initiate_request at ../src/feature/dirclient/dirclient.c:1257: . Stack trace: (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(log_backtrace_impl+0x6c) [0x557a907880] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(tor_assertion_failed_+0x124) [0x557a914364] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(directory_initiate_request+0x714) [0x557a9d5424] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(router_do_reachability_checks+0x184) [0x557a8d27b8] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(connection_dir_reached_eof+0x13cc) [0x557a9d783c] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(+0x1993e4) [0x557a9a93e4] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(+0x68570) [0x557a878570] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /lib/aarch64-linux-gnu/libevent-2.1.so.7(+0x234e4) [0x7f9e42e4e4] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /lib/aarch64-linux-gnu/libevent-2.1.so.7(event_base_loop+0x50c) [0x7f9e42ef84] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(do_main_loop+0xec) [0x557a8799e0] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(tor_run_main+0x1c0) [0x557a8751b4] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(tor_main+0x54) [0x557a871734] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(main+0x20) [0x557a871220] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /lib/aarch64-linux-gnu/libc.so.6(__libc_start_main+0xe8) [0x7f9dd5c218] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay Tor[6069]: Bug: /usr/bin/tor(+0x612a8) [0x557a8712a8] (on Tor 0.4.5.10 )
Oct 22 06:48:37 torrelay systemd[1]: tor@default.service: Main process exited, code=killed, status=6/ABRT
Oct 22 06:48:37 torrelay systemd[1]: tor@default.service: Failed with result 'signal'.
Oct 22 06:48:37 torrelay systemd[1]: tor@default.service: Consumed 12.377s CPU time.
Oct 22 06:48:37 torrelay systemd[1]: tor@default.service: Scheduled restart job, restart counter is at 5.
Oct 22 06:48:37 torrelay systemd[1]: Stopped Anonymizing overlay network for TCP.
Oct 22 06:48:37 torrelay systemd[1]: tor@default.service: Consumed 12.377s CPU time.
```
### Possible fixesTor: 0.4.5.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.org