Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-06-27T13:57:33Zhttps://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-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19610IPv6-only clients fetch microdescriptors from a small number of IPv6 fallbacks2020-11-04T14:18:56ZteorIPv6-only clients fetch microdescriptors from a small number of IPv6 fallbacksWhen an IPv6-only client bootstraps using microdescriptors (legacy/trac#19608), it fetches the microdescriptor consensus from an IPv6 fallback, but the microdescriptor consensus has no IPv6 addresses.
So it falls back to the fallback di...When an IPv6-only client bootstraps using microdescriptors (legacy/trac#19608), it fetches the microdescriptor consensus from an IPv6 fallback, but the microdescriptor consensus has no IPv6 addresses.
So it falls back to the fallback directories, fetching ~7500/500 = 15 sets of descriptors from 15 of the 25 IPv6 fallbacks.
We should improve this behaviour somehow, to avoid overloading the fallbacks. One simple way of doing this is selecting 200 fallbacks for 0.2.9 in legacy/trac#18828.
It's worth noting that this extra load only happens on bootstrap, when there are no cached microdescriptors. If an IPv6-only client has any IPv6 microdescriptors that match the current consensus, it will use those relays instead.Tor: 0.3.3.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19608IPv6-only clients can't fetch microdescriptors on 0.2.8.5-rc2020-06-27T13:58:37ZteorIPv6-only clients can't fetch microdescriptors on 0.2.8.5-rcThere's a lovely catch-22 when IPv6-only clients try to fetch microdescriptors:
* some fallback directories are on IPv6, and deliver the microdescriptor consensus
* but the microdescriptor consensus doesn't contain any IPv6 addresses
* b...There's a lovely catch-22 when IPv6-only clients try to fetch microdescriptors:
* some fallback directories are on IPv6, and deliver the microdescriptor consensus
* but the microdescriptor consensus doesn't contain any IPv6 addresses
* but it's a consensus, so IPv6-only clients try to use it to find an IPv6 relay, and fail
A solution is to teach IPv6-only clients to get (at least some of) their descriptors from the fallback directories, at least until they have some IPv6 microdescriptors. Perhaps this should happen automatically when the entire consensus fails, but for some reason it doesn't.
I have no idea how we didn't catch this during testing - perhaps there were always cached descriptors? Perhaps we broke falling back to the fallbacks for descriptors?Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19487Meek and ReachableAddresses2022-09-19T21:17:44ZcypherpunksMeek and ReachableAddressesThis came to my attention through an old StackExchange ticket that the Community accound had bumped: http://tor.stackexchange.com/q/9500
The user appears to have setup some combination of `ReachableAddresses`,`FirewallPorts`, and `Fasci...This came to my attention through an old StackExchange ticket that the Community accound had bumped: http://tor.stackexchange.com/q/9500
The user appears to have setup some combination of `ReachableAddresses`,`FirewallPorts`, and `FascistFirewall`. While the ports they can reach might be set correctly, when using `meek` `tor` sees the destination address as a fake destination. You end up with a log that looks like this:
```
NOTICE: Bridge at '0.0.2.0:1' isn't reachable by our firewall policy. Skipping.
```
This happens because they haven't defined `0.0.2.0:1` as being a reachable address, while in reality it's using (most likely) port 443 on some CDN, which might actually be defined reachable.
Maybe not a common issue but an interesting edge case that may be clarified, avoided, or documented somewhere.https://gitlab.torproject.org/tpo/core/tor/-/issues/18674Tor rejects [::]/8 and [::]/127 explicitly, but the latter is sometimes elimi...2020-07-27T19:10:04ZSebastian HahnTor rejects [::]/8 and [::]/127 explicitly, but the latter is sometimes eliminatedI suspect the rules that try to eliminate duplicates are at play here. I figured this out while trying to add tests for some getinfo exit-policy queries.I suspect the rules that try to eliminate duplicates are at play here. I figured this out while trying to add tests for some getinfo exit-policy queries.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18652ipv6 listener only, ipv4 source addresses2020-06-27T13:59:20ZTracipv6 listener only, ipv4 source addresses[notice] Opening OR listener on [::]:0
[notice] OR listener listening on port 38153.
[notice] Guessed our IP address as 42.42.42.42 (source: 154.35.175.225).
If my listening "port" is IPv6, the ip address guessed should be the IPv6 one,...[notice] Opening OR listener on [::]:0
[notice] OR listener listening on port 38153.
[notice] Guessed our IP address as 42.42.42.42 (source: 154.35.175.225).
If my listening "port" is IPv6, the ip address guessed should be the IPv6 one, if available.
Practically, if the address family of the listen port should be used as the address family of the outgoing socket that detects the local addess.
**Trac**:
**Username**: chadmillerhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18394Allow relays to have an IPv6 DirPort on the same port as the IPv4 DirPort2020-06-27T13:59:31ZteorAllow relays to have an IPv6 DirPort on the same port as the IPv4 DirPortCurrently, to do this, relay operators need to say `DirPort [IPv6-address]:80 NoAdvertise`, or they get a warning "Can't advertise more than one DirPort."
This supports clients on IPv6 in 0.2.8.Currently, to do this, relay operators need to say `DirPort [IPv6-address]:80 NoAdvertise`, or they get a warning "Can't advertise more than one DirPort."
This supports clients on IPv6 in 0.2.8.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18387Allow Listening on :: for IPv62020-06-27T13:59:31ZTracAllow Listening on :: for IPv6Running tor-win32-0.2.7.6, SocksPort and ORPort do not allow binding to "::1" for "all IPv6 interfaces". They do allow binding to "0.0.0.0" for "all IPv4 interfaces" though. This ticket is a feature request to allow binding to "::1" for ...Running tor-win32-0.2.7.6, SocksPort and ORPort do not allow binding to "::1" for "all IPv6 interfaces". They do allow binding to "0.0.0.0" for "all IPv4 interfaces" though. This ticket is a feature request to allow binding to "::1" for "all IPv6 interfaces" in torrc.
**Trac**:
**Username**: DJXTor: 0.2.9.x-final