Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:28:44Zhttps://gitlab.torproject.org/legacy/trac/-/issues/8716HashedControlPassword Doesn't Seem To Do Anything2020-06-13T14:28:44ZcypherpunksHashedControlPassword Doesn't Seem To Do AnythingAfter setting HashedControlPassword, I'm able to connect to the control port without being prompted for my password. Further, I can actually manually change the hash (for example, I can change the last few characters all to 'F'), and arm...After setting HashedControlPassword, I'm able to connect to the control port without being prompted for my password. Further, I can actually manually change the hash (for example, I can change the last few characters all to 'F'), and arm is still able to connect without prompting me. I've attached my torrc with the nickname and contact info removed.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/8711authorities should say on their flag-threshold lines in their vote whether th...2020-06-13T14:28:43ZRoger Dingledineauthorities should say on their flag-threshold lines in their vote whether they have enough Measured lines that they're counting non-Measured relays as 0 bandwidthauthorities should say on their flag-threshold lines in their vote whether they have enough Measured lines that they're counting non-Measured relays as 0 bandwidth
that will help karsten to track and explain changes over timeauthorities should say on their flag-threshold lines in their vote whether they have enough Measured lines that they're counting non-Measured relays as 0 bandwidth
that will help karsten to track and explain changes over timeTor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/8701Stem doesn't recognize error 555 on attach_stream2020-06-13T14:28:42ZcypherpunksStem doesn't recognize error 555 on attach_streamWhen trying to attach a stream that is not controlled by the controller using Controller.attach_stream, Tor will reply with error 555. Stem does not recognize this and will throw a generic exception:
```
stem.ProtocolError: ATTACHSTREAM...When trying to attach a stream that is not controlled by the controller using Controller.attach_stream, Tor will reply with error 555. Stem does not recognize this and will throw a generic exception:
```
stem.ProtocolError: ATTACHSTREAM returned unexpected response code: 555
```
I think an InvalidArguments exception would be best suited for this error code.
```
@@ -1981,6 +1981,8 @@ class Controller(BaseController):
raise stem.InvalidRequest(response.code, response.message)
elif response.code == '551':
raise stem.OperationFailed(response.code, response.message)
+ elif response.code == '555':
+ raise stem.InvalidArguments(response.code, response.message)
else:
raise stem.ProtocolError("ATTACHSTREAM returned unexpected response code: %s" % response.code)
```Tor: 0.2.4.x-finalDamian JohnsonDamian Johnsonhttps://gitlab.torproject.org/legacy/trac/-/issues/8700Tor attaches streams to newly created circuits even with __LeaveStreamsUnatta...2020-06-13T14:28:41ZcypherpunksTor attaches streams to newly created circuits even with __LeaveStreamsUnattached=1When Tor created a new circuit it checks for streams that are not attached yet and attaches them to the new circuit. This is normally fine, but it should not be done when !__LeaveStreamsUnattached is set to 1.When Tor created a new circuit it checks for streams that are not attached yet and attaches them to the new circuit. This is normally fine, but it should not be done when !__LeaveStreamsUnattached is set to 1.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/8685Document how authorities choose relay status flags2020-06-13T14:28:41ZRoger DingledineDocument how authorities choose relay status flags#8273 and #8435 are confusing in part because we don't know what they're trying to do. We should decide what they ought to do (starting I guess with deciding with what we think they did), and document that in dir-spec (or somewhere else ...#8273 and #8435 are confusing in part because we don't know what they're trying to do. We should decide what they ought to do (starting I guess with deciding with what we think they did), and document that in dir-spec (or somewhere else that's appropriate). That way when we find something weird looking, there's a way to decide whether it's a bug.
In an ideal world, in retrospect, this topic probably could have used a short proposal.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/8683moria1 isn't voting for Fast flag when it should2020-06-13T16:20:53ZRoger Dingledinemoria1 isn't voting for Fast flag when it shouldmoria1 running master (and thus #8273 and #8435) is voting weirdly about its flags -- particularly Fast and Exit.
For example, this one really ought to get Fast:
```
r Ferrari458 ABwTs6Vacbl3ymXshVOdecZTo/w r5fmkGFLqpZj8tHabjbPP5IidFo 2...moria1 running master (and thus #8273 and #8435) is voting weirdly about its flags -- particularly Fast and Exit.
For example, this one really ought to get Fast:
```
r Ferrari458 ABwTs6Vacbl3ymXshVOdecZTo/w r5fmkGFLqpZj8tHabjbPP5IidFo 2013-04-11 03:37:00 68.38.171.200 9001 9030
s HSDir Running V2Dir Valid
v Tor 0.2.3.25
w Bandwidth=605 Measured=1120
p reject 1-65535
m 8,9,10,11,12,13,14,15,16,17 sha256=oRdjVNraRMF9pWQJzl8UxZdfNBoHSWF0GlYWailMsBU
```
And this one really ought to get Exit:
```
r sumkledi ABPSI4nNUNC3hKPkBhyzHozozrU S6rBWKQIhhXr/+EVxRX/DT9AB8I 2013-04-11 04:01:46 178.218.213.229 80 0
s Running Valid
v Tor 0.2.2.35
w Bandwidth=51 Measured=20
p accept 80,443
m 8,9,10,11,12,13,14,15,16,17 sha256=9K0eJJ5HKhiAianDAkw+0Zs8WFIUDE9D6p/VY3w0WOE
```Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/8680CPU 100% - conn_write_callback(): socket # wants to write.2020-06-13T14:28:39ZTracCPU 100% - conn_write_callback(): socket # wants to write.Running as a relay on Debian Wheezy x86_64, installed from tor repository.
This is difficult to describe, and I'm not 100% certain I know how to reproduce it... It seems to reproduce itself. After an indeterminate amount of time, the C...Running as a relay on Debian Wheezy x86_64, installed from tor repository.
This is difficult to describe, and I'm not 100% certain I know how to reproduce it... It seems to reproduce itself. After an indeterminate amount of time, the CPU usage for tor goes to 100% and stays there until I restart the service. This is a fairly low bandwidth relay (128 KB/s), and even when very busy the CPU usage is usually 3%. The most recent time this happened, I stumbled upon the "SIGNAL DEBUG" command, which I passed to tor via arm. The result was *millions of lines* of the following:
```
Apr 10 17:59:25.000 [debug] conn_write_callback(): socket 124 wants to write.
Apr 10 17:59:25.000 [debug] connection_read_to_buf(): 124: starting, inbuf_datalen 0 (0 pending in tls object). at_most 15872.
Apr 10 17:59:25.000 [debug] tor_tls_read(): read returned r=-1, err=-2
Apr 10 17:59:25.000 [debug] connection_read_to_buf(): After TLS read of 0: 0 read, 0 written
Apr 10 17:59:25.000 [debug] connection_or_process_cells_from_inbuf(): 124: starting, inbuf_datalen 0 (0 pending in tls object).
Apr 10 17:59:25.000 [debug] conn_write_callback(): socket 124 wants to write.
Apr 10 17:59:25.000 [debug] connection_read_to_buf(): 124: starting, inbuf_datalen 0 (0 pending in tls object). at_most 15872.
Apr 10 17:59:25.000 [debug] tor_tls_read(): read returned r=-1, err=-2
Apr 10 17:59:25.000 [debug] connection_read_to_buf(): After TLS read of 0: 0 read, 0 written
Apr 10 17:59:25.000 [debug] connection_or_process_cells_from_inbuf(): 124: starting, inbuf_datalen 0 (0 pending in tls object).
```
Those lines were repeated _identically_, adding 75,000 lines _per second_ to the log.
Other information:
* The relay also runs a bitcoin server as a hidden service.
* Tor is configured to to listen for socks connections on the local network.
Before running "SIGNAL DEBUG", I:
* Turned off the bitcoin server. CPU remained at 100% for the tor process.
* Disabled the hidden service in torrc, and gave SIGHUP. CPU remained at 100% for the tor process.
* Disabled any device on the local network that could be accessing tor via socks. CPU remained at 100% for the tor process.
I'm not sure what other information I can provide... Let me know what else you need to help track this down.
**Trac**:
**Username**: alphawolfTor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/8639Controller: Stream event source field is "<unknown address type>:1" for DNS r...2020-06-13T14:28:34ZTracController: Stream event source field is "<unknown address type>:1" for DNS requests from the controllerMy patch #8203 tried to be clever and copied the IP and port of the control connection into the SOURCE field of STREAM_EVENT_NEW_RESOLVE events. As it turns out, the control connection address can be a unix domain socket, which tor_dup_a...My patch #8203 tried to be clever and copied the IP and port of the control connection into the SOURCE field of STREAM_EVENT_NEW_RESOLVE events. As it turns out, the control connection address can be a unix domain socket, which tor_dup_addr helpfully converts to "<unknown address type>".
From the control Spec
```
Address = ip4-address / ip6-address / hostname (XXXX Define these)
(...)
"650" SP "STREAM" SP StreamID SP StreamStatus SP CircuitID SP Target
[SP "REASON=" Reason [ SP "REMOTE_REASON=" Reason ]]
[SP "SOURCE=" Source] [ SP "SOURCE_ADDR=" Address ":" Port ]
[SP "PURPOSE=" Purpose]
CRLF
```
Previously "(Tor_internal):0" was used, even though it also did not follow the control spec, but the controllers seemed to handle it fine.
My suggestion: If the control connection is via a unix domain socket, use "(Tor_internal)" again. And while we are at it, add (Tor_internal) to the control spec as well.
**Trac**:
**Username**: DesoxyTor: 0.2.4.x-finalAndrea ShepardAndrea Shepardhttps://gitlab.torproject.org/legacy/trac/-/issues/8638mkdir fails in test suite2020-06-13T14:28:33Zweasel (Peter Palfrader)mkdir fails in test suiteOur ci has failed twice already in the test suite with this error:
```
13:00:02 dir/measured_bw: [forking] File exists
13:00:03 Can't create directory C:\Users\jenkins\\tor_test_3572:
13:00:03 [measured_bw FAILED]
```
drwx------+ 1 j...Our ci has failed twice already in the test suite with this error:
```
13:00:02 dir/measured_bw: [forking] File exists
13:00:03 Can't create directory C:\Users\jenkins\\tor_test_3572:
13:00:03 [measured_bw FAILED]
```
drwx------+ 1 jenkins None 0 Apr 3 15:20 /c/Users/jenkins/tor_test_3572
Not sure what exactly is going on there. This is the only tor_test_%d directory in the user profile dir, and it has an mtime of a day earlier.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/8599PathsNeededToBuildCircuits option is broken2020-06-13T14:28:32ZKarsten LoesingPathsNeededToBuildCircuits option is brokenThe PathsNeededToBuildCircuits config option added in 02c32091 can be set to a value between 0.25 and 0.95, but that value is only used in nodelist.c if it's >= 1.0 which should probably be >= 0.0. Also, the check for too high values (>...The PathsNeededToBuildCircuits config option added in 02c32091 can be set to a value between 0.25 and 0.95, but that value is only used in nodelist.c if it's >= 1.0 which should probably be >= 0.0. Also, the check for too high values (> 0.95) is broken, setting all valid values to 0.95. See [branch paths-needed-option in my public repo](https://gitweb.torproject.org/karsten/tor.git/shortlog/refs/heads/paths-needed-option). Not adding a ChangeLog entry, because this bug is not in a released version, AFAIK.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/8598clang warning in circuitbuild.c switch statement2020-06-13T14:28:31ZNick Mathewsonclang warning in circuitbuild.c switch statementIn maint-0.2.4, building with clang 3.2 on fedora, I get:
```
src/or/circuitbuild.c:1946:11: error: enumeration values 'PATH_STATE_NEW_CIRC',
'PATH_STATE_BUILD_ATTEMPTED', and 'PATH_STATE_ALREADY_COUNTED' not
explicitly hand...In maint-0.2.4, building with clang 3.2 on fedora, I get:
```
src/or/circuitbuild.c:1946:11: error: enumeration values 'PATH_STATE_NEW_CIRC',
'PATH_STATE_BUILD_ATTEMPTED', and 'PATH_STATE_ALREADY_COUNTED' not
explicitly handled in switch [-Werror,-Wswitch-enum]
switch (ocirc->path_state) {
```
I have a fix for this; just adding this ticket so I can give it a bug number.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/8596Inconsistent addrmap events when resolving hostname (regression)2020-06-13T14:28:31ZTracInconsistent addrmap events when resolving hostname (regression)Tor 0.2.3.x would generate an ADDRMAP event for all addresses added to the cache, and since all resolved IPv4 addresses were added to the cache, all IPv4 addresses generated an ADDRMAP event. Ticket #7570 introduced circuit-based separat...Tor 0.2.3.x would generate an ADDRMAP event for all addresses added to the cache, and since all resolved IPv4 addresses were added to the cache, all IPv4 addresses generated an ADDRMAP event. Ticket #7570 introduced circuit-based separation of the DNS cache and "broke" that mechanism: Resolves generated via the DNSPort or a control connection do not end up in the cache and thus don't generate an ADDRMAP event. Also, when the cache is disabled by adding the `SocksPort 9050 NoCacheDNS` to the torrc, no ADDRMAP event is generated.
Git-bisect shows commit 7536c40e9641a0724f0c9e6f994306d762d37e4d[1] introduced this problem.
First, we should be clear about when to generate ADDRMAP events. From the control spec:
```
4.1.7. New Address mapping
These events are generated when a new address mapping is entered in
Tor's address map cache, or when the answer for a RESOLVE command is
found.
```
This would mean that DNS data retrieved for DNSPort queries or when NoCacheDNS is set would not trigger an event. Do we want this behavior? Or do we want to trigger ADDRMAP events for any mapping that is not already in the cache, even if it is not going to be cached anyway?
1: https://gitweb.torproject.org/tor.git/commitdiff/7536c40e9641a0724f0c9e6f994306d762d37e4d?hp=f33487668f16dbd7f95eaf8644865c28e1dd7036
**Trac**:
**Username**: DesoxyTor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/8590Clarification on the Use of Fingerprints in the MyFamily Option in the torrc ...2020-06-13T14:28:29ZPatrick McDonaldClarification on the Use of Fingerprints in the MyFamily Option in the torrc Man PageThe torrc man page states fingerprints or nicks may be used for the MyFamily option. While nicknames are valid, fingerprints are more reliable and the man page should reflect this.
Per discussion with nickm on IRC, I will supply a patch...The torrc man page states fingerprints or nicks may be used for the MyFamily option. While nicknames are valid, fingerprints are more reliable and the man page should reflect this.
Per discussion with nickm on IRC, I will supply a patch which provides this clarification.Tor: 0.2.4.x-finalPatrick McDonaldPatrick McDonaldhttps://gitlab.torproject.org/legacy/trac/-/issues/8587Test for curve25519-donna-c64 usability is borken.2020-06-13T14:36:00ZNick MathewsonTest for curve25519-donna-c64 usability is borken.In #8753, weasel discovered that under some circumstances, we're building curve25519-donna-c64 on 32-bit operating systems. It looks like our order-of-operations is busted in the testing code for whether 128-bit int ops work, and we had...In #8753, weasel discovered that under some circumstances, we're building curve25519-donna-c64 on 32-bit operating systems. It looks like our order-of-operations is busted in the testing code for whether 128-bit int ops work, and we hadn't noticed because our return-status boolean was inverted.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/8580Internal Error,Tor Guard Success Rates VERY high2020-06-13T14:28:28ZTracInternal Error,Tor Guard Success Rates VERY high[Sat Mar 23 18:06:09 2013] Tor Software Error - The Tor software encountered an internal bug. Please report the following error message to the Tor developers at bugs.torproject.org: "pathbias_count_build_success(): Bug: Unexpectedly high...[Sat Mar 23 18:06:09 2013] Tor Software Error - The Tor software encountered an internal bug. Please report the following error message to the Tor developers at bugs.torproject.org: "pathbias_count_build_success(): Bug: Unexpectedly high successes counts (255.375000/236.375000) for guard ndnr1=6330CCF8FEED2EF9B12FCF6688E2577C65522BA4
"
**Trac**:
**Username**: branefreezTor: 0.2.4.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/8573master build warning on i386 with clang2020-06-13T14:28:27Zweasel (Peter Palfrader)master build warning on i386 with clangThere are a couple of implicit off64_T to size_t conversions like this:
```
15:33:07 clang -DHAVE_CONFIG_H -I. -I./src/ext -Isrc/ext -I./src/common -Isrc/common -I./src/or -Isrc/or -DSHARE_DATADIR="\"/usr/local/share\"" -DLOCALSTATEDIR...There are a couple of implicit off64_T to size_t conversions like this:
```
15:33:07 clang -DHAVE_CONFIG_H -I. -I./src/ext -Isrc/ext -I./src/common -Isrc/common -I./src/or -Isrc/or -DSHARE_DATADIR="\"/usr/local/share\"" -DLOCALSTATEDIR="\"/usr/local/var\"" -DBINDIR="\"/usr/local/bin\"" -I./src/common -g -O2 -D_FORTIFY_SOURCE=2 -Qunused-arguments -fstack-protector-all -Wstack-protector -fwrapv --param ssp-buffer-size=1 -fPIE -Wall -fno-strict-aliasing -W -Wfloat-equal -Wundef -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings -Wredundant-decls -Wchar-subscripts -Wcomment -Wformat=2 -Wwrite-strings -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wbad-function-cast -Wswitch-enum -Werror -Winit-self -Wmissing-field-initializers -Wdeclaration-after-statement -Wold-style-definition -Waddress -Wmissing-noreturn -Wstrict-overflow=1 -Wshorten-64-to-32 -MT src/common/crypto_curve25519.o -MD -MP -MF $depbase.Tpo -c -o src/common/crypto_curve25519.o src/common/crypto_curve25519.c &&\
15:33:07 mv -f $depbase.Tpo $depbase.Po
15:33:07 src/common/crypto_curve25519.c:172:28: error: implicit conversion loses integer precision: '__off64_t' (aka 'long long') to 'size_t' (aka 'unsigned int') [-Werror,-Wshorten-64-to-32]
15:33:07 memwipe(content, 0, st.st_size);
15:33:07 ~~~~~~~ ~~~^~~~~~~
15:33:07 1 error generated.
```
Full log is currently at https://jenkins.torproject.org/job/tor-ci-linux-clang/ARCHITECTURE=i386/1/console but that link might not be too stable yet.Tor: 0.2.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/8561Enable ntor protocol by default.2020-06-13T14:28:25ZNick MathewsonEnable ntor protocol by default.It works for me, after all. Why not set the parameter to 1 in the consensuses, and to 1 in the configurations for 0.2.5?It works for me, after all. Why not set the parameter to 1 in the consensuses, and to 1 in the configurations for 0.2.5?Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/8553get_net_param_from_list(): Bug: src/or/networkstatus.c:2192: get_net_param_fr...2020-06-13T14:28:24ZTracget_net_param_from_list(): Bug: src/or/networkstatus.c:2192: get_net_param_from_list: Assertion min_val <= default_val failed;Maybe there was something going wrong between commits 6e94d2fb3a11d7cb and 7c2eabcf8e68aee1 :
```
[...] [notice] Tor 0.2.5.0-alpha-dev (git-7c2eabcf8e68aee1) opening log file.
[...] [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip...Maybe there was something going wrong between commits 6e94d2fb3a11d7cb and 7c2eabcf8e68aee1 :
```
[...] [notice] Tor 0.2.5.0-alpha-dev (git-7c2eabcf8e68aee1) opening log file.
[...] [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
[...] [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
[...] [notice] This version of Tor (0.2.5.0-alpha-dev) is newer than any recommended version, according to the directory authorities. Recommended versions are: 0.2.2.39,0.2.3.24-rc,0.2.3.25,0.2.4.5-alpha,0.2.4.6-alpha,0.2.4.7-alpha,0.2.4.8-alpha,0.2.4.9-alpha,0.2.4.10-alpha,0.2.4.11-alpha
[...] [notice] We now have enough directory information to build circuits.
[...] [notice] Bootstrapped 80%: Connecting to the Tor network.
[...] [err] get_net_param_from_list(): Bug: src/or/networkstatus.c:2192: get_net_param_from_list: Assertion min_val <= default_val failed; aborting.
```
```
[...] [notice] Tor 0.2.5.0-alpha-dev (git-6e94d2fb3a11d7cb) opening log file.
[...] [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
[...] [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
[...] [notice] This version of Tor (0.2.5.0-alpha-dev) is newer than any recommended version, according to the directory authorities. Recommended versions are: 0.2.2.39,0.2.3.24-rc,0.2.3.25,0.2.4.5-alpha,0.2.4.6-alpha,0.2.4.7-alpha,0.2.4.8-alpha,0.2.4.9-alpha,0.2.4.10-alpha,0.2.4.11-alpha
[...] [notice] We now have enough directory information to build circuits.
[...] [notice] Bootstrapped 80%: Connecting to the Tor network.
[...] [notice] Bootstrapped 85%: Finishing handshake with first hop.
[...] [notice] Bootstrapped 90%: Establishing a Tor circuit.
[...] [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
[...] [notice] Bootstrapped 100%: Done.
```
**Trac**:
**Username**: tornewbieTor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/8508Tor clients won't build paths on testing tor network with no guards or exits2020-06-13T14:28:18ZNick MathewsonTor clients won't build paths on testing tor network with no guards or exitsStarting in 0.2.4.10-alpha, with our changes to the minimal requirements for building circuits, clients never consider themselves to be ready to build paths if they're running on a testing tor network without bandwidth info.
Instead the...Starting in 0.2.4.10-alpha, with our changes to the minimal requirements for building circuits, clients never consider themselves to be ready to build paths if they're running on a testing tor network without bandwidth info.
Instead they say:
```
Mar 18 12:00:21.000 [notice] I learned some more directory information, but not enough to build a circuit: We need more descriptors: we have 8/8, and can only build 0% of likely paths. (We have 0% of guards bw, 100% of midpoint bw, and 0% of exit bw.)
```
Found with Chutney.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/8477connection_ap_expire_beginning(): Bug: circuit->purpose == CIRCUIT_PURPOSE_C_...2020-06-13T14:28:15Zcypherpunksconnection_ap_expire_beginning(): Bug: circuit->purpose == CIRCUIT_PURPOSE_C_GENERAL failed. The purpose on the circuit was UNKNOWN_20- Tor 0.2.5.0-alpha-dev (git-331e4dcb460b5c91) used as client only and configured to use bridges :
```
[warn] connection_ap_expire_beginning(): Bug: circuit->purpose == CIRCUIT_PURPOSE_C_GENERAL failed. The purpose on the circuit was U...- Tor 0.2.5.0-alpha-dev (git-331e4dcb460b5c91) used as client only and configured to use bridges :
```
[warn] connection_ap_expire_beginning(): Bug: circuit->purpose == CIRCUIT_PURPOSE_C_GENERAL failed. The purpose on the circuit was UNKNOWN_20; it was in state open, path_state use attempted.
[warn] connection_ap_expire_beginning(): Bug: circuit->purpose == CIRCUIT_PURPOSE_C_GENERAL failed. The purpose on the circuit was UNKNOWN_20; it was in state open, path_state use attempted.
```Tor: 0.2.4.x-finalMike PerryMike Perry