Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-06-27T13:57:08Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/21506Client with current microdesc consensus but no descriptors chooses down fallb...2020-06-27T13:57:08ZteorClient with current microdesc consensus but no descriptors chooses down fallback every timeTor 0.2.9.9 doesn't have the fix for a similar issue in legacy/trac#20996, but 0.3.0.2-alpha does.
But this issue is different from that issue: the client downloads the consensus, then tries the same fallback (a down fallback) every tim...Tor 0.2.9.9 doesn't have the fix for a similar issue in legacy/trac#20996, but 0.3.0.2-alpha does.
But this issue is different from that issue: the client downloads the consensus, then tries the same fallback (a down fallback) every time.
This really shouldn't happen: the client should choose a different relay every time.
My guess is that this relay is chosen because it's down, and all the up relay descriptors are unavailable. This is pathological behaviour.
I think we fixed it in 0.3.0.2-alpha with the patch to legacy/trac#20996, but I'm logging this bug just in case.
http://pastebin.ca/3769463Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/21283Remove broken fallback directory mirrors2020-06-27T13:57:19ZteorRemove broken fallback directory mirrorsSome time around 0.3.0.?-rc, we should remove all non-functional fallback directories from the December 2016 list (or rebuild the entire list).
I'll create a draft branch here, but the script should be re-run just before the release (an...Some time around 0.3.0.?-rc, we should remove all non-functional fallback directories from the December 2016 list (or rebuild the entire list).
I'll create a draft branch here, but the script should be re-run just before the release (and ideally, operators should be contacted and given an opportunity to fix any errors).Tor: 0.3.2.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/20908Display the fingerprint when downloading consensuses from fallbacks2020-06-27T13:57:39ZteorDisplay the fingerprint when downloading consensuses from fallbacksJust using this for the bug number, will be fixed in legacy/trac#18828.Just using this for the bug number, will be fixed in legacy/trac#18828.Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20194Add "update fallbacks" to "Preliminaries" in Tor's doc/HACKING/ReleasingTor.md2021-07-22T16:23:16ZteorAdd "update fallbacks" to "Preliminaries" in Tor's doc/HACKING/ReleasingTor.mdWhen we added fallback directory mirrors, we should have also listed them as something we need to update every major release:
2. Early in the alpha series for each new major release, at least a month before the code freeze, update th...When we added fallback directory mirrors, we should have also listed them as something we need to update every major release:
2. Early in the alpha series for each new major release, at least a month before the code freeze, update the list of fallback directory mirrors using the instructions in: https://trac.torproject.org/projects/tor/wiki/doc/UpdatingFallbackDirectoryMirrorsTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20172Fallback Tasks for 20162020-06-27T13:58:10ZteorFallback Tasks for 2016This is the top-level task for fallback directory mirror tickets in 2016, typically in 0.2.8 or 0.2.9.This is the top-level task for fallback directory mirror tickets in 2016, typically in 0.2.8 or 0.2.9.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19989Tor fails to bootstrap with an Exit as EntryNode2020-07-27T19:41:51ZteorTor fails to bootstrap with an Exit as EntryNodeWhen I try to run tor with EntryNodes x (where x is a single Exit relay), it hangs at:
```
Aug 26 00:51:57.000 [notice] Bootstrapped 45%: Asking for relay descriptors
Aug 26 00:51:57.000 [notice] I learned some more directory informatio...When I try to run tor with EntryNodes x (where x is a single Exit relay), it hangs at:
```
Aug 26 00:51:57.000 [notice] Bootstrapped 45%: Asking for relay descriptors
Aug 26 00:51:57.000 [notice] I learned some more directory information, but not enough to build a circuit: We need more microdescriptors: we have 0/6973, and can only build 0% of likely paths. (We have 0% of guards bw, 0% of midpoint bw, and 0% of exit bw = 0% of path bw.)
Aug 26 00:51:58.000 [notice] Bootstrapped 50%: Loading relay descriptors
```
~~This issue might prevent us from switching to one guard in future releases.~~
This issue likely makes Exits useless as fallback directories for IPv6-only microdescriptor clients (legacy/trac#19608).
I can reproduce this issue on 0.2.9.2-alpha-dev, 0.2.8.{6,7}, maint-0.2.7, maint-0.2.6 using the following command:
```
src/or/tor DataDirectory /tmp/tor.$$ SOCKSPort 0 EntryNodes x
```Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19810Could high-bandwidth ORPort-only relays be fallbacks?2020-06-27T13:58:30ZteorCould high-bandwidth ORPort-only relays be fallbacks?In 0.2.8, relays automatically support begindir over ORPort, even if they don't have a DirPort.
I wonder if we're missing out on (m)any high-bandwidth relays by excluding relays without a DirPort. That said, we wouldn't want too many, b...In 0.2.8, relays automatically support begindir over ORPort, even if they don't have a DirPort.
I wonder if we're missing out on (m)any high-bandwidth relays by excluding relays without a DirPort. That said, we wouldn't want too many, because relays still use the DirPort to bootstrap off fallbacks. (But if the fallback only has an ORPort, the relay will use that.)
We'd need to make the following changes for this to happen:
* modify the DirPort requirement during fallback selection to check for either a DirPort, or declared begindir support in the descriptor
* make a DirPort optional for configured FallbackDirs in Tor
* this may be as simple as setting the DirPort to 0, and disabling the validation. The rest of the code might just work, because it ignores 0 DirPorts
* test, test, testTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19782Remove a fallback directory in 0.2.82020-06-27T13:58:31ZteorRemove a fallback directory in 0.2.8An operator just told me they are taking down their fallback directory. So I need to comment it out in the 0.2.8 fallback_dirs.inc file, and move it from the whitelist to the blacklist.
The fingerprint is 08DC0F3C6E3D9C527C1FC8745D35DD1...An operator just told me they are taking down their fallback directory. So I need to comment it out in the 0.2.8 fallback_dirs.inc file, and move it from the whitelist to the blacklist.
The fingerprint is 08DC0F3C6E3D9C527C1FC8745D35DD1B0DE1875D.Tor: 0.2.8.x-finalhttps://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/18812[warn] Tried connecting to router at 81.7.17.171:443, but identity key was no...2020-06-27T13:59:14ZRoger Dingledine[warn] Tried connecting to router at 81.7.17.171:443, but identity key was not as expected: wanted 00C4B4731658D3B4987132A3F77100CFCB190D97 but got CFECDDCA990E3EF7B7EC958B22441386B6B8D820.I'm running git master, but I think this applies to Tor 0.2.8.2-alpha. On bootstrap, I got
```
[...]
Apr 13 03:17:50.542 [notice] I learned some more directory information, but not enough to build a circuit: We have no usable consensus.
...I'm running git master, but I think this applies to Tor 0.2.8.2-alpha. On bootstrap, I got
```
[...]
Apr 13 03:17:50.542 [notice] I learned some more directory information, but not enough to build a circuit: We have no usable consensus.
Apr 13 03:17:50.620 [warn] Tried connecting to router at 81.7.17.171:443, but identity key was not as expected: wanted 00C4B4731658D3B4987132A3F77100CFCB190D97 but got CFECDDCA990E3EF7B7EC958B22441386B6B8D820.
Apr 13 03:17:52.147 [notice] Bootstrapped 40%: Loading authority key certs
[...]
```
So I think everything is going according to plan (cool, I even used a fallback dir!), except my fallback dir seems to have changed its key since it went into fallback_dirs.inc.
Maybe it isn't so reliably stable after all? :) :/
I wonder if we should consider a) doing periodic full checks of the fallback relays, to catch issues like this one preemptively, and then b) making the warning less scary for normal users.Tor: 0.2.8.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18481Allow the fallback directory schedules to be changed outside a test network2021-09-16T14:34:12ZteorAllow the fallback directory schedules to be changed outside a test networkIn legacy/trac#4483, I made the additional schedules TestingTorNetwork. But, if it turns out they need tuning, we want to be able to change them in the default torrc in a Tor Browser release.
So they need to be turned into non-testing t...In legacy/trac#4483, I made the additional schedules TestingTorNetwork. But, if it turns out they need tuning, we want to be able to change them in the default torrc in a Tor Browser release.
So they need to be turned into non-testing torrc options, and the testing values moved to the common chutney template.
This also involves carefully sanity checking any user-supplied values to these options.https://gitlab.torproject.org/tpo/core/tor/-/issues/18084Use the same fallback directory mirror to bootstrap2022-06-17T14:30:58ZteorUse the same fallback directory mirror to bootstrapIf Tor always tries to use the same fallback directory mirror to bootstrap (when the consensus expires because Tor isn't used), fewer servers learn about Tor clients, and a Tor client is less likely to download from a bad fallback direct...If Tor always tries to use the same fallback directory mirror to bootstrap (when the consensus expires because Tor isn't used), fewer servers learn about Tor clients, and a Tor client is less likely to download from a bad fallback directory mirror.
This is low priority, as most Tor clients only bootstrap once [citation needed].https://gitlab.torproject.org/tpo/core/tor/-/issues/7798Use directory guards even when consensus isn't live2021-06-18T18:21:27ZNick MathewsonUse directory guards even when consensus isn't liveOur initial directory guard implementation only works when we have a live consensus to find out the directory guards' IP addresses. So it's an improvement, but it's hardly a perfect solution.
We should instead remember our guards' IP a...Our initial directory guard implementation only works when we have a live consensus to find out the directory guards' IP addresses. So it's an improvement, but it's hardly a perfect solution.
We should instead remember our guards' IP addresses in our state file, and try to use our directory guards even when we don't have a consensus. This will require consideration about handling our guards being down and handling the network being down.