The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T14:10:03Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/902It appears there is a bug in the intersection of the bandwidthrate and accoun...2020-06-27T14:10:03ZTracIt appears there is a bug in the intersection of the bandwidthrate and accountingmaxIt appears there is a bug in the intersection of the bandwidthrate and
accountingmax when set to ridiculously high levels (999 TB).
But perhaps also at lower settings (9 GB).
Jan 05 19:10:54.773 [notice] Configured hibernation. This ...It appears there is a bug in the intersection of the bandwidthrate and
accountingmax when set to ridiculously high levels (999 TB).
But perhaps also at lower settings (9 GB).
Jan 05 19:10:54.773 [notice] Configured hibernation. This interval began at 2009-01-05 12:21:00; the scheduled
wake-up time was 2009-01-05 12:21:00; we expect to exhaust our quota for this interval around 2009-01-06 12:21:00;
the next interval begins at 2009-01-06 12:21:00 (all times local)
Jan 05 19:12:10.984 [notice] Received reload signal (hup). Reloading config.
Jan 05 19:12:10.988 [notice] Tor 0.2.0.32 (r17346) opening log file.
AccountingStart day 12:21
AccountingMax 5 GB
BandwidthRate 20000
BandwidthBurst 21000
`Low traffic` is the result
20000*3600*24 is less than 5 GB?
[Automatically added by flyspray2trac: Operating System: Fedora Core Linux]
**Trac**:
**Username**: udohttps://gitlab.torproject.org/tpo/core/tor/-/issues/903Crash when runnig as Service2020-06-27T14:10:03ZTracCrash when runnig as ServiceWhen used as a service it terminates unexpectantly with either error 1064 or 1067 without any warning.
This happends as the service tries to start, everytime.
Torrc found here : http://pastebin.com/f514929fb
When run as a regular progr...When used as a service it terminates unexpectantly with either error 1064 or 1067 without any warning.
This happends as the service tries to start, everytime.
Torrc found here : http://pastebin.com/f514929fb
When run as a regular program it doesn't get any errors.
The regular program and service uses the same torrc.
OS: win XP.
memory : 1GB
no other errors are registerd at or near the time the service stops.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: zerakhttps://gitlab.torproject.org/tpo/core/tor/-/issues/904When we fail to decrypt an onionskin, we never reply2020-06-27T14:10:03ZRoger DingledineWhen we fail to decrypt an onionskin, we never replyOn my bridge:
Jan 06 13:06:06.447 [debug] router_set_status(): Marking router 'moria1/128.31.0
.34' as up.
Jan 06 13:06:06.447 [debug] circuit_n_conn_done(): or_conn to moria1/128.31.0.34
, status=1
Jan 06 13:06:06.447 [debug] circuit_n...On my bridge:
Jan 06 13:06:06.447 [debug] router_set_status(): Marking router 'moria1/128.31.0
.34' as up.
Jan 06 13:06:06.447 [debug] circuit_n_conn_done(): or_conn to moria1/128.31.0.34
, status=1
Jan 06 13:06:06.447 [debug] circuit_n_conn_done(): Found circ, sending create ce
ll.
Jan 06 13:06:06.447 [debug] circuit_send_next_onion_skin(): First skin; sending
create cell.
Jan 06 13:06:06.449 [debug] circuit_deliver_create_cell(): Chosen circID 23991.
Jan 06 13:06:06.449 [debug] append_cell_to_circuit_queue(): Made a circuit activ
e.
Jan 06 13:06:06.449 [info] circuit_send_next_onion_skin(): First hop: finished s
ending CREATE cell to 'moria1'
Jan 06 13:06:06.449 [info] command_process_netinfo_cell(): Got good NETINFO cell
from 128.31.0.34; OR connection is now open, using protocol version 2
...
Jan 06 13:06:36.449 [info] circuit_expire_building(): Abandoning circ 128.31.0.3
4:9001:23991 (state 0:doing handshakes, purpose 5)
Jan 06 13:06:36.449 [info] exit circ (length 1, exit moria1): $FFCB46DB1339DA846
74C70D7CB586434C4370441(waiting for keys)
Jan 06 13:06:36.449 [info] circuit_build_failed(): Our circuit failed to get a r
esponse from the first hop (128.31.0.34:9001). I'm going to try to rotate to a b
etter connection.
Jan 06 13:06:36.449 [info] connection_ap_fail_onehop(): Closing onehop stream to
'$FFCB46DB1339DA84674C70D7CB586434C4370441/128.31.0.34' because the OR conn jus
t failed.
On moria1 at the same time:
Jan 06 13:06:06.447 [info] tor_tls_read(): Got a TLS renegotiation from "128.31.
0.34"
Jan 06 13:06:06.447 [info] command_process_versions_cell(): Negotiated version 2
with 128.31.0.34; sending NETINFO.
Jan 06 13:06:06.449 [info] command_process_netinfo_cell(): Got good NETINFO cell
from 128.31.0.34; OR connection is now open, using protocol version 2
Jan 06 13:06:06.491 [info] onion_skin_server_handshake(): Couldn't decrypt onion
skin: client may be using old onion key
Shouldn't moria1 be sending something back to indicate failure?
[Automatically added by flyspray2trac: Operating System: All]0.2.1.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/905ServerDNSRandomizeCase config option without effect2020-06-27T14:10:03ZTracServerDNSRandomizeCase config option without effectMy Tor exit gw always randomizes cases in dns queries. Setting "ServerDNSRandomizeCase 0" has no effect. I checked with
v0.2.1.8-alpha (r17523) and v0.2.1.10-alpha (r17969).
[Automatically added by flyspray2trac: Operating System: All]...My Tor exit gw always randomizes cases in dns queries. Setting "ServerDNSRandomizeCase 0" has no effect. I checked with
v0.2.1.8-alpha (r17523) and v0.2.1.10-alpha (r17969).
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Falo0.2.1.11-alphaNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/906crash in getinfo_helper_dir <- handle_control_getinfo <- connection_control_p...2020-06-27T14:10:03ZTraccrash in getinfo_helper_dir <- handle_control_getinfo <- connection_control_process_inbufin version 0.1.2.19 (btw, please add more versions to the input box?)
(ubuntu 8.04 amd64, tor 0.1.2.19-2)
tor crashed:
#0 0x000000000042ba6f in getinfo_helper_dir (control_conn=<value optimized out>,
question=0x139a7f0 "dir/serve...in version 0.1.2.19 (btw, please add more versions to the input box?)
(ubuntu 8.04 amd64, tor 0.1.2.19-2)
tor crashed:
#0 0x000000000042ba6f in getinfo_helper_dir (control_conn=<value optimized out>,
question=0x139a7f0 "dir/server/fp/DCA644B81B06B83F86F6A76EC6974627380C6865", answer=0x7fff6a16a990) at control.c:1281
1281 control.c: No such file or directory.
in control.c
(gdb) bt
#0 0x000000000042ba6f in getinfo_helper_dir (control_conn=<value optimized out>,
question=0x139a7f0 "dir/server/fp/DCA644B81B06B83F86F6A76EC6974627380C6865", answer=0x7fff6a16a990) at control.c:1281
#1 0x0000000000430a1f in handle_control_getinfo (conn=0xc48730, len=<value optimized out>, body=<value optimized out>) at control.c:1618
legacy/trac#2 0x0000000000431cd1 in connection_control_process_inbuf (conn=0xc48730) at control.c:2449
legacy/trac#3 0x000000000042261f in connection_handle_read (conn=0xc48730) at connection.c:1465
legacy/trac#4 0x00000000004460a0 in conn_read_callback (fd=<value optimized out>, event=<value optimized out>, _conn=<value optimized out>) at main.c:422
legacy/trac#5 0x00007f416113bf41 in event_base_loop (base=0x6d5de0, flags=<value optimized out>) at event.c:331
legacy/trac#6 0x0000000000445ceb in tor_main (argc=1, argv=<value optimized out>) at main.c:1270
legacy/trac#7 0x00007f4160df11c4 in __libc_start_main () from /lib/libc.so.6
legacy/trac#8 0x00000000004068f9 in _start ()
I have the core file, if you need more info tell me what to write in gdb -c core etc
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: limcoretorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/907HardwareAccel isn't used2020-06-27T14:10:02ZTracHardwareAccel isn't usedLog shows me:
[info] crypto_global_init(): Initializing OpenSSL via tor_tls_init().
but crypto.c says:
if (useAccel < 0) {
log_info(LD_CRYPTO, "Initializing OpenSSL via tor_tls_init().");
}
if (useAccel > 0) {
l...Log shows me:
[info] crypto_global_init(): Initializing OpenSSL via tor_tls_init().
but crypto.c says:
if (useAccel < 0) {
log_info(LD_CRYPTO, "Initializing OpenSSL via tor_tls_init().");
}
if (useAccel > 0) {
log_info(LD_CRYPTO, "Initializing OpenSSL engine support.");
ENGINE_load_builtin_engines();
if (!ENGINE_register_all_complete())
return -1;
So no HardwareAccel even though torrc says:
HardwareAccel 1
This is Fedora 10 on VIA EK8000. Tor 0.2.0.32, built with source and spec from tor.eff site.
[Automatically added by flyspray2trac: Operating System: Fedora Core Linux]
**Trac**:
**Username**: udohttps://gitlab.torproject.org/tpo/core/tor/-/issues/911Authorities assign Running flag to hibernating relays?2020-06-27T14:10:02ZRoger DingledineAuthorities assign Running flag to hibernating relays?Mikeperry noted that it looks like authorities are assigning the Running
flag if a relay has been reachable within the past however many minutes,
even if the relay published its latest descriptor with "hibernating 1"
in it.
Even if so, ...Mikeperry noted that it looks like authorities are assigning the Running
flag if a relay has been reachable within the past however many minutes,
even if the relay published its latest descriptor with "hibernating 1"
in it.
Even if so, it isn't a big deal, since those latest descriptors will claim
a bandwidth of 0, and so clients will avoid them. But still, worth fixing
at some point.
[Automatically added by flyspray2trac: Operating System: All]Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/912Tor says "data cell dropped, unknown stream", no furter usage of Tor possible2020-06-27T14:10:02ZTracTor says "data cell dropped, unknown stream", no furter usage of Tor possibleIt is the third time this happens to me on this computer.
Tor was running all smooth on the computer, but today I am not able to connect to any website through Tor.
It looks pretty normal and Firefox already shows the favicon when out o...It is the third time this happens to me on this computer.
Tor was running all smooth on the computer, but today I am not able to connect to any website through Tor.
It looks pretty normal and Firefox already shows the favicon when out of nowhere Firefox acts
like someone pressed the reload button. The connection to the site is halted and then Firefox tries to reconnect.
This happens before the page content is rendered in the browser so I don't know how much data was already processed
till the reconnection happens.
At the same time this "reconnect" happens, the Tor log says:
[Info] connection_edge_process_relay_cell(): data cell dropped, unknown stream.
(about 30 times in a row on [Info] verbosity.
I've attached 2 logs. One at [Info] and one at [Debug]. In both cases, Tor was started through Vidalia.
After the onion went green (Tor was connected) I waited some seconds and tried to open blog.fefe.de in
Firefox (Fefes Blog was chosen because it consists of one large html page without pictures - beside the favicon).
Last time this problem occurred I had to do a clean reinstall of the Vidalia Bundle to make it disappear.
The problem occurred with different versions of the 2.1.x branch.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: knappohttps://gitlab.torproject.org/tpo/core/tor/-/issues/913panther compile warnings 0.2.1.11-alpha2020-06-27T14:10:02ZRoger Dingledinepanther compile warnings 0.2.1.11-alphaIn file included from container.c:14:
compat.h:257: warning: duplicate `const'
The line in question is DECLARE_CTYPE_FN()
Perhaps it is looking at this?
extern const uint32_t const TOR_##name##_TABLE[];
[Automatically added by flyspr...In file included from container.c:14:
compat.h:257: warning: duplicate `const'
The line in question is DECLARE_CTYPE_FN()
Perhaps it is looking at this?
extern const uint32_t const TOR_##name##_TABLE[];
[Automatically added by flyspray2trac: Operating System: OSX 10.3 Panther]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/915Directory authority retries parsing incorrect vote infinitely2020-06-27T14:10:02ZKarsten LoesingDirectory authority retries parsing incorrect vote infinitelyThis morning, I found gabelmoo filling its logs with these warnings
(info-level logs only included where it seemed useful):
Jan 22 11:19:46.397 [notice] Tor 0.2.1.11-alpha (r18193) opening log file.
[...]
Jan 23 01:50:01.080 [notice] Ti...This morning, I found gabelmoo filling its logs with these warnings
(info-level logs only included where it seemed useful):
Jan 22 11:19:46.397 [notice] Tor 0.2.1.11-alpha (r18193) opening log file.
[...]
Jan 23 01:50:01.080 [notice] Time to vote.
Jan 23 01:50:01.108 [notice] Choosing valid-after time in vote as 2009-01-23 01:00:00:
consensus_set=1, last_interval=3600
Jan 23 01:50:01.359 [notice] Vote posted.
Jan 23 01:50:19.559 [warn] Got a vote from an authority (nickname rgnx, address
208.83.223.34) with authority key ID 0F06AD141
ABB617AEA5A51663BB2F295DCB13521. This key ID is not recognized. Known v3 key IDs are: E2A2AF570166665D738736D0DD58169CC61D8A8B, 14C131DFC5C6F93646BE72FA1401C02A8DF2E8B4, E8A9C45EDE6D711294FADF8E7951F4DE6CA56B58, 27B6B5996C426270A5C95488AA5BCEB6BCC86956, 81349FC1F2DBA2C2C11B45CB9706637D480AB913, 585769C78764D58426B8B52B6651A5A71137189A
Jan 23 01:50:59.743 [notice] Uploaded a vote to dirserver 80.190.246.100:80
Jan 23 01:50:59.866 [notice] Uploaded a vote to dirserver 194.109.206.212:80
Jan 23 01:51:00.072 [notice] Uploaded a vote to dirserver 128.31.0.34:9031
Jan 23 01:51:00.161 [notice] Uploaded a vote to dirserver 216.224.124.114:9030
Jan 23 01:51:12.885 [notice] Uploaded a vote to dirserver 86.59.21.38:80
Jan 23 01:52:31.246 [notice] Time to fetch any votes that we're missing.
Jan 23 01:52:31.246 [notice] We're missing votes from 2 authorities. Asking every other
authority for a copy.
Jan 23 01:52:31.452 [info] connection_dir_client_reached_eof(): Got votes (size 913169)
from server 86.59.21.38:80
Jan 23 01:52:31.508 [warn] Error decoding descriptor digest "UpcKF+KfBAgnHr+IyNP009-01-2"
Jan 23 01:52:31.522 [warn] Error reading network-status vote: signature does not match.
Jan 23 01:52:31.524 [warn] Couldn't parse vote: length was 457268
Jan 23 01:52:31.533 [warn] Error decoding descriptor digest "UpcKF+KfBAgnHr+IyNP009-01-2"
Jan 23 01:52:31.547 [warn] Error reading network-status vote: signature does not match.
Jan 23 01:52:31.548 [warn] Couldn't parse vote: length was 457268
Jan 23 01:52:31.557 [warn] Error decoding descriptor digest "UpcKF+KfBAgnHr+IyNP009-01-2"
Jan 23 01:52:31.571 [warn] Error reading network-status vote: signature does not match.
Jan 23 01:52:31.572 [warn] Couldn't parse vote: length was 457268
[...]
Jan 23 12:03:23.635 [warn] Error decoding descriptor digest "UpcKF+KfBAgnHr+IyNP009-01-2"
Jan 23 12:03:23.648 [warn] Error reading network-status vote: signature does not match.
Jan 23 12:03:23.650 [warn] Couldn't parse vote: length was 457268
This problem recurred at a rate of about 42 times per second (!) until I
killed it at 12:03. gabelmoo was unresponsive at that time: Tor weather
reported it couldn't ping it, gabelmoo didn't vote, and the Tor process had
to be killed with -9.
In the last votes that gabelmoo wrote (at 00:55), there is the correct line
that probably should have been parsed:
r Unnamed St3/Fe5maZRmmctLe/Mh9jU0rYk UpcKF+KfBAgnHr+IyNPOYbOzMCA 2009-01-22 13:10:15
99.21.76.207 9001 9030
The first question is where the ten characters # in
"UpcKF+KfBAgnHr+IyNP#########legacy/trac#9-01-2" went missing.
The second, and more important question is why gabelmoo tries to re-parse
the incorrect vote over and over again.
[Automatically added by flyspray2trac: Operating System: Other Linux]https://gitlab.torproject.org/tpo/core/tor/-/issues/9160.2.0.33 doesn't compile on FC8 64-bit2020-06-27T14:10:02ZRoger Dingledine0.2.0.33 doesn't compile on FC8 64-bitReported by John Thompson:
It won't compile for me here (Fedora8 64bit). tor-0.2.32 compiled fine,
however, and 0.2.0.33 built fine on my NetBSD box. See attached log.
In file included from buffers.c:17:
or.h: In function 'TO_OR_CONN'...Reported by John Thompson:
It won't compile for me here (Fedora8 64bit). tor-0.2.32 compiled fine,
however, and 0.2.0.33 built fine on my NetBSD box. See attached log.
In file included from buffers.c:17:
or.h: In function 'TO_OR_CONN':
or.h:1102: warning: implicit declaration of function 'log'
or.h:1102: warning: incompatible implicit declaration of built-in function 'log'
or.h:1102: error: 'LOG_ERR' undeclared (first use in this function)
or.h:1102: error: (Each undeclared identifier is reported only once
or.h:1102: error: for each function it appears in.)
or.h:1102: error: 'LD_BUG' undeclared (first use in this function)
or.h:1102: error: too many arguments to function 'log'
or.h: In function 'TO_DIR_CONN':
or.h:1107: warning: incompatible implicit declaration of built-in function 'log'
or.h:1107: error: 'LOG_ERR' undeclared (first use in this function)
or.h:1107: error: 'LD_BUG' undeclared (first use in this function)
or.h:1107: error: too many arguments to function 'log'
or.h: In function 'TO_EDGE_CONN':
or.h:1112: warning: incompatible implicit declaration of built-in function 'log'
or.h:1112: error: 'LOG_ERR' undeclared (first use in this function)
or.h:1112: error: 'LD_BUG' undeclared (first use in this function)
or.h:1112: error: too many arguments to function 'log'
or.h: In function 'TO_CONTROL_CONN':
or.h:1117: warning: incompatible implicit declaration of built-in function 'log'
or.h:1117: error: 'LOG_ERR' undeclared (first use in this function)
or.h:1117: error: 'LD_BUG' undeclared (first use in this function)
or.h:1117: error: too many arguments to function 'log'
or.h: In function 'TO_OR_CIRCUIT':
or.h:1945: warning: incompatible implicit declaration of built-in function 'log'
or.h:1945: error: 'LOG_ERR' undeclared (first use in this function)
or.h:1945: error: 'LD_BUG' undeclared (first use in this function)
or.h:1945: error: too many arguments to function 'log'
or.h: In function 'TO_ORIGIN_CIRCUIT':
or.h:1950: warning: incompatible implicit declaration of built-in function 'log'
or.h:1950: error: 'LOG_ERR' undeclared (first use in this function)
or.h:1950: error: 'LD_BUG' undeclared (first use in this function)
or.h:1950: error: too many arguments to function 'log'
buffers.c: In function 'chunk_new_with_alloc_size':
buffers.c:174: warning: incompatible implicit declaration of built-in function '
log'
buffers.c:174: error: 'LOG_ERR' undeclared (first use in this function)
buffers.c:174: error: 'LD_BUG' undeclared (first use in this function)
buffers.c:174: error: too many arguments to function 'log'
buffers.c: In function 'chunk_grow':
buffers.c:226: warning: incompatible implicit declaration of built-in function '
log'
buffers.c:226: error: 'LOG_ERR' undeclared (first use in this function)
buffers.c:226: error: 'LD_BUG' undeclared (first use in this function)
buffers.c:226: error: too many arguments to function 'log'
buffers.c: In function 'buf_shrink_freelists':
buffers.c:271: warning: implicit declaration of function 'log_info'
buffers.c:271: error: 'LD_MM' undeclared (first use in this function)
buffers.c:275: warning: incompatible implicit declaration of built-in function '
log'
buffers.c:275: error: 'LOG_ERR' undeclared (first use in this function)
buffers.c:275: error: 'LD_BUG' undeclared (first use in this function)
buffers.c:275: error: too many arguments to function 'log'
buffers.c:288: warning: incompatible implicit declaration of built-in function '
log'
buffers.c:288: error: too many arguments to function 'log'
buffers.c: In function 'buf_dump_freelist_sizes':
buffers.c:306: warning: incompatible implicit declaration of built-in function '
log'
buffers.c:306: error: 'LD_MM' undeclared (first use in this function)
buffers.c:306: error: too many arguments to function 'log'
buffers.c:317: error: too many arguments to function 'log'
buffers.c:320: error: too many arguments to function 'log'
buffers.c: In function 'buf_pullup':
buffers.c:373: warning: incompatible implicit declaration of built-in function '
log'
buffers.c:373: error: 'LOG_ERR' undeclared (first use in this function)
buffers.c:373: error: 'LD_BUG' undeclared (first use in this function)
buffers.c:373: error: too many arguments to function 'log'
buffers.c:381: warning: incompatible implicit declaration of built-in function '
log'
buffers.c:381: error: too many arguments to function 'log'
buffers.c:393: warning: incompatible implicit declaration of built-in function '
log'
buffers.c:393: error: too many arguments to function 'log'
buffers.c:406: warning: incompatible implicit declaration of built-in function '
log'
buffers.c:406: error: too many arguments to function 'log'
buffers.c:411: warning: incompatible implicit declaration of built-in function '
log'
buffers.c:411: error: too many arguments to function 'log'
buffers.c: In function 'buf_remove_from_front':
buffers.c:431: warning: incompatible implicit declaration of built-in function '
log'
buffers.c:431: error: 'LOG_ERR' undeclared (first use in this function)
buffers.c:431: error: 'LD_BUG' undeclared (first use in this function)
buffers.c:431: error: too many arguments to function 'log'
buffers.c:433: warning: incompatible implicit declaration of built-in function '
log'
buffers.c:433: error: too many arguments to function 'log'
...
[Automatically added by flyspray2trac: Operating System: Fedora Core Linux]0.2.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/917Nameserver probes can give strange results2020-06-27T14:10:02ZNick MathewsonNameserver probes can give strange resultsWe should not actually retry nameserver probes, nor should we _ever_ reattach them to a new nameserver after
clear and resume.
Fortunately, the worst that happens here now is that we erroneously mark a down nameserver as up, retry it,
...We should not actually retry nameserver probes, nor should we _ever_ reattach them to a new nameserver after
clear and resume.
Fortunately, the worst that happens here now is that we erroneously mark a down nameserver as up, retry it,
fail, and mark it down again. Still, that's pretty ugly.
[Automatically added by flyspray2trac: Operating System: All]post 0.2.1.xhttps://gitlab.torproject.org/tpo/core/tor/-/issues/918bind to port 443 + wake from hibernation = exit2020-06-27T14:10:01ZRoger Dingledinebind to port 443 + wake from hibernation = exit<ioerror> Jan 28 22:05:50.644 [notice] Opening OR listener on 80.68.85.45:443
<ioerror> Jan 28 22:05:50.644 [warn] Could not bind to 80.68.85.45:443:
+Permission denied
<ioerror> Jan 28 22:05:50.645 [warn] Failed to parse/validate config...<ioerror> Jan 28 22:05:50.644 [notice] Opening OR listener on 80.68.85.45:443
<ioerror> Jan 28 22:05:50.644 [warn] Could not bind to 80.68.85.45:443:
+Permission denied
<ioerror> Jan 28 22:05:50.645 [warn] Failed to parse/validate config: Failed
+to bind one of the listener ports.
Basically if you bind to port 443 directly, and then drop privs, that's fine.
When you hup, Tor will (should) correctly decide to leave that port alone since
it hasn't changed and it wouldn't be able to bind it again anyway.
But when we hibernate, and then come back, we can't bind it. Currently we die.
Option one, never close it in this case. Not great, since we want to be hibernating,
but not awful.
Option two, keep a separate root process around that can jumpstart Tor again. Ugh.
Option three, warn if this configuration is used, so the user can at least know.
How do we auto detect that it's a privileged port? Just "port < 1024"?
[Automatically added by flyspray2trac: Operating System: All]Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/919If you hup tor while it's hibernating, it rebinds its ports2020-06-27T14:10:01ZRoger DingledineIf you hup tor while it's hibernating, it rebinds its portsIt looks like retry_listeners() and retry_all_listeners() do not care
whether we're hibernating. In main.c, retry-all-listeners is only called if
if (!we_are_hibernating() && time_to_check_listeners < now) {
whereas in config.c it do...It looks like retry_listeners() and retry_all_listeners() do not care
whether we're hibernating. In main.c, retry-all-listeners is only called if
if (!we_are_hibernating() && time_to_check_listeners < now) {
whereas in config.c it does not check if we_are_hibernating. Sounds like that's
the place to fix it.
[Automatically added by flyspray2trac: Operating System: All]Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/920don't bundle libevent with Tor2020-06-27T14:10:01ZTracdon't bundle libevent with TorHi,
I am the maintainer of Tor in Gentoo Linux and we have an open report in our issues tracker: http://bugs.gentoo.org/show_bug.cgi?id=206969
The report states that the asynchronous DNS part of libevent is bundled with Tor, which is t...Hi,
I am the maintainer of Tor in Gentoo Linux and we have an open report in our issues tracker: http://bugs.gentoo.org/show_bug.cgi?id=206969
The report states that the asynchronous DNS part of libevent is bundled with Tor, which is true (see src/or/evendns.{c,h}). This gives our security team and myself a headache as a security problem found in libevent has to be tracked in all messages that bundle it or just only parts. Please remove that bit and try to bring your modifications upstream to libevent if needed.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: V-Lipost 0.2.1.xhttps://gitlab.torproject.org/tpo/core/tor/-/issues/921clients avoid *all* authority types when avoiding any2020-06-27T14:10:01ZRoger Dingledineclients avoid *all* authority types when avoiding anyClients doing directory fetches avoid authorities of all types when trying
to avoid authorities of any type. So a client asking for a v3 consensus will
never ask moria2, because moria2 is an authority of some type. Similarly,
caches want...Clients doing directory fetches avoid authorities of all types when trying
to avoid authorities of any type. So a client asking for a v3 consensus will
never ask moria2, because moria2 is an authority of some type. Similarly,
caches wanting a v3 consensus won't ask moria2, because it's not a v3
authority. Same goes for Tonga, our bridge authority.
See
is_trusted = router_digest_is_trusted_dir(status->identity_digest);
in router_pick_directory_server_impl() in routerlist.c
We should instead ask if it's a trusted dir for the type of authority
we're wondering about.
[Automatically added by flyspray2trac: Operating System: All]post 0.2.1.xhttps://gitlab.torproject.org/tpo/core/tor/-/issues/922Problem upgrading to Tor stable Version 0.2.0.332020-06-27T14:10:01ZTracProblem upgrading to Tor stable Version 0.2.0.33I need some assistance please. I am a basic computer user but I have been
able to install Tor which I have been using daily for months now. My OS is
MacOsx Panther 10.3.9 and the Tor bundle installed is 0.2.0.31. The OS is
being operat...I need some assistance please. I am a basic computer user but I have been
able to install Tor which I have been using daily for months now. My OS is
MacOsx Panther 10.3.9 and the Tor bundle installed is 0.2.0.31. The OS is
being operated from an external HD.
I am no longer able to upgrade to the latest Tor versions (0.2.0.33) because
as soon as I open the installer package of the new version I get the error
message:
The Installer package "vidalia-bundle - 0.2.0.33-0.10-ppc" cannot be
opened.
The Bill of Materials for this package was not found.
I have tried several times with the same result. I have tried
deleting the previous Tor, Privoxy and Vidalia (0.2.0.31) before
I install the new version but I still get the error message.In
another Tor forum I was advised to report this as a possible bug.
I have always upgraded to new stable versions of Tor this way.
The install.log shows only:
Feb 5 08:08:25 localhost : Vidalia - Tor - Privoxy - Torbutton Bundle Installation Log
Feb 5 08:08:25 localhost : Opened from: /Volumes/vidalia-bundle-0.2.0.33-0.1.10-ppc/vidalia-bundle-0.2.0.33-0.1.10-ppc.mpkg
Feb 5 08:08:25 localhost : Hardware Model: PowerMac6,4 @ 1249 MHz, 1024 MB
Feb 5 08:08:25 localhost : Running OS Build: 7W98
Feb 5 08:08:25 localhost : Installer Language: English
Thank you
Louis
[Automatically added by flyspray2trac: Operating System: OSX 10.3 Panther]
**Trac**:
**Username**: LouisAndrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/tpo/core/tor/-/issues/923Tor software exited unexpectedly2020-06-27T14:10:01ZTracTor software exited unexpectedlyTor does not start
Vadilia detected that the Tor software exited unexpectedly
Error from libevent: evsignal_init: socketpair: No error
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: serbaTor does not start
Vadilia detected that the Tor software exited unexpectedly
Error from libevent: evsignal_init: socketpair: No error
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: serbahttps://gitlab.torproject.org/tpo/core/tor/-/issues/927Tor silently dies since v0.2.0.332020-06-27T14:10:00ZTracTor silently dies since v0.2.0.33Tor worked just fine for ages, but unfortunately v0.2.0.32 was last version to work at all.
After upgrading to v0.2.0.33 and later to v0.2.0.34 tor just silently dies. So i forced to roll back to v0.2.0.32
All versions was installed as ...Tor worked just fine for ages, but unfortunately v0.2.0.32 was last version to work at all.
After upgrading to v0.2.0.33 and later to v0.2.0.34 tor just silently dies. So i forced to roll back to v0.2.0.32
All versions was installed as vidalia bundle on Windows 2000 Service Pack 4 server. Application log shows nothing about tor.
And tor own log dosn't help either. Below is two tor versions outputs, started from cmd line, so bundle config is not used.
v0.2.0.32 :
16:29:12
%%>>>H:\WinApp\TOR\Tor\tor
Feb 15 16:29:20.139 [notice] Tor v0.2.0.32 (r17346). This is experimental softwa
re. Do not rely on it for strong anonymity. (Running on Windows 2000 Service Pac
k 4 [server] {enterprise})
Feb 15 16:29:20.239 [notice] Configuration file "G:\Documents and Settings\Admin
istrator\Application Data\tor\torrc" not present, using reasonable defaults.
Feb 15 16:29:20.259 [notice] Initialized libevent version 1.4.7-stable using met
hod win32. Good.
Feb 15 16:29:20.259 [notice] Opening Socks listener on 127.0.0.1:9050
Feb 15 16:29:22.342 [warn] Please upgrade! This version of Tor (0.2.0.32) is obs
olete, according to the directory authorities. Recommended versions are: 0.2.0.3
3,0.2.0.34,0.2.1.11-alpha,0.2.1.12-alpha
Feb 15 16:29:25.236 [notice] We now have enough directory information to build c
ircuits.
Feb 15 16:29:30.974 [notice] Tor has successfully opened a circuit. Looks like c
lient functionality is working.
v0.2.0.32 :
16:30:10
%%>>>H:\WinApp\TOR\Tor\tor
Feb 15 16:31:07.153 [notice] Tor v0.2.0.34 (r18423). This is experimental softwa
re. Do not rely on it for strong anonymity. (Running on Windows 2000 Service Pac
k 4 [server] {enterprise})
Feb 15 16:31:07.243 [notice] Configuration file "G:\Documents and Settings\Admin
istrator\Application Data\tor\torrc" not present, using reasonable defaults.
Feb 15 16:31:07.293 [notice] Initialized libevent version 1.4.9-stable using met
hod win32. Good.
Feb 15 16:31:07.293 [notice] Opening Socks listener on 127.0.0.1:9050
16:31:08
%%>>>H:\WinApp\TOR\Tor\
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: Pheamaphhttps://gitlab.torproject.org/tpo/core/tor/-/issues/928With BridgeRelay 1 and ORPort 0, things go bad2020-06-27T14:10:00ZRoger DingledineWith BridgeRelay 1 and ORPort 0, things go badA while ago Vidalia set my BridgeRelay to 1 but left my ORPort off. This
caused my Tor to make all sorts of weird decisions about what it would
contact, what it would fetch, etc. After a while my Tor became useless
because it didn't have...A while ago Vidalia set my BridgeRelay to 1 but left my ORPort off. This
caused my Tor to make all sorts of weird decisions about what it would
contact, what it would fetch, etc. After a while my Tor became useless
because it didn't have enough descriptors to make a circuit, and it didn't
care to get any more.
We fixed the Vidalia bug (I think), but if a user sets their config this
way they will end up sad. We should explore why this is, and tighten up
the checks inside Tor.
[Automatically added by flyspray2trac: Operating System: All]Tor: 0.2.2.x-final