Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:50:22Zhttps://gitlab.torproject.org/legacy/trac/-/issues/33271Prop 313: 8.2. Test IPv6 Statistics using Chutney2020-06-13T15:50:22ZteorProp 313: 8.2. Test IPv6 Statistics using ChutneyWe want to test IPv6 connection and consumed bandwidth statistics using
chutney networks. However, chutney runs for a short amount of time, and
creates a limited amount of traffic, so we also need to test these changes
on the public tor ...We want to test IPv6 connection and consumed bandwidth statistics using
chutney networks. However, chutney runs for a short amount of time, and
creates a limited amount of traffic, so we also need to test these changes
on the public tor network.
In particular, we have struggled to test statistics using chutney, because
tor's hard-coded statistics period is 24 hours. (And most chutney networks
run for under 1 minute.)
Maybe we can change the statistics interval to 10-30 seconds, and see if that works?
See proposal 313, section 8.2, chutney tests part:
https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-ipv6-stats.txt#n355Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33267Prop 313: 8.1. Test IPv6 Relay Consensus Counts using Chutney2020-06-13T15:50:20ZteorProp 313: 8.1. Test IPv6 Relay Consensus Counts using ChutneyTest the IPv6 relay count script in proposal 313, using chutney networks.
Since chutney creates a limited number of relays, we also need to test these changes on consensuses from the public tor network. So we shouldn't spend much time t...Test the IPv6 relay count script in proposal 313, using chutney networks.
Since chutney creates a limited number of relays, we also need to test these changes on consensuses from the public tor network. So we shouldn't spend much time testing the script with chutney.
See proposal 313, section 8.1, chutney tests part:
https://gitweb.torproject.org/torspec.git/tree/proposals/313-relay-ipv6-stats.txt#n337Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33251Prop 312: 5.1. Test Relay IPv6 Addresses Discovery using Chutney2020-06-13T15:50:19ZteorProp 312: 5.1. Test Relay IPv6 Addresses Discovery using ChutneyTest the IPv6 ORPort Address Detection changes in proposal 312, using chutney networks.
Since chutney runs on private addresses, these tests might be difficult to write, or they might not tell us much about how tor relays behave on the ...Test the IPv6 ORPort Address Detection changes in proposal 312, using chutney networks.
Since chutney runs on private addresses, these tests might be difficult to write, or they might not tell us much about how tor relays behave on the public tor network. So we shouldn't spend much time on them.
See proposal 312, section 5.1:
​https://gitweb.torproject.org/torspec.git/tree/proposals/312-relay-auto-ipv6-addr.txt#n1461Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33231Prop 311: 6.3. Test Legacy Relays Accept IPv6 Extends using Chutney2020-06-13T15:50:17ZteorProp 311: 6.3. Test Legacy Relays Accept IPv6 Extends using ChutneyThis ticket depends on relay IPv6 extends in #33220. We may also need to disable the "Relay=3" protocol version check.
Test IPv6 extends from newer relays (which implement proposal 311) to older relays (which do not).
Although proposal...This ticket depends on relay IPv6 extends in #33220. We may also need to disable the "Relay=3" protocol version check.
Test IPv6 extends from newer relays (which implement proposal 311) to older relays (which do not).
Although proposal 311 does not create these kinds of circuits, we need to check for bugs and excessive logs in older tor versions.
See proposal 311, section 6.3:
https://gitweb.torproject.org/torspec.git/tree/proposals/311-relay-ipv6-reachability.txt#n698Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/33228Prop 311: 6.1. Test IPv6 ORPort Reachability using Chutney2020-06-13T15:50:17ZteorProp 311: 6.1. Test IPv6 ORPort Reachability using ChutneyTest the IPv6 ORPort Reachability and Extends changes in proposal 311, using chutney networks with AssumeReachable disabled.
(Chutney currently enables AssumeReachable by default.)
See proposal 311, section 6.1:
https://gitweb.torproje...Test the IPv6 ORPort Reachability and Extends changes in proposal 311, using chutney networks with AssumeReachable disabled.
(Chutney currently enables AssumeReachable by default.)
See proposal 311, section 6.1:
https://gitweb.torproject.org/torspec.git/tree/proposals/311-relay-ipv6-reachability.txt#n671
Chutney already implements some of these tests, but we still need a fix for a bridge descriptor upload bug, see tor #33582 and chutney #33407.Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33043Prop 306: Keep bridge IPv6 behaviour in sync with client behaviour2020-06-13T15:50:13ZteorProp 306: Keep bridge IPv6 behaviour in sync with client behaviourWe should make some minor changes to Proposal 306, so that bridge IPv6 behaviour stays in sync with client IPv6 behaviour:
https://gitweb.torproject.org/torspec.git/tree/proposals/306-ipv6-happy-eyeballs.txt
For an description of the ne...We should make some minor changes to Proposal 306, so that bridge IPv6 behaviour stays in sync with client IPv6 behaviour:
https://gitweb.torproject.org/torspec.git/tree/proposals/306-ipv6-happy-eyeballs.txt
For an description of the necessary changes, see section 3.3.1 and 3.3.2 of the draft proposal 311:
https://github.com/torproject/torspec/pull/103/files#diff-090a91ed4c8eac745c5ecc316b78dab4R153Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/30954Address torrc option is ignored if set second time for the IPv6 address2020-06-13T15:49:56Zs7rAddress torrc option is ignored if set second time for the IPv6 addressCurrently if we specify `Address` 2 times in the same torrc, once for IPv4 address and once for IPv6 address, it will just ignore the second entry as like it would be for the same IP family:
```
[warn] Option 'Address' used more than on...Currently if we specify `Address` 2 times in the same torrc, once for IPv4 address and once for IPv6 address, it will just ignore the second entry as like it would be for the same IP family:
```
[warn] Option 'Address' used more than once; all but the last value will be ignored.
```
This behavior is perfect for cases where operators specify more addresses from the same family (like IPv4 for example) in the same torrc. I am marking this Low priority because it's here only to remind us about it when IPv6 autodetection will be implemented.
I know currently does not do IPv6 address detection so I am guessing this is why it currently does not care to learn about an IPv6 address from `Address` torrc setting, and only from `ORPort` to build just descriptors and be optimistic about getting the ReachableIPv6 flag, but when this changes it should be possible to specify `Address` 2 times in torrc, once for IPv4 and once for IPv6, the same as for `OutboundBindAddress | OutboundBindAddressOR | OutboundBindAddressExit`.Tor: unspecifiedNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/32954Stop public authorities specifying an internal address for their IPv6 ORPort2020-06-13T15:49:56ZteorStop public authorities specifying an internal address for their IPv6 ORPortWhen we implement `Address [IPv6]` in #30954, we should check that the supplied IPv6 address is a public address on Directory Authorities.
This matches the current `Address IPv4` check for authorities.When we implement `Address [IPv6]` in #30954, we should check that the supplied IPv6 address is a public address on Directory Authorities.
This matches the current `Address IPv4` check for authorities.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/27490When ClientPreferIPv6ORPort is set to auto, and a relay is being chosen for a...2020-06-13T15:49:50ZNeel Chauhanneel@neelc.orgWhen ClientPreferIPv6ORPort is set to auto, and a relay is being chosen for a directory or orport connection, prefer IPv4 or IPv6 at randomSuggested by teor at #17835:
>1. Make ClientPreferIPv6ORPort into an autobool
>2. When ClientPreferIPv6ORPort is set to auto, and a relay is being chosen for a directory or orport connection, prefer IPv4 or IPv6 at randomSuggested by teor at #17835:
>1. Make ClientPreferIPv6ORPort into an autobool
>2. When ClientPreferIPv6ORPort is set to auto, and a relay is being chosen for a directory or orport connection, prefer IPv4 or IPv6 at randomTor: 0.4.0.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/32905Remove the ClientAutoIPv6ORPort option2020-06-13T15:49:49ZNeel Chauhanneel@neelc.orgRemove the ClientAutoIPv6ORPort optionIn #27490, we introduced the option `ClientAutoIPv6ORPort`, which randomly tries IPv4 or IPv6 randomly.
This option is not true Happy Eyeballs and fails very often, usually trying IPv6 on networks which are IPv4-only (#30639).
We shoul...In #27490, we introduced the option `ClientAutoIPv6ORPort`, which randomly tries IPv4 or IPv6 randomly.
This option is not true Happy Eyeballs and fails very often, usually trying IPv6 on networks which are IPv4-only (#30639).
We should remove this option.Tor: 0.4.4.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/32588Setting ORPort [ipv6]:auto mistakenly advertises port 942020-06-13T15:49:47ZRoger DingledineSetting ORPort [ipv6]:auto mistakenly advertises port 94Start your Tor with
```
ORPort 9001
ORPort [2a01:238:43e4:2b00:ae5a:a980:1f63:cc5e]:auto nolisten
DirPort 9030
```
and let it start up. Then go to http://127.0.0.1:9030/tor/server/authority and check out how it has the line
```
or-addres...Start your Tor with
```
ORPort 9001
ORPort [2a01:238:43e4:2b00:ae5a:a980:1f63:cc5e]:auto nolisten
DirPort 9030
```
and let it start up. Then go to http://127.0.0.1:9030/tor/server/authority and check out how it has the line
```
or-address [2a01:238:43e4:2b00:ae5a:a980:1f63:cc5e]:94
```
First: How did it pick that number? It's a weird choice for a port.
Second: If this is actually your ipv6 address, you can leave out the nolisten, and that's where things get interesting. Your logs will say something like
```
Nov 24 01:53:42 v4 tor[10988]: Nov 24 01:53:42.001 [notice] Opening OR listener on [2a01:238:43e4:2b00:ae5a:a980:1f63:cc5e]:0
Nov 24 01:53:42 v4 tor[10988]: Nov 24 01:53:42.002 [notice] Opened OR listener on [2a01:238:43e4:2b00:ae5a:a980:1f63:cc5e]:41535
```
but then your descriptor will still say :94.
This is happening right now to relay "Testbit": they have set :auto for their ipv6 address in their ORPort, they get the above line about how it's opened on port 41535, and yet their descriptor says it's on port 94.Tor: 0.4.3.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/32888Log address config info when tor starts up2020-06-13T15:49:47ZteorLog address config info when tor starts upWe're going to be modifying tor's address detection and reachability code for an upcoming sponsor. To help us debug, we should log the following info when tor starts up:
IPv4:
* the `Address` torrc option
* and whether it is an IP add...We're going to be modifying tor's address detection and reachability code for an upcoming sponsor. To help us debug, we should log the following info when tor starts up:
IPv4:
* the `Address` torrc option
* and whether it is an IP address, or a DNS name
* the local hostname
* and whether it is an IP address, or a DNS name
* the local network interface addresses
See `resolve_my_address()` for details.
IPv6:
* the IPv6 address of the first IPv6 `ORPort` torrc option
See `router_build_fresh_descriptor()` and `router_get_advertised_ipv6_or_ap()` (in #32588) for details.
When (or if) we use them as part of address detection, we should also log the following info:
IPv4 and IPv6:
* the `Address` torrc option
* and whether it is an IP address, or a DNS name
* the IPv4 and IPv6 addresses of the first `ORPort` torrc option of each address family
* the local hostname
* and whether it is an IP address, or a DNS name
* the local network interface addresses
Notes:
* We'll need a proposal to decide if `ORPort` or hostname should come first
* We'll probably want a summary at notice level, and then detailed logs at info level
* If all these methods fail, relays use `X-Your-Address-Is:` headers from directory authorities. They are out of scope, because they are not available at startup.
* Similarly, we won't print address reachability self-testing info, because it's not available at startup.
* We may want to print similar log messages (including `X-Your-Address-Is:` and reachability info) as part of tor's regular heartbeat messages. But that deserves a separate ticket.
I don't think we'll use (or log):
* the addresses of any `DirPort` torrc options
* the addresses of multiple `ORPort` torrc optionsTor: unspecifiedcchttps://gitlab.torproject.org/legacy/trac/-/issues/32822Make authorities add their own IPv6 address to trusted dir servers2020-06-13T15:49:29ZteorMake authorities add their own IPv6 address to trusted dir serversAuthorities add themselves to trusted dir servers, but they don't add their own IPv6 addresses.Authorities add themselves to trusted dir servers, but they don't add their own IPv6 addresses.Tor: 0.4.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/32707need a mechanism to automatically detect the ipv6 address of the node2020-06-13T15:49:00ZTracneed a mechanism to automatically detect the ipv6 address of the nodebecause for a dynamic ipv6 address specifying the current ipv6 address requires automatic editing torrc by a scripts(or have i found no other way). it is also necessary to automatically detect when the ipv6 address changes as it is done ...because for a dynamic ipv6 address specifying the current ipv6 address requires automatic editing torrc by a scripts(or have i found no other way). it is also necessary to automatically detect when the ipv6 address changes as it is done for ipv4
**Trac**:
**Username**: babutTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/32629Re-enable 1 or 2 more macOS jobs in Travis2020-06-13T15:48:43ZteorRe-enable 1 or 2 more macOS jobs in TravisReverts #32177.
We might need to merge or disable some jobs, to get builds to finish fast enough.Reverts #32177.
We might need to merge or disable some jobs, to get builds to finish fast enough.Tor: 0.2.9.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/32315Can't perform reverse DNS lookup for a (binary) IPv6 address2020-06-13T15:47:35ZTracCan't perform reverse DNS lookup for a (binary) IPv6 addressTor provides the "RESOLVE_PTR" (0xF1) command as an extension to the SOCKS5 protocol, which can in theory be used to perform a reverse DNS lookup of an IPv4 or IPv6 address.
As with other SOCKS5 commands, this command takes an argument ...Tor provides the "RESOLVE_PTR" (0xF1) command as an extension to the SOCKS5 protocol, which can in theory be used to perform a reverse DNS lookup of an IPv4 or IPv6 address.
As with other SOCKS5 commands, this command takes an argument which can either be a binary IPv4 or IPv6 address, or an ASCII string.
Somewhat contrary to ticket #32314, this command works for IPv6 addresses only if the address is specified as an ASCII string (address type 3) with no brackets. If the address is specified in binary (address type 4), or as a string enclosed in brackets, Tor will reject it.
**Trac**:
**Username**: liberatTor: 0.4.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/32314Can't connect to literal IPv6 address containing double colon2020-06-13T15:47:34ZTracCan't connect to literal IPv6 address containing double colonWhen an application wants to use Tor's SOCKS port to connect to a known IPv6 address, it has a couple of options:
- It can specify a 16-byte binary address using address type 4.
- It can specify the address as an ASCII string using add...When an application wants to use Tor's SOCKS port to connect to a known IPv6 address, it has a couple of options:
- It can specify a 16-byte binary address using address type 4.
- It can specify the address as an ASCII string using address type 3.
If the address is specified as a string, Tor accepts IPv6 addresses either with or without brackets. For example, Tor will accept either "2a01:4f8:fff0:4f:266:37ff:fe2c:5d19" or "[2a01:4f8:fff0:4f:266:37ff:fe2c:5d19]".
However, if the address is abbreviated using double-colon notation, it only works if enclosed in brackets: "[2a00:1450:4001:800::200e]" works, but "2a00:1450:4001:800::200e" does not. On the other hand, the unabbreviated form "2a00:1450:4001:800:0:0:0:200e" does work.
The problem appears to be:
- The destination is transmitted to the exit relay as a string of the form "<hostname>:<port>".
- The exit relay tries to parse this string by calling the function tor_addr_port_split.
- The string "2a00:1450:4001:800::200e:80" is a valid IPv6 literal, so tor_addr_port_split interprets it as an address with no port number.
- The relay refuses to connect to an address with no port number.
Note that if the application uses the binary form (address type 4), this is internally converted into a string enclosed in brackets. However, it seems to be more common for applications to use the ASCII form, without brackets. For example, if you try to visit http://[2a00:1450:4001:800::200e]/ in Tor Browser, it will fail, whereas http://[2a01:4f8:fff0:4f:266:37ff:fe2c:5d19]/ succeeds.
So there are a few ways this could be fixed:
(a) applications could be changed to use either the binary form or wrap the address in brackets;
(b) the Tor proxy could automatically add brackets around IPv6 addresses;
(c) the exit relay could be smarter about parsing IPv6 addresses.
It seems to me that (b) would be the most sensible option, but it might be reasonable to do (c) as well.
In the long term, I think it'd be wise to deprecate the use of IPv6 addresses without brackets in RELAY_BEGIN, as well as any other places where tor_addr_port_split is used, because it's just confusing.
**Trac**:
**Username**: liberatTor: 0.4.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/32141single onion v3 IPv6 intro circuit BUG() warnings2020-06-13T15:46:54Zteorsingle onion v3 IPv6 intro circuit BUG() warningsLooks like some of our assertions are wrong in single onion IPv6 mode, but chutney still succeeds:
```
Warning: Bug: Tor 0.4.3.0-alpha-dev (git-d616214e474084fd): Non-fatal assertion !(!hs_ident_intro_circ_is_valid(circ->hs_ident)) fail...Looks like some of our assertions are wrong in single onion IPv6 mode, but chutney still succeeds:
```
Warning: Bug: Tor 0.4.3.0-alpha-dev (git-d616214e474084fd): Non-fatal assertion !(!hs_ident_intro_circ_is_valid(circ->hs_ident)) failed in intro_circ_is_ok at src/feature/hs/hs_client.c:491. Stack trace: (on Tor 0.4.3.0-alpha-dev d616214e474084fd) Number: 1
Warning: Bug: Tor 0.4.3.0-alpha-dev (git-d616214e474084fd): Non-fatal assertion !(desc == NULL) failed in setup_intro_circ_auth_key at src/feature/hs/hs_client.c:685. Stack trace: (on Tor 0.4.3.0-alpha-dev d616214e474084fd) Number: 1
Warning: tor_bug_occurred_: Bug: src/feature/hs/hs_client.c:491: intro_circ_is_ok: Non-fatal assertion !(!hs_ident_intro_circ_is_valid(circ->hs_ident)) failed. (Future instances of this warning will be silenced.) (on Tor 0.4.3.0-alpha-dev d616214e474084fd) Number: 1
Warning: tor_bug_occurred_: Bug: src/feature/hs/hs_client.c:685: setup_intro_circ_auth_key: Non-fatal assertion !(desc == NULL) failed. (Future instances of this warning will be silenced.) (on Tor 0.4.3.0-alpha-dev d616214e474084fd) Number: 1
```
https://travis-ci.org/torproject/tor/jobs/599435523#L3431Tor: 0.4.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/31793Bug: tor_addr_is_internal() called from src/feature/dirauth/process_descs.c:4...2020-06-13T15:45:47ZRoger DingledineBug: tor_addr_is_internal() called from src/feature/dirauth/process_descs.c:447 with a non-IP address of type 0Starting tor from git master on moria1, I get tens of thousands of these:
```
Sep 18 16:32:03.546 [warn] tor_addr_is_internal_(): Bug: tor_addr_is_internal() called from src/feature/dirauth/process_descs.c:447 with a non-IP address of ty...Starting tor from git master on moria1, I get tens of thousands of these:
```
Sep 18 16:32:03.546 [warn] tor_addr_is_internal_(): Bug: tor_addr_is_internal() called from src/feature/dirauth/process_descs.c:447 with a non-IP address of type 0 (on Tor 0.4.2.1-alpha-dev d6d3e829dd20b78e)
Sep 18 16:32:03.546 [warn] tor_bug_occurred_(): Bug: src/lib/net/address.c:318: tor_addr_is_internal_: This line should not have been reached. (Future instances of this warning will be silenced.) (on Tor 0.4.2.1-alpha-dev d6d3e829dd20b78e)
Sep 18 16:32:03.546 [warn] Bug: Tor 0.4.2.1-alpha-dev (git-d6d3e829dd20b78e): Line unexpectedly reached at tor_addr_is_internal_ at src/lib/net/address.c:318. Stack trace: (on Tor 0.4.2.1-alpha-dev d6d3e829dd20b78e)
Sep 18 16:32:03.546 [warn] Bug: ../git/src/app/tor(log_backtrace_impl+0x47) [0x55b51002c057] (on Tor 0.4.2.1-alpha-dev d6d3e829dd20b78e)
Sep 18 16:32:03.546 [warn] Bug: ../git/src/app/tor(tor_bug_occurred_+0x19b) [0x55b5100270eb] (on Tor 0.4.2.1-alpha-dev d6d3e829dd20b78e)
Sep 18 16:32:03.546 [warn] Bug: ../git/src/app/tor(tor_addr_is_internal_+0xbf) [0x55b51001c47f] (on Tor 0.4.2.1-alpha-dev d6d3e829dd20b78e)
Sep 18 16:32:03.546 [warn] Bug: ../git/src/app/tor(authdir_wants_to_reject_router+0x159) [0x55b50ff8a609] (on Tor 0.4.2.1-alpha-dev d6d3e829dd20b78e)
Sep 18 16:32:03.546 [warn] Bug: ../git/src/app/tor(router_add_to_routerlist+0x50e) [0x55b50ff4a32e] (on Tor 0.4.2.1-alpha-dev d6d3e829dd20b78e)
Sep 18 16:32:03.546 [warn] Bug: ../git/src/app/tor(dirserv_add_descriptor+0x239) [0x55b50ff89709] (on Tor 0.4.2.1-alpha-dev d6d3e829dd20b78e)
Sep 18 16:32:03.546 [warn] Bug: ../git/src/app/tor(init_keys+0x446) [0x55b50ff5de66] (on Tor 0.4.2.1-alpha-dev d6d3e829dd20b78e)
Sep 18 16:32:03.546 [warn] Bug: ../git/src/app/tor(set_options+0x755) [0x55b50ff9aae5] (on Tor 0.4.2.1-alpha-dev d6d3e829dd20b78e)
Sep 18 16:32:03.546 [warn] Bug: ../git/src/app/tor(options_init_from_string+0x35a) [0x55b50ffa01ea] (on Tor 0.4.2.1-alpha-dev d6d3e829dd20b78e)
Sep 18 16:32:03.546 [warn] Bug: ../git/src/app/tor(options_init_from_torrc+0x5e8) [0x55b50ffa0858] (on Tor 0.4.2.1-alpha-dev d6d3e829dd20b78e)
Sep 18 16:32:03.546 [warn] Bug: ../git/src/app/tor(tor_init+0x309) [0x55b50fe6cf99] (on Tor 0.4.2.1-alpha-dev d6d3e829dd20b78e)
Sep 18 16:32:03.546 [warn] Bug: ../git/src/app/tor(tor_run_main+0xa9) [0x55b50fe6d739] (on Tor 0.4.2.1-alpha-dev d6d3e829dd20b78e)
Sep 18 16:32:03.546 [warn] Bug: ../git/src/app/tor(tor_main+0x43) [0x55b50fe6a9c3] (on Tor 0.4.2.1-alpha-dev d6d3e829dd20b78e)
Sep 18 16:32:03.546 [warn] Bug: ../git/src/app/tor(main+0x19) [0x55b50fe6a649] (on Tor 0.4.2.1-alpha-dev d6d3e829dd20b78e)
Sep 18 16:32:03.546 [warn] Bug: /lib64/libc.so.6(__libc_start_main+0x100) [0x7fec1801dd20] (on Tor 0.4.2.1-alpha-dev d6d3e829dd20b78e)
Sep 18 16:32:03.546 [warn] Bug: ../git/src/app/tor(+0x5f559) [0x55b50fe6a559] (on Tor 0.4.2.1-alpha-dev d6d3e829dd20b78e)
```Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/21003extend_info_describe should list IPv6 address (if present)2020-06-13T15:44:46Zteorextend_info_describe should list IPv6 address (if present)When running an IPv6-only client using:
```
src/or/tor ClientUseIPv4 0 DataDirectory `mktemp -d` UseMicrodescriptors 0
```
I get log messages like
`[info] add_an_entry_guard(): Chose $906933A309F15D7CF379127078A6791DF9B0C763~Unnamed at ...When running an IPv6-only client using:
```
src/or/tor ClientUseIPv4 0 DataDirectory `mktemp -d` UseMicrodescriptors 0
```
I get log messages like
`[info] add_an_entry_guard(): Chose $906933A309F15D7CF379127078A6791DF9B0C763~Unnamed at 91.121.82.25 as new entry guard`
But I'm really contacting them on their IPv6 address. So we should list it along with the IPv4 address.Tor: 0.4.2.x-final