Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T16:05:45Zhttps://gitlab.torproject.org/legacy/trac/-/issues/20175Allow the fallback script to ignore temporary IPv6 addresses2020-06-13T16:05:45ZteorAllow the fallback script to ignore temporary IPv6 addressesWhen updateFallbackDirs.py checks relay addresses, it makes sure that the IPv4 and IPv6 addresses and ports match the relay's whitelist entry.
If a relay's IPv6 address is temporary, it should not be included in the whitelist.
But this...When updateFallbackDirs.py checks relay addresses, it makes sure that the IPv4 and IPv6 addresses and ports match the relay's whitelist entry.
If a relay's IPv6 address is temporary, it should not be included in the whitelist.
But this means the relay will never be selected, because its descriptor has an IPv6 address, and that address doesn't match the (missing) address in the whitelist.
We should add a way to say ipv6=ignored or something.Tor: unspecifiedhaxxpophaxxpophttps://gitlab.torproject.org/legacy/trac/-/issues/20174Automate checking existing fallbacks2020-06-13T16:05:45ZteorAutomate checking existing fallbacksI use a manual process to check existing fallbacks. It would be great if the updateFallbackDirs.py script would automatically read src/or/fallback_dirs.inc, and check each fallback for errors.
For details, see:
https://trac.torproject.o...I use a manual process to check existing fallbacks. It would be great if the updateFallbackDirs.py script would automatically read src/or/fallback_dirs.inc, and check each fallback for errors.
For details, see:
https://trac.torproject.org/projects/tor/wiki/doc/UpdatingFallbackDirectoryMirrors
I think it can go in 0.3.0Tor: 0.3.0.x-finalhaxxpophaxxpophttps://gitlab.torproject.org/legacy/trac/-/issues/20070Make address choice failure log message more informative2020-06-13T15:01:07ZteorMake 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/legacy/trac/-/issues/19991Tor client slow to bootstrap using ClientUseIPv4 02020-06-13T15:00:42ZteorTor 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/legacy/trac/-/issues/19990EntryNodes is incompatible with IPv6-only bootstrap2020-06-13T15:00:41ZteorEntryNodes 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/legacy/trac/-/issues/19947NULL %s in fmt string (dir_server_new() - routerlist.c)2020-06-13T15:00:23ZTracNULL %s in fmt string (dir_server_new() - routerlist.c)in src/or/routerlist.c:4545-4550 `hostname` passed to tor_asprintf() can be NULL such as when dir_server_new() is called from fallback_dir_server_new()
Found this because recent OpenBSD -current whinges about it in syslog:
tor: vfp...in src/or/routerlist.c:4545-4550 `hostname` passed to tor_asprintf() can be NULL such as when dir_server_new() is called from fallback_dir_server_new()
Found this because recent OpenBSD -current whinges about it in syslog:
tor: vfprintf %s NULL in "directory server at %s:%d"
last message repeated 88 times
**Trac**:
**Username**: rubiateTor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/19639Make sure extend_info_from_router is only called on servers2020-06-13T14:59:23ZteorMake sure extend_info_from_router is only called on serversCurrently, extend_info_from_router is only called for a relay's ORPort self-checks. Let's make sure it stays that way.Currently, extend_info_from_router is only called for a relay's ORPort self-checks. Let's make sure it stays that way.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/19136Crushed on Windows10 (Tor 0.2.8.1-alpha 9093e3769746742f)2020-06-13T14:57:41ZTracCrushed on Windows10 (Tor 0.2.8.1-alpha 9093e3769746742f)[周五 5月 20 14:08:28 2016] Tor软件错误 - Tor 软件遇到了一个内部错误。请将下列错误信息通过 bugs.torproject.org 发送给 Tor 的开发者:“circuit_package_relay_cell(): Bug: outgoing relay cell sent from ../src/or/relay.c:706 has n_chan==NULL. Dropping. (on Tor 0.2.8.1-alpha 9093...[周五 5月 20 14:08:28 2016] Tor软件错误 - Tor 软件遇到了一个内部错误。请将下列错误信息通过 bugs.torproject.org 发送给 Tor 的开发者:“circuit_package_relay_cell(): Bug: outgoing relay cell sent from ../src/or/relay.c:706 has n_chan==NULL. Dropping. (on Tor 0.2.8.1-alpha 9093e3769746742f)
”
**Trac**:
**Username**: user33331111https://gitlab.torproject.org/legacy/trac/-/issues/19074Mark fallback directories down when their key is wrong2020-06-13T14:57:31ZteorMark fallback directories down when their key is wrongarma says that we will happily retry fallback directories with the wrong key fingerprint. We can do two things to fix this:
* mark fallback directories as down when their key fingerprint is wrong
* cancel all pending connections to a fal...arma says that we will happily retry fallback directories with the wrong key fingerprint. We can do two things to fix this:
* mark fallback directories as down when their key fingerprint is wrong
* cancel all pending connections to a fallback with the wrong key (perhaps in #18809) - this should be unlikely with 100 fallbacksTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/19028Merge the header checks in configure.ac2020-06-13T14:57:17ZcypherpunksMerge the header checks in configure.acThe build configuration contains [two sets of header checks](https://gitweb.torproject.org/tor.git/tree/configure.ac#n945) where one checks headers that are deemed essential and one checks headers that are not. The only difference being ...The build configuration contains [two sets of header checks](https://gitweb.torproject.org/tor.git/tree/configure.ac#n945) where one checks headers that are deemed essential and one checks headers that are not. The only difference being that missing essential headers display a non-fatal warning when they aren't found.
For the following reasons i think it is better to merge the sets and discard the warning.
- Commit [e8cc839e41adc4975a61fee62abe7f6664fd0c0e](https://gitweb.torproject.org/tor.git/commit/?id=e8cc839e41adc4975a61fee62abe7f6664fd0c0e) adds `sys/capability.h` to the essential header set but Tor runs fine without capabilities being available. IMO it is in the wrong set.
- Having two sets requires developers to make a choice whether headers are essential or not. Instead developers should write code that handles cases where the headers are unavailable (like the capabilities code).
- The current warning is truncated because its message is incorrectly quoted. This means the part about sending the `orconfig.h` file isn't shown and has been ineffective.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/18963Download authority certificates even under blackholed authorities or fallbacks2020-06-13T14:59:06ZteorDownload authority certificates even under blackholed authorities or fallbacksOur fix for #18816 is still not great if a significant number of fallbacks are blocked or blackholed.
There are a few options to deal with this:
* do what we do with the consensus, and try multiple, simultaneous connections to both autho...Our fix for #18816 is still not great if a significant number of fallbacks are blocked or blackholed.
There are a few options to deal with this:
* do what we do with the consensus, and try multiple, simultaneous connections to both authorities and fallback directories, use the first one that succeeds, and close the rest,
* if the connection to a fallback fails, try an authority (this still doesn't help with blackholed fallbacks),
* or any of the other options arma mentions in #18816:
> Longer term (0.2.9 and later), I think we should explore a) having directory_get_from_dirserver() notice that there are tls conns established to dir mirrors that we just recently used (and prefer them), or b) trying to explicitly remember the dir mirror that gave us the consensus and re-use it, and/or c) designing a piggy-back mechanism so we can ask for "the certs that go with this consensus" when we're fetching a consensus and we know we will want the certs for it too (thus saving a round-trip).Tor: 0.2.9.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/18929Fix selection of directories with non-preferred address families2020-06-13T14:56:51ZteorFix selection of directories with non-preferred address familiesIn #17840 in 0.2.8.1-alpha, we sometimes fail to fall back to directories with addresses in non-preferred IP families:
* we didn't identify relays that we could fall back to correctly;
* we incorrectly assumed that every node would have ...In #17840 in 0.2.8.1-alpha, we sometimes fail to fall back to directories with addresses in non-preferred IP families:
* we didn't identify relays that we could fall back to correctly;
* we incorrectly assumed that every node would have an IPv4 address~~ - this doesn't apply to bridges~~;
* we counted relays when we had already fallen back to non-preferred addresses.
This likely affected ~~bridge clients with IPv4 bridges, and~~ clients in small networks.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/18921Fix IPv6 bridge client directory address selection2020-06-13T14:56:50ZteorFix IPv6 bridge client directory address selectionAfter #17840 in 0.2.8.1-alpha, we incorrectly chose an IPv4 address for all DIRIND_ONEHOP directory connections, even if the routerstatus didn't have an IPv4 address.
This likely affected bridge clients with IPv6 bridges.After #17840 in 0.2.8.1-alpha, we incorrectly chose an IPv4 address for all DIRIND_ONEHOP directory connections, even if the routerstatus didn't have an IPv4 address.
This likely affected bridge clients with IPv6 bridges.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/18918Clarify directory and ORPort checking functions2020-06-13T14:56:48ZteorClarify directory and ORPort checking functionsThe OR and dir checking functions in router.c are somewhat confusing. We could document them better, or modify their names, or restructure.
In #18616, we added:
* decide_to_advertise_begindir
We already had:
* check_whether_orport_reac...The OR and dir checking functions in router.c are somewhat confusing. We could document them better, or modify their names, or restructure.
In #18616, we added:
* decide_to_advertise_begindir
We already had:
* check_whether_orport_reachable
* check_whether_dirport_reachable
* router_has_bandwidth_to_be_dirserver
* router_should_be_directory_server
* dir_server_mode
* decide_to_advertise_dirport
* consider_testing_reachabilityTor: 0.3.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/18852Directory mirrors should check accounting usage more frequently2020-06-13T14:56:34ZteorDirectory mirrors should check accounting usage more frequentlyAfter merging #12538 and #18616, Tor can wait up to 18 hours before checking whether the accounting usage has increase so much that we want to stop advertising DirPort and begindir support.
This is not great for relays with daily accoun...After merging #12538 and #18616, Tor can wait up to 18 hours before checking whether the accounting usage has increase so much that we want to stop advertising DirPort and begindir support.
This is not great for relays with daily accounting periods.
I suggest we check every hour to see whether the result of router_should_be_directory_server() has changed. If so, we should mark_my_descriptor_dirty() with an appropriate message about deciding to advertise or stop advertising directory service support / DirPort.
This likely also means separating the calculation part of router_should_be_directory_server() from the logging, otherwise we will log duplicate messages each time we change our minds about our accounting.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/18849Fix router_picked_poor_directory_log() before 0.2.8 release2020-06-13T14:56:32ZteorFix router_picked_poor_directory_log() before 0.2.8 releaseUsers and developers still report log messages like this:
`router_picked_poor_directory_log(): Bug: Firewall denied all OR and Dir addresses for all relays when searching for a directory. (on Tor 0.2.8.1-alpha-dev 9093e3769746742f)`
Aft...Users and developers still report log messages like this:
`router_picked_poor_directory_log(): Bug: Firewall denied all OR and Dir addresses for all relays when searching for a directory. (on Tor 0.2.8.1-alpha-dev 9093e3769746742f)`
After #18616 is fixed, we need to work out whether these logs still occur, and whether they are genuine bugs that affect reachability, or spurious warnings that should be eliminated.Tor: 0.2.8.x-finalAndrea ShepardAndrea Shepardhttps://gitlab.torproject.org/legacy/trac/-/issues/18816We still wait 120 seconds for cert fetches from missing dir mirrors2020-06-13T14:56:24ZRoger DingledineWe still wait 120 seconds for cert fetches from missing dir mirrorsIn #4483 and prop210 we set up an elaborate download schedule for consistently reaching fallbackdirs when fetching the consensus, so we don't end up just sitting there for 120 seconds while a tcp connection waits (and eventually the Sock...In #4483 and prop210 we set up an elaborate download schedule for consistently reaching fallbackdirs when fetching the consensus, so we don't end up just sitting there for 120 seconds while a tcp connection waits (and eventually the SocksTimeout parameter is reached and we move on).
But we didn't do any similar thing with fetching the key certs. I just had my bootstrap go smoothly through the #4483 features (with the fixes from #18809) and then it stalled for 2 minutes trying to fetch the certs from a fallbackdir that's offline.
Sure enough, in authority_certs_fetch_missing() I see
```
/* XXX - do we want certs from authorities or mirrors? - teor */
directory_get_from_dirserver(DIR_PURPOSE_FETCH_CERTIFICATE, 0,
resource, PDS_RETRY_IF_NO_SERVERS,
DL_WANT_ANY_DIRSERVER);
```
So teor noticed this one too.
I think in 0.2.8, if we leave the fallbackdir stuff in (meaning we merge #18809 or equivalent into 0.2.8), we could bandage this one by changing DL_WANT_ANY_DIRSERVER to DL_WANT_AUTHORITY, and then it wouldn't be much worse than it is now (in terms of performance -- we would indeed lose the ability to bootstrap from scratch when the authorities are unavailable).
Longer term (0.2.9 and later), I think we should explore a) having directory_get_from_dirserver() notice that there are tls conns established to dir mirrors that we just recently used (and prefer them), or b) trying to explicitly remember the dir mirror that gave us the consensus and re-use it, and/or c) designing a piggy-back mechanism so we can ask for "the certs that go with this consensus" when we're fetching a consensus and we know we will want the certs for it too (thus saving a round-trip).Tor: 0.2.8.x-finalhttps://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/18809Handle linked connections better during bootstrap2020-06-13T14:57:32ZteorHandle linked connections better during bootstrapbegindir connections advance directly to the CLIENT_SENDING state, even before their TLS connection is created.
So we need to modify the logic from #4483 that checks for consensuses that are downloading:
* is it a direct connection in s...begindir connections advance directly to the CLIENT_SENDING state, even before their TLS connection is created.
So we need to modify the logic from #4483 that checks for consensuses that are downloading:
* is it a direct connection in state after connecting, or
* a linked connection that's attached, or
* a linked connection that's in a state after sending
And then do the standard "extra consensus download check" when we're about to link a directory connection to a TLS connection.
Or arma may have a better idea.
I am not sure whether we should fix this in 0.2.8, because the current code works, but it's not optimal when too many TLS connections hang.
Tagging it just in case.Tor: 0.2.8.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/18808Check if connection is excess in connection_dir_finished_flushing2020-06-13T14:56:19ZteorCheck if connection is excess in connection_dir_finished_flushingIn #4483, I added a check like the one below to every transition from DIR_CONN_STATE_CONNECTING to another state, but I missed connection_dir_finished_flushing:
```
/* Close this connection if there's another consensus connectio...In #4483, I added a check like the one below to every transition from DIR_CONN_STATE_CONNECTING to another state, but I missed connection_dir_finished_flushing:
```
/* Close this connection if there's another consensus connection
* downloading (during bootstrap), or connecting (after bootstrap). */
if (connection_dir_close_consensus_conn_if_extra(conn)) {
return;
}
```
It would be good to to fix this in 0.2.8, because otherwise clients could end up requesting multiple consensuses, which is expensive for relays and for the network.Tor: 0.2.8.x-finalteorteor