Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:35:04Zhttps://gitlab.torproject.org/legacy/trac/-/issues/28698When circuit times are fixed, they can't be "relaxed"2020-06-13T15:35:04ZteorWhen circuit times are fixed, they can't be "relaxed"In #28639, we had trouble diagnosing a sbws bug. tor said that circuit times were "relaxed", even when LearnCircuitBuildTimeout was 0.
When circuit_build_times_disabled() is true, we should change these log messages so that they make se...In #28639, we had trouble diagnosing a sbws bug. tor said that circuit times were "relaxed", even when LearnCircuitBuildTimeout was 0.
When circuit_build_times_disabled() is true, we should change these log messages so that they make sense:
https://github.com/torproject/tor/blob/b058f64cc002b44e6dd48616ca3163a01c3f3e14/src/core/or/circuituse.c#L591
I think relaxed_timeout is meaningless when circuit_build_times_disabled() is true, but that's another issue.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/24703Document IPv6Exit in the sample torrcs2020-06-13T15:19:20ZteorDocument IPv6Exit in the sample torrcsWe could backport this to 0.3.2 if we want to get it in the next release.We could backport this to 0.3.2 if we want to get it in the next release.Tor: 0.3.2.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/23571Stop closing channels out from under OR connections in hibernate_go_dormant()2020-06-13T15:14:07ZteorStop closing channels out from under OR connections in hibernate_go_dormant()This allows dormant connections to flush then close normally.
Bugfix on #7267 in 0.2.4.7-alpha.This allows dormant connections to flush then close normally.
Bugfix on #7267 in 0.2.4.7-alpha.Tor: 0.3.3.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/21499client_dns_incr_failures while passing not hostname but only IP2020-06-13T15:06:28ZTracclient_dns_incr_failures while passing not hostname but only IPI frequently find in logs that while only passing IP to socksport instead of hostname, tor still tell me resolving failed while it shouldn´t have to resolve anything.
Feb 18 15:09:21.000 [info] {APP} client_dns_incr_failures(): Address [...I frequently find in logs that while only passing IP to socksport instead of hostname, tor still tell me resolving failed while it shouldn´t have to resolve anything.
Feb 18 15:09:21.000 [info] {APP} client_dns_incr_failures(): Address [2001:41b8:202:deb:213:21ff:fe20:1426] now has 1 resolve failures.
Feb 18 15:09:22.000 [info] {APP} client_dns_incr_failures(): Address [2001:41b8:202:deb:213:21ff:fe20:1426] now has 2 resolve failures.
Feb 18 15:09:30.000 [info] {APP} client_dns_incr_failures(): Address [2001:41b8:202:deb:213:21ff:fe20:1426] now has 3 resolve failures.
Feb 18 15:09:40.000 [info] {APP} client_dns_incr_failures(): Address [2001:41b8:202:deb:213:21ff:fe20:1426] now has 1 resolve failures.
Feb 18 15:09:40.000 [info] {APP} client_dns_incr_failures(): Address [2001:41b8:202:deb:213:21ff:fe20:1426] now has 2 resolve failures.
Feb 18 15:09:45.000 [info] {APP} client_dns_incr_failures(): Address [2001:41b8:202:deb:213:21ff:fe20:1426] now has 3 resolve failures.
Feb 18 15:09:47.000 [info] {APP} client_dns_incr_failures(): Address [2001:41b8:202:deb:213:21ff:fe20:1426] now has 1 resolve failures.
**Trac**:
**Username**: acceleraTorTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/21357potential bug: Some IPv6Exits do not add the ipv6-policy line to their descri...2020-06-13T15:05:51Zcypherpunkspotential 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.
#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/legacy/trac/-/issues/21310Exits should tell clients when they are connecting to an IPv6-only hostname2020-06-13T15:27:40ZteorExits should tell clients when they are connecting to an IPv6-only hostnameWhen #21311 is finished, we need to make exits tell clients that the hostname they asked for is IPv6-onlyWhen #21311 is finished, we need to make exits tell clients that the hostname they asked for is IPv6-onlyTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/18489Fallback directories don't serve extrainfo descriptors2020-06-13T14:55:04ZDamian JohnsonFallback directories don't serve extrainfo descriptorsGuess not too surprising, but most relays do not fetch extrainfo descriptors and as a result don't provide them when used as a fallback directory. For example...
```
# use Doedel26
% curl http://178.254.20.134:80/tor/extra/fp/9695DFC35F...Guess not too surprising, but most relays do not fetch extrainfo descriptors and as a result don't provide them when used as a fallback directory. For example...
```
# use Doedel26
% curl http://178.254.20.134:80/tor/extra/fp/9695DFC35FFEB861329B9F1AB04C46397020CE31
<no results>
# use moria1
curl http://128.31.0.39:9131/tor/extra/fp/9695DFC35FFEB861329B9F1AB04C46397020CE31
extra-info moria1 9695DFC35FFEB861329B9F1AB04C46397020CE31
published 2016-03-06 10:40:50
write-history 2016-03-06 06:56:34 (14400 s) 25821065216,26561069056,27690179584,25304364032,21429001216,15790654464
read-history 2016-03-06 06:56:34 (14400 s) 3077893120,3154214912,3207265280,3199601664,3018620928,2618984448
... etc...
```
Couple options come to mind...
* Only pick fallbacks that serve extrainfo descriptors.
* Don't use fallbacks when 'DownloadExtraInfo 1' is set.
Of those I suspect we want to opt for the second since few relays probably mirror this information.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17574Fallback mirrors should never fetch from fallback mirrors2020-06-13T14:50:52ZteorFallback mirrors should never fetch from fallback mirrorsIf we allow fallback mirrors to fallback to other fallback mirrors, we could get download loops or other nasty consequences. The bootstrap process should deliver a recent consensus and prevent this, but let's avoid the possibility - ther...If we allow fallback mirrors to fallback to other fallback mirrors, we could get download loops or other nasty consequences. The bootstrap process should deliver a recent consensus and prevent this, but let's avoid the possibility - there's no need for the ~300 fallbacks to use mirrors.
While relays can check their own list of fallback mirrors, there's no way to predict which relays were/are fallbacks in past/future releases.
Therefore, any relays which could possibly become a fallback, must connect to an authority:
* public servers (not a bridge)
* with a dirport (not just an automatic dir cache with the V2Dir flag (#12538), but one with an actual, public, dirport that can be used for initial bootstrapping)
Currently, the authority connection code is advisory, we need to split it and make the above conditions mandatory.
This was introduced in 0.2.4.7-alpha as an unintended consequence of commits like 5c51b3f1f0d4c394392.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/17572router_get_fallback_dirserver_by_digest uses authorities, should use fallbacks2020-06-13T14:50:51Zteorrouter_get_fallback_dirserver_by_digest uses authorities, should use fallbacksrouter_get_fallback_dirserver_by_digest looks like it was copied from router_get_trusteddirserver_by_digest. The comment was changed, but the set of servers searched was not.
router_get_fallback_dirserver_by_digest is only used in conne...router_get_fallback_dirserver_by_digest looks like it was copied from router_get_trusteddirserver_by_digest. The comment was changed, but the set of servers searched was not.
router_get_fallback_dirserver_by_digest is only used in connection_dir_client_reached_eof to record 503 "too busy" messages. The impact of this issue is that only authorities are getting marked as "too busy". Unless a user specifies their own fallbacks, and those fallbacks are busy, they'll never see this issue.
Bug in 5c51b3f1f0d4c394392, released in 0.2.4.7-alpha.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/15775Add IPv4 Fallback Directory List to tor, active by default2020-06-13T14:51:37ZteorAdd IPv4 Fallback Directory List to tor, active by defaultweasel writes on tor-dev:
Tor has included a feature to fetch the initial consensus from nodes
other than the authorities for a while now. We just haven't shipped a
list of alternate locations for clients to go to yet.
Reasons why we ...weasel writes on tor-dev:
Tor has included a feature to fetch the initial consensus from nodes
other than the authorities for a while now. We just haven't shipped a
list of alternate locations for clients to go to yet.
Reasons why we might want to ship tor with a list of additional places
where clients can find the consensus is that it makes authority
reachability and BW less important.
At the last Tor dev meeting we came up with a list of arbitrary
requirements that nodes should meet to be included in this list.
We want them to have been around and using their current key, address,
and port for a while now (120 days), and have been running, a guard, and
a v2 directory mirror for most of that time.
I have written a script to come up with a list of notes that match our
criteria. It's currently at
https://www.palfrader.org/volatile/fallback-dir/get-fallback-dir-candidates
It currently produces
https://www.palfrader.org/volatile/2015-04-17-VjBkc8DWV8c/list
See https://lists.torproject.org/pipermail/tor-dev/2015-April/008674.html
This file current has 329 entries, and takes up approximately 32kB.
If we hard-coded it in the binary like the authorities, it would increase the binary size by approximately 2% on my platform.
Edit: nickm favours putting it in `torrc.defaults`
Edit 2: weasel notes `torrc.defaults` is for package maintainers. Putting it in a list of strings in the code. Much like the authorities.
Do we expect this in by 0.2.7?
Edit: Yes
Do we want to work on a signed file first (#15774)?
(A signed file needs a well-defined threat model and signature verification has to work without access to the authorities or fallback directories.)
Edit: No clear threat model, defer.Tor: 0.2.8.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/15774Signed Fallback Directory File2020-06-13T14:45:31ZteorSigned Fallback Directory FileSee
https://lists.torproject.org/pipermail/tor-dev/2015-April/008682.html
and #15642, in which I say:
The function which loads fallback directories currently loads from a string array inside the function, so it would need to be modi...See
https://lists.torproject.org/pipermail/tor-dev/2015-April/008682.html
and #15642, in which I say:
The function which loads fallback directories currently loads from a string array inside the function, so it would need to be modified to load from a signed file. I support the security benefits of signed fallback directories enough to write client code and unit tests for it, but I'm not sure how the code for the authorities would work - is the proposal to sign a section of the consensus, and output it as a separate file?
If so, we would either need to backport, and/or wait until a majority of the authorities update to tor versions with the feature. And perhaps a majority of clients as well, controlled by a consensus parameter? (Otherwise, using any entry in the file itself would allow clients to effectively be partitioned from the rest of the network by their behaviour.)
While I'm making a list, do we need to modify the existing proposal which describes fallback directories?
Is this change proposed for 0.2.7?
Or all currently supported releases?
Do we need a new configuration option to give the location of the (signed) Fallback Directories file?
How should this interact with the existing FallbackDir option?
Cumulative?
And nickm says:
I think making the file signed is a different ticket, and I don't really understand the threat model for it.
Before we make this change, we need to understand how the threat model is different from, for example:
* a package maintainer adding their own directory
* a package maintainer removing the signature check code
* a package maintainer replacing all the authorities
Also:
How can a signature be verified if the client is using the fallback directories? Doesn't this mean it can't access the directories themselves? So it has to trust the keys it gets from the directories on the not-yet-verified list?Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/15642Disable default fallback directories when DirAuthorities, AlternateDirAuthori...2020-06-13T14:45:15ZteorDisable default fallback directories when DirAuthorities, AlternateDirAuthority, or FallbackDir are setCurrently, when we set `DirAuthorities` or `AlternateDirAuthority`, we don't add the default directory authorities. But, (as long as `FallbackDir` isn't set) we do add the default fallback directories.
It doesn't make sense to me to add...Currently, when we set `DirAuthorities` or `AlternateDirAuthority`, we don't add the default directory authorities. But, (as long as `FallbackDir` isn't set) we do add the default fallback directories.
It doesn't make sense to me to add the default fallback directories when we have custom `DirAuthorities` or `AlternateDirAuthority`. I think we should only add the default fallback directories when other directories are also set to their defaults.
However, the list of default fallback directories is currently `NULL`, so this issue currently has no effect.
I also can't imagine any scenarios where it would be useful to set an `AlternateDirAuthority` or `DirAuthorities`, and still get the default `FallbackDir`.
I can imagine this causing similar issues to #13163, where the default authorities were added to a custom set of authorities in some circumstances.
I'll create a patch to fix this, but it won't actually change tor's observable behaviour until we add directories to the default fallback directory list.
Bugfix on 90f6071d8dc0 in 0.2.4.7-alpha.Tor: 0.2.7.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/8202Combined flash proxy + pyobfsproxy browser bundles XP usabillity.2013-02-11T04:43:10ZTracCombined flash proxy + pyobfsproxy browser bundles XP usabillity.Problem encountered: Windows XP-SP3 Freezing at line [Notice] Parsing GEOIP IPv4 file .\Data\Tor\geoip.
Multiple xp users with the same problem not concurrent on Win 7
Fixed: Windows component not enabled in Add/remove progs - Add/Remo...Problem encountered: Windows XP-SP3 Freezing at line [Notice] Parsing GEOIP IPv4 file .\Data\Tor\geoip.
Multiple xp users with the same problem not concurrent on Win 7
Fixed: Windows component not enabled in Add/remove progs - Add/Remove Windows components. Service necessary, UPnP User Interface under network services. Tick to enable. Not always enabled by default installation.
No noticeable proxy changes detected normal boot speed.
**Trac**:
**Username**: DaringdoDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/8201Combined flash proxy + pyobfsproxy browser bundles XP usabillity.2013-04-25T07:24:50ZTracCombined flash proxy + pyobfsproxy browser bundles XP usabillity.Problem encountered: Windows XP-SP3 Freezing at line [Notice] Parsing GEOIP IPv4 file .\Data\Tor\geoip.
Multiple xp users with the same problem not concurrent on Win 7
Fixed: Windows component not enabled in Add/remove progs - Add/Remo...Problem encountered: Windows XP-SP3 Freezing at line [Notice] Parsing GEOIP IPv4 file .\Data\Tor\geoip.
Multiple xp users with the same problem not concurrent on Win 7
Fixed: Windows component not enabled in Add/remove progs - Add/Remove Windows components. Service necessary, UPnP User Interface under network services. Tick to enable. Not always enabled by default installation.
No noticeable proxy changes detected normal boot speed.
**Trac**:
**Username**: DaringdoDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/7845parse error: Malformed object: missing object end line2020-06-13T14:26:10ZRoger Dingledineparse error: Malformed object: missing object end lineRunning v0.2.4.7-alpha-dev (git-17c24b3118224d65) I got
```
Jan 02 05:16:34.000 [warn] parse error: Malformed object: missing object end line
Jan 02 05:16:34.000 [warn] Unparseable microdescriptor
```
My debug-level logs are only slight...Running v0.2.4.7-alpha-dev (git-17c24b3118224d65) I got
```
Jan 02 05:16:34.000 [warn] parse error: Malformed object: missing object end line
Jan 02 05:16:34.000 [warn] Unparseable microdescriptor
```
My debug-level logs are only slightly more helpful:
```
...
Jan 02 05:16:34.000 [debug] conn_read_callback(): socket -1 wants to read.
Jan 02 05:16:34.000 [debug] fetch_from_buf_http(): headerlen 197, bodylen 9763.
Jan 02 05:16:34.000 [debug] connection_dir_client_reached_eof(): Received response from directory server '94.254.1.254:443': 200 "OK" (purpose: 19)
Jan 02 05:16:34.000 [debug] router_new_address_suggestion(): Got X-Your-Address-Is: 87.213.50.130.
Jan 02 05:16:34.000 [debug] connection_dir_client_reached_eof(): Time on received directory is within tolerance; we are -88 seconds skewed. (That's okay.)
Jan 02 05:16:34.000 [info] connection_dir_client_reached_eof(): Received answer to microdescriptor request (status 200, size 16655) from server '94.254.1.254:443'
Jan 02 05:16:34.000 [warn] parse error: Malformed object: missing object end line
Jan 02 05:16:34.000 [warn] Unparseable microdescriptor
Jan 02 05:16:34.000 [debug] download_status_increment_failure(): r9clvX7cTGes/a70f5pyLkOy6QUOMHMN0hu/0D3mRdw failed 1 time(s); I'll try again immediately.
Jan 02 05:16:34.000 [debug] download_status_increment_failure(): r9gxpWtpN+lvdC+azIzBRV8bKEClpqVOWlb0DMcFfHs failed 1 time(s); I'll try again immediately.
Jan 02 05:16:34.000 [debug] download_status_increment_failure(): r+WKD+7TLtTYCS0P74etXSv+LTQT0KdX3MlIeV9T8r0 failed 1 time(s); I'll try again immediately.
...
```
http://94.254.1.254/ seems to be timing out now, so it's likely this is a problem with the particular dir mirror I picked. But in any case the warn messages should either be more helpful or more quiet.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/7836Incorrect "non-loopback address" warnings2020-06-13T14:26:09ZfkIncorrect "non-loopback address" warningsWhen running Tor in a FreeBSD jail with the IP address 10.0.0.2, a torrc that contains these directives:
TransListenAddress 127.0.0.1
SocksListenAddress 10.0.0.2
ControlListenAddress 127.0.0.1
Results in these messages:
```
Dec 31 11:2...When running Tor in a FreeBSD jail with the IP address 10.0.0.2, a torrc that contains these directives:
TransListenAddress 127.0.0.1
SocksListenAddress 10.0.0.2
ControlListenAddress 127.0.0.1
Results in these messages:
```
Dec 31 11:27:31.879 [notice] Tor v0.2.4.7-alpha (git-e46e1ed1bc50ad24) (with bufferevents) running on FreeBSD with Libevent 2.0.16-stable and OpenSSL 1.0.1c.
Dec 31 11:27:31.880 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Dec 31 11:27:31.880 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Dec 31 11:27:31.880 [notice] Read configuration file "/usr/local/etc/tor/torrc".
Dec 31 11:27:31.893 [notice] You configured a non-loopback address '10.0.0.2:9050' for SocksPort. This allows everybody on your local network to use your machine as a proxy. Make sure this is what you wanted.
Dec 31 11:27:31.893 [notice] You configured a non-loopback address '10.0.0.2:9050' for DNSPort. This allows everybody on your local network to use your machine as a proxy. Make sure this is what you wanted.
Dec 31 11:27:31.893 [notice] You configured a non-loopback address '10.0.0.2:9050' for TransPort. This allows everybody on your local network to use your machine as a proxy. Make sure this is what you wanted.
[...]
Dec 31 11:27:31.895 [notice] You configured a non-loopback address '10.0.0.2:9050' for SocksPort. This allows everybody on your local network to use your machine as a proxy. Make sure this is what you wanted.
Dec 31 11:27:31.895 [notice] You configured a non-loopback address '10.0.0.2:9050' for DNSPort. This allows everybody on your local network to use your machine as a proxy. Make sure this is what you wanted.
Dec 31 11:27:31.895 [notice] You configured a non-loopback address '10.0.0.2:9050' for TransPort. This allows everybody on your local network to use your machine as a proxy. Make sure this is what you wanted.
Dec 31 11:27:31.895 [notice] Opening Socks listener on 10.0.0.2:9050
Dec 31 11:27:31.896 [notice] Opening DNS listener on 127.0.0.1:53
Dec 31 11:27:31.896 [notice] Opening Transparent pf/netfilter listener on 127.0.0.1:9040
Dec 31 11:27:31.896 [notice] Opening Control listener on 127.0.0.1:9051
Dec 31 11:27:31.896 [notice] Opening Control listener on /var/run/tor/tor-socket
```
The fact that some messages are shown twice is #4019, this report is about the incorrect warnings for the listeners on 127.0.0.1. It looks like the Socks address 10.0.0.2:9050 is used for all complaints.
With a torrc that contains these directives:
TransListenAddress 127.0.0.1
SocksListenAddress 127.0.0.1
ControlListenAddress 127.0.0.1
No warnings are shown, even though the risk (in the described FreeBSD jail) is equivalent.
```
Dec 31 12:19:17.414 [notice] Tor v0.2.4.7-alpha (git-e46e1ed1bc50ad24) (with bufferevents) running on FreeBSD with Libevent 2.0.16-stable and OpenSSL 1.0.1c.
Dec 31 12:19:17.415 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Dec 31 12:19:17.415 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Dec 31 12:19:17.415 [notice] Read configuration file "/usr/local/etc/tor/torrc".
[...]
Dec 31 12:19:17.431 [notice] Opening Socks listener on 127.0.0.1:9050
Dec 31 12:19:17.431 [notice] Opening DNS listener on 127.0.0.1:53
Dec 31 12:19:17.431 [notice] Opening Transparent pf/netfilter listener on 127.0.0.1:9040
Dec 31 12:19:17.431 [notice] Opening Control listener on 127.0.0.1:9051
Dec 31 12:19:17.431 [notice] Opening Control listener on /var/run/tor/tor-socket
```Tor: 0.2.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/7814Segfault with exit on 0.2.4.7-alpha2020-06-13T14:26:05ZNick MathewsonSegfault with exit on 0.2.4.7-alphaAndrea encountered this while testing #7743
```
#0 0x0000000000539321 in tor_strlower (s=0x0) at src/common/util.c:517
#1 0x00000000004d56c4 in connection_exit_begin_conn (cell=0x7fffffffde30,
circ=0x1bec960)
at src/or/connecti...Andrea encountered this while testing #7743
```
#0 0x0000000000539321 in tor_strlower (s=0x0) at src/common/util.c:517
#1 0x00000000004d56c4 in connection_exit_begin_conn (cell=0x7fffffffde30,
circ=0x1bec960)
at src/or/connection_edge.c:2482
#2 0x0000000000429143 in connection_edge_process_relay_cell
(cell=0x7fffffffde30, circ=0x1bec960, conn=0x0,
layer_hint=0x0) at src/or/relay.c:1190
#3 0x0000000000425e66 in circuit_receive_relay_cell (cell=0x7fffffffde30,
circ=0x1bec960,
cell_direction=CELL_DIRECTION_OUT) at src/or/relay.c:193
#4 0x00000000004b00a9 in command_process_relay_cell (cell=0x7fffffffde30,
chan=0x1d9c0e0) at src/or/command.c:407
#5 0x00000000004af32d in command_process_cell (chan=0x1d9c0e0,
cell=0x7fffffffde30) at src/or/command.c:147
#6 0x0000000000485fac in channel_queue_cell (chan=0x1d9c0e0,
cell=0x7fffffffde30) at src/or/channel.c:2516
#7 0x000000000048cb48 in channel_tls_handle_cell (cell=0x7fffffffde30,
conn=0x22fc5e0) at src/or/channeltls.c:921
#8 0x00000000004db608 in connection_or_process_cells_from_inbuf
(conn=0x22fc5e0) at src/or/connection_or.c:1937
#9 0x00000000004d80a6 in connection_or_process_inbuf (conn=0x22fc5e0) at
src/or/connection_or.c:461
#10 0x00000000004cbba9 in connection_process_inbuf (conn=0x22fc5e0,
package_partial=1) at src/or/connection.c:3954
#11 0x00000000004c95c9 in connection_handle_read_impl (conn=0x22fc5e0) at
src/or/connection.c:2819
#12 0x00000000004c96f4 in connection_handle_read (conn=0x22fc5e0) at
src/or/connection.c:2860
#13 0x000000000040a26f in conn_read_callback (fd=22, event=2,
_conn=0x22fc5e0) at src/or/main.c:722
#14 0x00007ffff772f930 in event_process_active (base=0x7e4c70,
flags=<value optimized out>) at event.c:395
#15 event_base_loop (base=0x7e4c70, flags=<value optimized out>) at
event.c:547
#16 0x000000000040cc77 in do_main_loop () at src/or/main.c:1989
#17 0x000000000040e237 in tor_main (argc=3, argv=0x7fffffffe658) at
src/or/main.c:2701
#18 0x0000000000408844 in main (argc=3, argv=0x7fffffffe658) at
src/or/tor_main.c:30
```Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/7799Tor seems to build+timeout circuits for hours when offline/idle2020-06-13T14:26:01ZTracTor seems to build+timeout circuits for hours when offline/idleSince I've upgraded to .7-alpha I am having my log file filled with the above message, which is generated a couple of times a *second*!
\
I have, so far, accumulated over 14,000 lines with this crap, which seems to be generated when tor ...Since I've upgraded to .7-alpha I am having my log file filled with the above message, which is generated a couple of times a *second*!
\
I have, so far, accumulated over 14,000 lines with this crap, which seems to be generated when tor was left idle (unused) overnight. I had to increase my log level (to "warn") in order to get rid of it temporarily, but that isn't good enough, since I cannot see my other (very useful) messages appearing at that level (notice) without having my log filled rapidly.
Here's the logline from the original bug title:
"No circuits are opened. Relaxed timeout for a circuit with channel state open to 60000ms. However, it appears the circuit has timed out anyway. 0 guards are live."
**Trac**:
**Username**: mr-4Tor: 0.2.4.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/7797tor DNS resolver unable to handle/return SRV type DNS records2020-06-13T16:09:00ZTractor DNS resolver unable to handle/return SRV type DNS recordsTor's internal DNS resolver is incapable of looking up SRV (service type) DNS records.
SRV-type DNS records have the following format: _service._protocol.name (like "_sip._udp.ekiga.net" for example). The "output" I am getting from tor...Tor's internal DNS resolver is incapable of looking up SRV (service type) DNS records.
SRV-type DNS records have the following format: _service._protocol.name (like "_sip._udp.ekiga.net" for example). The "output" I am getting from tor is as follows (127.0.0.1 refers to tor's internal DNS server):
# dig @127.0.0.1 _sip._udp.ekiga.net SRV
; <<>> DiG 9.7.3-P1-RedHat-9.7.3-2.P1.fc18 <<>> @127.0.0.1 _sip._udp.ekiga.net SRV
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOTIMP, id: 29790
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;_sip._udp.ekiga.net. IN SRV
;; Query time: 2 msec
;; SERVER: 127.0.0.1 # 53(127.0.0.1)
;; WHEN: Wed Dec 26 00:45:05 2012
;; MSG SIZE rcvd: 37
Note the "status" above as NOTIMP (Not Implemented). The correct output, using a "proper" DNS server (marked as xxx.xxx.xxx.xxx below) is as follows:
# dig @xxx.xxx.xxx.xxx _sip._udp.ekiga.net SRV
; <<>> DiG 9.7.3-P1-RedHat-9.7.3-2.P1.fc18 <<>> @xxx.xxx.xxx.xxx _sip._udp.ekiga.net SRV
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65507
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; QUESTION SECTION:
;_sip._udp.ekiga.net. IN SRV
;; ANSWER SECTION:
_sip._udp.ekiga.net. 86400 IN SRV 0 0 5060 ekiga.net.
;; ADDITIONAL SECTION:
ekiga.net. 85881 IN A 86.64.162.35
;; Query time: 24 msec
;; SERVER: xxx.xxx.xxx.xxx # 53(xxx.xxx.xxx.xxx)
;; WHEN: Wed Dec 26 00:48:01 2012
;; MSG SIZE rcvd: 82
As evident, the "status" returned is NOERROR (No Error).
**Trac**:
**Username**: mr-4Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/7646fix/enhance getinfo ns/id/* commands2020-06-13T14:25:23ZTracfix/enhance getinfo ns/id/* commands1. Fix getinfo ns/id/*
See the last few comments on #7059 with regards to the ns/id/* getinfo command.
Currently, it only returns information about tor nodes which have microdescriptors and ignores those that use "normal" descriptors, i...1. Fix getinfo ns/id/*
See the last few comments on #7059 with regards to the ns/id/* getinfo command.
Currently, it only returns information about tor nodes which have microdescriptors and ignores those that use "normal" descriptors, in other words, it behaves exactly like the md/id/node command.
I can understand the rationale behind having desc/id/node to only show information about tor nodes with "normal" descriptors and I can understand the reasons for md/id/node to do the same for tor nodes with microdescriptors, but ns/id/node should, in my view, be implemented in such a way to return information about all tor nodes, regardless of whether or not they use microdescriptors, particularly so because by definition of this command in control-specs.txt it is supposed to return V2 directory info on all nodes without making such distinctions.
2. Enhance ns/* - just an idea (not a bug!): currently, there is no way I could get information on a tor node by specifying its ip address.
I would love to be able to get that information by executing something like "getinfo ns/ip/<ip_address>" (note the "ip" in the middle!). This should return information on all tor nodes with the specified ip address (and/or netmask), regardless of whether they use microdescriptors or not.
**Trac**:
**Username**: mr-4Tor: unspecified