Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2022-06-17T16:05:15Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/21397Tor TransparentProxy documentation: add IPv6 support / port to nftables2022-06-17T16:05:15ZadrelanosTor TransparentProxy documentation: add IPv6 support / port to nftableshttps://trac.torproject.org/projects/tor/wiki/doc/TransparentProxy
* add IPv6 support
* port to nftableshttps://trac.torproject.org/projects/tor/wiki/doc/TransparentProxy
* add IPv6 support
* port to nftableshttps://gitlab.torproject.org/tpo/core/tor/-/issues/21357potential bug: Some IPv6Exits do not add the ipv6-policy line to their descri...2020-06-27T13:57:16Zcypherpunkspotential bug: Some IPv6Exits do not add the ipv6-policy line to their descriptorAn exit relay is expected to add a ipv6-policy line to its descriptor when:
{{{ IPv6Exit 1 }}
and its exit policy allows at least a single IPv6 destination.
There are 10 known cases where the exit didn't generate an ipv6-policy line.
...An exit relay is expected to add a ipv6-policy line to its descriptor when:
{{{ IPv6Exit 1 }}
and its exit policy allows at least a single IPv6 destination.
There are 10 known cases where the exit didn't generate an ipv6-policy line.
legacy/trac#21355 should help with debugging.
references:
list of exit relays with IPv6 ORPort and no ipv6-policy (if IPv6Exit setting is known, it is shown at the end of the line)
https://gist.githubusercontent.com/nusenu/1534d210049fcb04919ae5a4529ea894/raw/4a5611aedb81c5bc01630433c85e8fc818c01a1d/IPv6Exit%25201%253F
https://lists.torproject.org/pipermail/tor-dev/2017-January/011860.html
https://lists.torproject.org/pipermail/tor-relays/2017-January/011806.htmlTor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/21355Warn when IPv6Exits have no ipv6-policy line in their descriptor2020-07-28T02:21:36ZteorWarn when IPv6Exits have no ipv6-policy line in their descriptorThere appears to be a bug in Tor's IPv6 Exit code, where exits that have IPv6Exit set do not have an ipv6-policy line in their descriptor.
To assist in diagnosing this bug, we should log a warning message (not a bug message) containing ...There appears to be a bug in Tor's IPv6 Exit code, where exits that have IPv6Exit set do not have an ipv6-policy line in their descriptor.
To assist in diagnosing this bug, we should log a warning message (not a bug message) containing the full exit policy, when the IPv6 exit policy summary is empty, but IPv6Exit is 1 and ExitRelay is 1 or auto.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/21346Clients with NoIPv4Traffic should only choose IPv6-supporting Exits2020-06-27T13:57:17ZteorClients with NoIPv4Traffic should only choose IPv6-supporting ExitsTor logs a warning when this happens in connection_ap_get_begincell_flags(), but it should actually fail.
Earlier in the process, it should choose an IPv6-supporting exit when NoIPv4Traffic is set (and choose an IPv4-supporting exit whe...Tor logs a warning when this happens in connection_ap_get_begincell_flags(), but it should actually fail.
Earlier in the process, it should choose an IPv6-supporting exit when NoIPv4Traffic is set (and choose an IPv4-supporting exit when NoIPv6 traffic is set).Tor: 0.3.5.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/21311Exits should resolve IPv6 addresses, regardless of IPv6Exit2022-06-17T17:40:46ZteorExits should resolve IPv6 addresses, regardless of IPv6ExitThat way, clients find out if the hostname they're trying to reach is IPv6-only, and can try an IPv6 exit next time.
Was: launch_resolve() should always resolve AAAA records, regardless of IPv6ExitThat way, clients find out if the hostname they're trying to reach is IPv6-only, and can try an IPv6 exit next time.
Was: launch_resolve() should always resolve AAAA records, regardless of IPv6Exithttps://gitlab.torproject.org/tpo/core/tor/-/issues/21310Exits should tell clients when they are connecting to an IPv6-only hostname2020-07-28T01:54:09ZteorExits should tell clients when they are connecting to an IPv6-only hostnameWhen legacy/trac#21311 is finished, we need to make exits tell clients that the hostname they asked for is IPv6-onlyWhen legacy/trac#21311 is finished, we need to make exits tell clients that the hostname they asked for is IPv6-onlyTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/21043Make ClientUseIPv4 and ClientUseIPv6 equivalent to ReachableAddresses2020-07-27T23:33:29ZteorMake ClientUseIPv4 and ClientUseIPv6 equivalent to ReachableAddressesOnce legacy/trac#20996 is fixed, we should also make ClientUseIPv4 and ClientUseIPv6 work the same as the equivalent ReachableAddresses settings.
For example:
ClientUseIPv4 = accept/reject 0.0.0.0/0 = accept/reject *4
ClientUseIPv6 = ac...Once legacy/trac#20996 is fixed, we should also make ClientUseIPv4 and ClientUseIPv6 work the same as the equivalent ReachableAddresses settings.
For example:
ClientUseIPv4 = accept/reject 0.0.0.0/0 = accept/reject *4
ClientUseIPv6 = accept/reject [::]/0 = accept6/reject6 * = accept/reject *6
Bootstrap and guards should also work if ReachableAddresses blocks almost all addresses of a particular type.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/21003extend_info_describe should list IPv6 address (if present)2020-06-27T13:57:33Zteorextend_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-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20999Make IP6-using clients try harder to find an IPv6 directory server2020-06-27T13:57:34ZteorMake IP6-using clients try harder to find an IPv6 directory serverfascist_firewall_use_ipv6 doesn't take IPv6 ORPort preferences into account. (IPv6 DirPorts are deprecated, see legacy/trac#19704.)
This makes it skip IPv6 address checks, when it really should be trying harder to find them.
Part of le...fascist_firewall_use_ipv6 doesn't take IPv6 ORPort preferences into account. (IPv6 DirPorts are deprecated, see legacy/trac#19704.)
This makes it skip IPv6 address checks, when it really should be trying harder to find them.
Part of legacy/trac#20996, opening this for the bug number.Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20996IPv6-only client fails to bootstrap on microdescriptor fetch/fallback2020-06-27T13:57:34ZmtigasIPv6-only client fails to bootstrap on microdescriptor fetch/fallbackFor a fresh client (nothing cached) when configured with "ClientUseIPv4 0" + "ClientUseIPv6 1" (and client is also on a network with no external IPv4 address).
Hangs at 45%, Asking for relay descriptors. Running on 0.2.9.7-rc.
Works fi...For a fresh client (nothing cached) when configured with "ClientUseIPv4 0" + "ClientUseIPv6 1" (and client is also on a network with no external IPv4 address).
Hangs at 45%, Asking for relay descriptors. Running on 0.2.9.7-rc.
Works fine with UseMicrodescriptors 0. ("ClientPreferIPv6DirPort 1" + "ClientPreferIPv6ORPort 1" have no affect.)
Attaching torrc and a log @ loglevel info.
CCing teor here since I vaguely remember having a conversation with him at last tor meeting where I believe he mentioned to try using "UseMicrodescriptors 0"; which (now that I've had a chance to test) seems like a good workaround at the moment.
Can't seem to find another ticket for this exactly, and just wanted something to refer to (and post some logs and info on), so please excuse if it’s actually a dupe. Possibly related: legacy/trac#20916.
On the mobile side, Apple’s starting to require that apps work in IPv6-only networks. And I’ve noticed that I’ve recently been assigned IPv6/NAT64 (with no external IPv4 address) on T-Mobile lately. But of course this also affects non-mobile IPv6-only networks.
(On the other hand, I'm quite happy that this all _does_ work under IPv6 with the "UseMicrodescriptors 0" workaround.)Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20916Proposal: Put Relay IPv6 Addresses in the microdesc consensus2020-06-27T13:57:39ZteorProposal: Put Relay IPv6 Addresses in the microdesc consensusThe relay wedostor is bound to an unreachable IPv6 address.
https://atlas.torproject.org/#details/F70B7C5CD72D74C7F9F2DC84FA9D20D51BA13610
(Atlas shows no IPv6 address.)
It advertises the IPv6 address in its descriptor:
http://46.28.109...The relay wedostor is bound to an unreachable IPv6 address.
https://atlas.torproject.org/#details/F70B7C5CD72D74C7F9F2DC84FA9D20D51BA13610
(Atlas shows no IPv6 address.)
It advertises the IPv6 address in its descriptor:
http://46.28.109.231:9030/tor/server/authority
The full consensus has no IPv6 address:
http://collector.torproject.org/recent/relay-descriptors/consensuses/2016-12-07-11-00-00-consensus
But the microdesc does have the IPv6 address:
http://46.28.109.231:9030/tor/micro/d/Z7YTOuC8gXcelqDlUhpsvaTPLp04QhyEXvOWo1inWj8
And strangely, no client I have access to seems to download this microdescriptor. Maybe it registers as invalid somehow?
A fix to this will require a new consensus method.Tor: unspecifiedteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20247seccomp2 crash after closing and opening ipv6 DirPort + OrPort2020-06-27T13:58:07Ztoralfseccomp2 crash after closing and opening ipv6 DirPort + OrPortrun this :
```
/etc/init.d/tor status 2>/dev/null
if [[ $? -eq 0 ]]; then
sed -i -e 's/^DirPort *\[/#DirPort [/' -e 's/^ORPort *\[/#ORPort [/' /etc/tor/torrc
/etc/init.d/tor reload
fi
# renew cert
#
/usr/bin/certbot renew --standalo...run this :
```
/etc/init.d/tor status 2>/dev/null
if [[ $? -eq 0 ]]; then
sed -i -e 's/^DirPort *\[/#DirPort [/' -e 's/^ORPort *\[/#ORPort [/' /etc/tor/torrc
/etc/init.d/tor reload
fi
# renew cert
#
/usr/bin/certbot renew --standalone --non-interactive --text --renew-hook RestartJabber --disable-hook-validation &>$log
# reopen Tor ports
#
sed -i -e 's/^#DirPort *\[/DirPort [/' -e 's/^#ORPort *\[/ORPort [/' /etc/tor/torrc
/etc/init.d/tor status 2>/dev/null
if [[ $? -eq 0 ]]; then
/etc/init.d/tor reload
fi
```
to get this:
```
============================================================ T= 1474911552
(Sandbox) Caught a bad syscall attempt (syscall setsockopt)
/usr/bin/tor(+0x15dbc8)[0x1ac72c9bc8]
/lib64/libc.so.6(setsockopt+0xa)[0x30a1fef1a2a]
/lib64/libc.so.6(setsockopt+0xa)[0x30a1fef1a2a]
/usr/bin/tor(+0xee289)[0x1ac725a289]
/usr/bin/tor(retry_all_listeners+0x322)[0x1ac725bb12]
/usr/bin/tor(set_options+0xa7d)[0x1ac724e58d]
/usr/bin/tor(options_init_from_string+0x32e)[0x1ac725020e]
/usr/bin/tor(options_init_from_torrc+0x1e2)[0x1ac7250562]
/usr/bin/tor(+0x425c9)[0x1ac71ae5c9]
/usr/lib64/libevent-2.1.so.5(+0x2443b)[0x30a20e8043b]
/usr/lib64/libevent-2.1.so.5(event_base_loop+0x56f)[0x30a20e812cf]
/usr/bin/tor(do_main_loop+0x235)[0x1ac71acdd5]
/usr/bin/tor(tor_main+0x1bad)[0x1ac71b04cd]
/usr/bin/tor(main+0x2b)[0x1ac71a83ab]
/lib64/libc.so.6(__libc_start_main+0x114)[0x30a1fe1b734]
/usr/bin/tor(_start+0x29)[0x1ac71a83f9]
```Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20218Fix and refactor and redocument routerstatus_has_changed2020-06-27T13:58:08ZNick MathewsonFix and refactor and redocument routerstatus_has_changedThe routerstatus_has_changed() function is used by controllers to to tell which rs entries are new. But it only looks at a fraction of the fields which might change in a routerstatus. Also, it only checks for semantic changes that tor ...The routerstatus_has_changed() function is used by controllers to to tell which rs entries are new. But it only looks at a fraction of the fields which might change in a routerstatus. Also, it only checks for semantic changes that tor cares about (though this is not documented).Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20127hidden service won't work with local ipv6 address2020-06-27T13:58:12Ztoralfhidden service won't work with local ipv6 addressworks fine:
```
HiddenServicePort 80 127.0.0.1:1234
```
doesn't work:
```
HiddenServicePort 80 [::1]:1234
```
Checked twice with a simple python http server:
https://github.com/toralf/torutils/blob/master/websvc.py
at a stable hardened G...works fine:
```
HiddenServicePort 80 127.0.0.1:1234
```
doesn't work:
```
HiddenServicePort 80 [::1]:1234
```
Checked twice with a simple python http server:
https://github.com/toralf/torutils/blob/master/websvc.py
at a stable hardened Gentoo Linux (host speaks ipv4 and ipv6)Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20072Add chutney's single-onion and single-onion-ipv6 targets to make test-network...2020-06-27T13:58:15ZteorAdd chutney's single-onion and single-onion-ipv6 targets to make test-network-allI'm proposing we add these with legacy/trac#20069 once legacy/trac#17178 is merged to Tor, and legacy/trac#17622 is merged to chutney.I'm proposing we add these with legacy/trac#20069 once legacy/trac#17178 is merged to Tor, and legacy/trac#17622 is merged to chutney.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20071Tor clients need 4 routers when connecting via IPv6, but only 3 using IPv42020-07-27T22:52:56ZteorTor clients need 4 routers when connecting via IPv6, but only 3 using IPv4The minimum number of routers in an IPv4-only Tor network is 3. But when a client is using IPv6, that goes up to 4, with the following log message:
```
Sep 06 13:27:47.000 [info] new_route_len: Not enough acceptable routers (3/4). Discar...The minimum number of routers in an IPv4-only Tor network is 3. But when a client is using IPv6, that goes up to 4, with the following log message:
```
Sep 06 13:27:47.000 [info] new_route_len: Not enough acceptable routers (3/4). Discarding this circuit.
```
Why is one router considered unacceptable? Is this another instance of legacy/trac#19989? (One of these routers is an exit.)
This can be tested using chuntney's client-ipv6-only network.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20070Make address choice failure log message more informative2020-06-27T13:58:15ZteorMake address choice failure log message more informativeLog a more informative message when we fail to find an address for a fallback or authority, because it has a hard-coded IPv6 address, but its descriptor does not have an IPv6 address.Log a more informative message when we fail to find an address for a fallback or authority, because it has a hard-coded IPv6 address, but its descriptor does not have an IPv6 address.Tor: 0.3.0.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19991Tor client slow to bootstrap using ClientUseIPv4 02020-06-27T13:58:20ZteorTor client slow to bootstrap using ClientUseIPv4 0When I run an IPv6-only Tor client using:
```
tor DataDirectory /tmp/tor.$$ SOCKSPort 0 ClientUseIPv4 0 UseMicrodescriptors 0
```
It is sometimes very slow to bootstrap.
I wonder if it's a poor quality IPv6 connection, and perhaps an in...When I run an IPv6-only Tor client using:
```
tor DataDirectory /tmp/tor.$$ SOCKSPort 0 ClientUseIPv4 0 UseMicrodescriptors 0
```
It is sometimes very slow to bootstrap.
I wonder if it's a poor quality IPv6 connection, and perhaps an interaction with the directory re-use feature?Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19990EntryNodes is incompatible with IPv6-only bootstrap2020-06-27T13:58:20ZteorEntryNodes is incompatible with IPv6-only bootstrapWhen UseMicrodescriptors is 1, tor clients which bootstrap over IPv6 have to get descriptors from the fallback directories, because there are no IPv6 addresses in the microdescriptor consensus.
When EntryNodes is set, it excludes all th...When UseMicrodescriptors is 1, tor clients which bootstrap over IPv6 have to get descriptors from the fallback directories, because there are no IPv6 addresses in the microdescriptor consensus.
When EntryNodes is set, it excludes all the fallback directories, meaning that IPv6 clients can't bootstrap.
This can be tested with:
```
src/or/tor DataDirectory /tmp/tor.$$ SOCKSPort 0 EntryNodes x ClientUseIPv4 0
```Tor: 0.3.3.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19760Update longclaw's hard-coded IPv6 address2020-06-27T13:58:32ZteorUpdate longclaw's hard-coded IPv6 addressIn 0.2.8.1-alpha, we added longclaw's IPv6 address as
`ipv6=[2620:13:4000:8000:60:f3ff:fea1:7cff]:443`
https://gitweb.torproject.org/tor.git/tree/src/or/config.c#n931
Now its descriptor says:
`[2620:13:4000:8000:a800:ff:fef5:2213]:443`
...In 0.2.8.1-alpha, we added longclaw's IPv6 address as
`ipv6=[2620:13:4000:8000:60:f3ff:fea1:7cff]:443`
https://gitweb.torproject.org/tor.git/tree/src/or/config.c#n931
Now its descriptor says:
`[2620:13:4000:8000:a800:ff:fef5:2213]:443`
https://atlas.torproject.org/#details/74A910646BCEEFBCD2E874FC1DC997430F968145
Should we update this before the 0.2.8 release?Tor: 0.3.2.x-finalteorteor