Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T17:37:18Zhttps://gitlab.torproject.org/legacy/trac/-/issues/20171Tell 0.2.8 fallback directory operators that their relays are on the list2020-06-13T17:37:18ZteorTell 0.2.8 fallback directory operators that their relays are on the listThank them, and remind them to keep their relay details the same.
I am hoping the community team can help me out with this, if I provide a list.Thank them, and remind them to keep their relay details the same.
I am hoping the community team can help me out with this, if I provide a list.https://gitlab.torproject.org/legacy/trac/-/issues/20170Backport latest fallback list to 0.2.8 and 0.2.92020-06-13T16:05:43ZteorBackport latest fallback list to 0.2.8 and 0.2.9I'm generating a new list of fallback directory mirrors for release 0.2.9 in #18828.
We have a few options for dealing with the 0.2.8 list:
* comment-out any broken fallbacks,
* backport the 0.2.9 list,
* do nothing.
I would prefer to ...I'm generating a new list of fallback directory mirrors for release 0.2.9 in #18828.
We have a few options for dealing with the 0.2.8 list:
* comment-out any broken fallbacks,
* backport the 0.2.9 list,
* do nothing.
I would prefer to have the same src/or/fallback_dirs.inc in every (relevant) Tor release, assuming we do another 0.2.8 series release.
This is consistent with how we handle directory authorities and geoip.
Otherwise it becomes hard to check multiple fallback lists at once.
But I could be convinced to go with either of the other options.Tor: 0.2.8.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/20010modifications of relay(s) on fallback whitelist2020-06-13T16:05:42ZTracmodifications of relay(s) on fallback whitelist```
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hello teor,
I currently have two relays in the fallback whitelist (niij01 230A8B2A8BA861210D9B4BA97745AEC217A94207 and niij02 0B85617241252517E8ECF2CFC7F4C1A32DCD153F). I have some u...```
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hello teor,
I currently have two relays in the fallback whitelist (niij01 230A8B2A8BA861210D9B4BA97745AEC217A94207 and niij02 0B85617241252517E8ECF2CFC7F4C1A32DCD153F). I have some updates/questions:
1. I have added IPv6 addresses for these two relays, is there anything I need to do to update them on the fallback list?
2. I have another fast, stable relay in the family of these 2 relays, that can be added (niij03 A9406A006D6E7B5DA30F2C6D4E42A338B5E340B2) to the fallback.
3. Do the IP addresses for these relays need to remain the same indefinitely? I was thinking of changing hosts (fingerprint would remain the same), but if changing the IP addresses causes issues, I will keep them on their current host.
Thanks, niij
-----BEGIN PGP SIGNATURE-----
wsFcBAEBCAAQBQJXwzUpCRAdSJS4jbcqPQAAsTAQAKs7K1exZHkf8Jyj/sLDBjo+
ZuBTulOQi+PxCstUNZgbOE3xN+LyerrBDBqFLy0znrwj1VK5TgKJi6+EawaJQFWh
qS/Mly8VujsighUdx94vrfxU2AKnvBIQ4oU72+tzXsp7Hsdscr3sG5DOMWTdWNKi
DvK/ccaeCsCkuAsU7UAJ55DtOhtHiJ9fHGMtJYipTXKB/gLUeo8rz5BUyJTGOCOJ
fTWqp1rw+Xbgvo+jPLl8YTsgijA+BMxurCgYng+90VH4P6weZGQFWIn7CQ55ANmO
kRfcw/sSRKXJTYAw6jCNe8eUC8eq1EhfGpbSZoa7KaV7l8UtpEsx7/splUnDtWj6
6KQF9tk+k3YR/2D1oeYfDcyDSJAMXIRH/NLRg7H06vuuoZEQm/Q5lSoZ8whGZbAN
HnKxb66ZNc/RMQ0DgLl1Gs42OMQCLcBsP0I6PFx429TgxnGfnceWpJgEqN0Q9kGy
rJ2J4jBy9kW70Sh813focmVlK3TkkejUcLYoWFz57siqipGY3nsBgtLETHpULEtl
SAhQCs6XjJ9LlRLmXplSj8ftmdTiwvyLKOukbxkrqdEiyDAxS0C9zdSCCfujrqR/
WEyEzbc9hom/Xms2FwCcZ5dFCDbf3CiD722bPbavhGH/6TgAyDzAlqOa2PA1heEr
BDFkOQzVrIyIbnzuoL7S
=0wQz
-----END PGP SIGNATURE-----
```
**Trac**:
**Username**: niijTor: 0.2.9.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/19989Tor fails to bootstrap with an Exit as EntryNode2020-06-13T15:00:41ZteorTor 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 (#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/legacy/trac/-/issues/19810Could high-bandwidth ORPort-only relays be fallbacks?2020-06-13T14:59:52ZteorCould 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/legacy/trac/-/issues/19480Avoid errors during fallback selection when there are no fallbacks2020-06-13T16:05:41ZteorAvoid errors during fallback selection when there are no fallbacksThis issue is fixed as part of #19071, I just needed a bug number.This issue is fixed as part of #19071, I just needed a bug number.Tor: 0.2.8.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/18812[warn] Tried connecting to router at 81.7.17.171:443, but identity key was no...2020-06-13T14:56:22ZRoger 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/legacy/trac/-/issues/18084Use the same fallback directory mirror to bootstrap2020-06-13T14:53:28ZteorUse 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].Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/7798Use directory guards even when consensus isn't live2020-06-13T16:05:41ZNick 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.Tor: unspecified