Tor issues
https://gitlab.torproject.org/tpo/core/tor/-/issues
2020-06-27T14:09:59Z
https://gitlab.torproject.org/tpo/core/tor/-/issues/936
Race in picking connections for create cell
2020-06-27T14:09:59Z
Roger Dingledine
Race in picking connections for create cell
Reported by lark.
I possible found edge case for doubling conns between two relays, the
one inbound and the one outbound for the node. It's can trigger if conns
launched by relays to each other at the same time, very precisely. Which ca...
Reported by lark.
I possible found edge case for doubling conns between two relays, the
one inbound and the one outbound for the node. It's can trigger if conns
launched by relays to each other at the same time, very precisely. Which can
happens for two relays with high uptime and fast speed, after
TIME_BEFORE_OR_CONN_IS_TOO_OLD.
```
--- connection_or.c.orig Thu Feb 5 00:42:22 2009
+++ connection_or.c Fri Mar 6 19:15:04 2009
-452,7 +452,7 @@
const or_connection_t *b,
int forgive_new_connections)
{
- int newer;
+ int newer, delta, inbound_a, outbound_b, prefer_conn_a;
/** Do not definitively deprecate a new connection with no circuits on it
* until this much time has passed. */
#define NEW_CONN_GRACE_PERIOD (15*60)
-461,15 +461,32 @@
return 0; /* A canonical connection is better than a non-canonical
* one, no matter how new it is or which has circuits. */
- newer = b->_base.timestamp_created < a->_base.timestamp_created;
+ inbound_a = tor_tls_is_server(a->tls);
+ outbound_b = !tor_tls_is_server(b->tls);
+ delta=(int)(a->_base.timestamp_created - b->_base.timestamp_created);
+ newer= delta > 0;
+
+ /* We prefer the "a" conn at equal conditions:
+ *
+ * if "a" is inbound from a node with higher identity key
+ * and created at the same time or later than outbound "b" conn;
+ *
+ * or
+ *
+ * if "a" newer than "b" for any other inbound-outbound
+ * combinations */
+ prefer_conn_a = ((newer && !(inbound_a && outbound_b)) ||
+ (inbound_a && outbound_b && delta >= 0 &&
+ a->circ_id_type == CIRC_ID_TYPE_LOWER));
+
if (
/* We prefer canonical connections regardless of newness. */
(!b->is_canonical && a->is_canonical) ||
/* If both have circuits we prefer the newer: */
- (b->n_circuits && a->n_circuits && newer) ||
+ (b->n_circuits && a->n_circuits && prefer_conn_a) ||
/* If neither has circuits we prefer the newer: */
- (!b->n_circuits && !a->n_circuits && newer))
+ (!b->n_circuits && !a->n_circuits && prefer_conn_a))
return 1;
/* If one has no circuits and the other does... */
```
[Automatically added by flyspray2trac: Operating System: All]
Tor: unspecified
https://gitlab.torproject.org/tpo/core/tor/-/issues/937
Tor does not support OpenSSL dynamic hardware engines
2020-06-27T14:09:59Z
coderman
Tor does not support OpenSSL dynamic hardware engines
NOTE: fix due in 0.2.2.x.
branch hardware_accel_improvements at git://git.torproject.org/~coderman/git/tor.git
The existing support for crypto acceleration in Tor via the HardwareAccel 1 option is not able to load dynamic engines.
For ...
NOTE: fix due in 0.2.2.x.
branch hardware_accel_improvements at git://git.torproject.org/~coderman/git/tor.git
The existing support for crypto acceleration in Tor via the HardwareAccel 1 option is not able to load dynamic engines.
For example, padlock acceleration with Via processors. See also http://archives.seul.org/or/talk/Dec-2008/msg00314.html
To fix this the src/common/crypto.c should be extended to attempt dynamic engine loading.
NOTE: I have fixed the engine name to "padlock"; robust support for this feature will require a config option
like "HardwareEngineName" or such.
In crypto_global_init():
if (useAccel > 0) {
ENGINE *e = NULL;
log_info(LD_CRYPTO, "Initializing OpenSSL engine support.");
ENGINE_load_builtin_engines();
ENGINE_register_all_complete();
e = ENGINE_by_id ("padlock");
if (!e) {
log_info(LD_CRYPTO, "Trying to load dynamic Padlock OpenSSL engine.");
e = try_load_engine ("padlock");
if (!e) {
log_info(LD_CRYPTO, "Unable to load Padlock OpenSSL engine.");
}
}
if (e) {
log_info(LD_CRYPTO, "Loaded Padlock OpenSSL engine, setting default ciphers.");
ENGINE_set_default (e, ENGINE_METHOD_ALL);
}
}
Where the try_load_engine for dynamic libs is:
/* Try to load a dynamic engine library. */
static ENGINE *
try_load_engine(const char *engine)
{
ENGINE *e = ENGINE_by_id ("dynamic");
if (e)
{
if (!ENGINE_ctrl_cmd_string (e, "SO_PATH", engine, 0)
|| !ENGINE_ctrl_cmd_string (e, "LOAD", NULL, 0))
{
ENGINE_free (e);
e = NULL;
}
}
return e;
}
Depending on VIA processor/stepping this results in:
Mar 08 06:32:00.473 [info] crypto_global_init(): Initializing OpenSSL engine support.
Mar 08 06:32:00.473 [info] crypto_global_init(): Loaded Padlock OpenSSL engine, setting default ciphers.
Mar 08 06:32:00.473 [info] Using default implementation for RSA
Mar 08 06:32:00.473 [info] Using default implementation for DH
Mar 08 06:32:00.473 [info] Using default implementation for RAND
Mar 08 06:32:00.473 [notice] Using OpenSSL engine VIA PadLock: RNG (not used) ACE2 PHE(8192) PMM [padlock] for SHA1
Mar 08 06:32:00.473 [info] Using default implementation for 3DES
Mar 08 06:32:00.473 [notice] Using OpenSSL engine VIA PadLock: RNG (not used) ACE2 PHE(8192) PMM [padlock] for AES
...
[Automatically added by flyspray2trac: Operating System: All]
post 0.2.1.x
coderman
coderman
https://gitlab.torproject.org/tpo/core/tor/-/issues/939
Our socket count is below zero
2020-06-27T14:09:59Z
Roger Dingledine
Our socket count is below zero
Running moria1 on 0.2.1.12-alpha-dev (r18691), it ran for a few weeks. Then
I !^c'ed it to move to 0.2.1.13-alpha, and its last words were
Mar 09 17:22:50.253 [warn] tor_close_socket(): Bug: Our socket count is below zero: -1. Please su...
Running moria1 on 0.2.1.12-alpha-dev (r18691), it ran for a few weeks. Then
I !^c'ed it to move to 0.2.1.13-alpha, and its last words were
Mar 09 17:22:50.253 [warn] tor_close_socket(): Bug: Our socket count is below zero: -1. Please submit a bug report.
[Automatically added by flyspray2trac: Operating System: All]
https://gitlab.torproject.org/tpo/core/tor/-/issues/941
circuit event lines sometimes miss verbose names
2020-06-27T14:09:59Z
Roger Dingledine
circuit event lines sometimes miss verbose names
In my Vidalia logs
Mar 12 20:18:31.186 [notice] QtWarningMsg: torcontrol: Improperly formatted
circuit: '16 EXTENDED $5A583B838FDC22246E046E1D4E108F41EFBAD175'
edmanm:#vidalia> those circ events are spec compliant, but they're annoying
...
In my Vidalia logs
Mar 12 20:18:31.186 [notice] QtWarningMsg: torcontrol: Improperly formatted
circuit: '16 EXTENDED $5A583B838FDC22246E046E1D4E108F41EFBAD175'
edmanm:#vidalia> those circ events are spec compliant, but they're annoying
since they don't include the nickname, even when you ask for verbose_names.
edmanm:#vidalia> i don't know why tor includes that with some circ events and
not others.
edmanm> when i say "usefeature verbose_names", tor gives me hops in circ
events as either "$id=nickname" for named relays or "$id~nickname" for
non-named relays.
edmanm> except in some cases, like the one you pasted above, all i get is
$id.
edmanm> that's the same format you get when you don't specify 'usefeature
verbose_names'. (i.e. just $id for non-named relays or just the nickname for
named relays)
[Automatically added by flyspray2trac: Operating System: All]
0.2.1.x-final
https://gitlab.torproject.org/tpo/core/tor/-/issues/943
Tor's once-per-second events are not quite once-per-second?
2020-06-27T14:09:59Z
Roger Dingledine
Tor's once-per-second events are not quite once-per-second?
Mar 16 11:07:43.655 [debug] QtDebugMsg: torcontrol: Control Event: 650 BW 0 0
Mar 16 11:07:44.659 [debug] QtDebugMsg: torcontrol: Control Event: 650 BW 0 0
Mar 16 11:07:45.663 [debug] QtDebugMsg: torcontrol: Control Event: 650 BW 0 0
Mar...
Mar 16 11:07:43.655 [debug] QtDebugMsg: torcontrol: Control Event: 650 BW 0 0
Mar 16 11:07:44.659 [debug] QtDebugMsg: torcontrol: Control Event: 650 BW 0 0
Mar 16 11:07:45.663 [debug] QtDebugMsg: torcontrol: Control Event: 650 BW 0 0
Mar 16 11:07:46.667 [debug] QtDebugMsg: torcontrol: Control Event: 650 BW 0 0
Mar 16 11:07:47.671 [debug] QtDebugMsg: torcontrol: Control Event: 650 BW 0 0
Mar 16 11:07:48.675 [debug] QtDebugMsg: torcontrol: Control Event: 650 BW 0 0
Mar 16 11:07:49.676 [debug] QtDebugMsg: torcontrol: Control Event: 650 BW 0 0
Mar 16 11:07:50.679 [debug] QtDebugMsg: torcontrol: Control Event: 650 BW 0 0
Mar 16 11:07:51.683 [debug] QtDebugMsg: torcontrol: Control Event: 650 BW 0 0
My 'bw' events are getting sent out slightly more than one second
apart. Didn't we try to send them out every second? More broadly,
is libevent calling our once-a-second events every 1.004 seconds or
the like?
Maybe that evtimer_add() call in second_elapsed_callback() should be at
the beginning? That seems a bit more fragile in the case where it takes
a whole second to process stuff. But if it takes any non-trivial amount
of time to process stuff, then that function isn't reliably getting
called once a second. How big a problem is that?
[Automatically added by flyspray2trac: Operating System: All]
Tor: 0.2.2.x-final
Nick Mathewson
Nick Mathewson
https://gitlab.torproject.org/tpo/core/tor/-/issues/948
Crash on rendcommon.c:33
2020-06-27T14:09:59Z
Trac
Crash on rendcommon.c:33
Revision 19068. Crash. No log (latest "[notice] Performing bandwidth self-test...done.")
Core was generated by `/usr/bin/tor --runasdaemon 1'.
Program terminated with signal 11, Segmentation fault.
[New process 8760]
[New process 8775]
...
Revision 19068. Crash. No log (latest "[notice] Performing bandwidth self-test...done.")
Core was generated by `/usr/bin/tor --runasdaemon 1'.
Program terminated with signal 11, Segmentation fault.
[New process 8760]
[New process 8775]
#0 0x080b89e3 in rend_service_descriptor_free (desc=0x86c9040) at rendcommon.c:33
33 SMARTLIST_FOREACH(desc->successful_uploads, char *, c, tor_free(c););
(gdb) bt
#0 0x080b89e3 in rend_service_descriptor_free (desc=0x86c9040) at rendcommon.c:33
#1 0x080bef73 in rend_consider_services_upload (now=1237319764) at rendservice.c:545
legacy/trac#2 0x080a9774 in second_elapsed_callback (fd=-1, event=1, args=0x0) at main.c:1086
legacy/trac#3 0xb7f1c3ce in event_base_loop (base=0x81430b0, flags=0) at event.c:387
legacy/trac#4 0xb7f1c5b4 in event_loop (flags=0) at event.c:463
legacy/trac#5 0x080a9db5 in do_main_loop () at main.c:1435
legacy/trac#6 0x080aa04f in tor_main (argc=3, argv=0xbfd7b284) at main.c:2060
legacy/trac#7 0x080e67e6 in main (argc=Cannot access memory at address 0x11
) at tor_main.c:30
(gdb)
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: xiando
0.2.1.x-final
https://gitlab.torproject.org/tpo/core/tor/-/issues/949
Tor server can't bind itself to a ip address and dies.
2020-06-27T14:09:58Z
Trac
Tor server can't bind itself to a ip address and dies.
I am using Tor version 0.2.0.34 (r18423).
I have set up Tor to bind the server to the localhost loopback and to a local network ip address.
By default the daemon is configured to start in runlevel 2 with S20tor.
When the system starts, t...
I am using Tor version 0.2.0.34 (r18423).
I have set up Tor to bind the server to the localhost loopback and to a local network ip address.
By default the daemon is configured to start in runlevel 2 with S20tor.
When the system starts, there is a race condition of the daemons on the same run-level and if the kernel
hasn't yet registered the ip address of the local network
interface because it's querying in dhcp mode,
tor puts a message on stdout on boot that it wasn't able to bind itself to the LAN address specified and dies.
This is very annoying,because I often start the system and then I don't find the expected instance of tor running,
even if the interface and the local ip address are working.
For me it's better if the started instance of tor,keep polling for specified ip address instead of die.
Also moving the name of the file to something like S90tor on all runlevels seems to help partially as the problem seems just to slightly
decrease.(this confirm the race condition problem)
I can't attach any log output as it does not output nothing relevant in the logs...it just dies.
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: mavior
weasel (Peter Palfrader)
weasel (Peter Palfrader)
https://gitlab.torproject.org/tpo/core/tor/-/issues/957
v0.2.1.13-alpha crashing
2020-06-27T14:09:58Z
Trac
v0.2.1.13-alpha crashing
Tor v0.2.1.13-alpha (r18828) on Debian Lenny x86_64
My Blutmagie server process died dumping a core file. gdb backtrace output refers to eventdns.
anonymizer2:~# gdb /usr/sbin/tor ~debian-tor/.tor/core.20793
GNU gdb 6.8-debian
Copyrigh...
Tor v0.2.1.13-alpha (r18828) on Debian Lenny x86_64
My Blutmagie server process died dumping a core file. gdb backtrace output refers to eventdns.
anonymizer2:~# gdb /usr/sbin/tor ~debian-tor/.tor/core.20793
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...
warning: core file may not match specified executable file.
warning: Can't read pathname for load map: Input/output error.
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /usr/lib/libevent-1.3e.so.1...done.
Loaded symbols for /usr/lib/libevent-1.3e.so.1
Reading symbols from /usr/lib/libssl.so.0.9.8...done.
Loaded symbols for /usr/lib/libssl.so.0.9.8
Reading symbols from /usr/lib/libcrypto.so.0.9.8...done.
Loaded symbols for /usr/lib/libcrypto.so.0.9.8
Reading symbols from /lib/libpthread.so.0...done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux-x86-64.so.2...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /lib/libnsl.so.1...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/librt.so.1...done.
Loaded symbols for /lib/librt.so.1
Reading symbols from /lib/libresolv.so.2...done.
Loaded symbols for /lib/libresolv.so.2
Core was generated by `/usr/sbin/tor'.
Program terminated with signal 6, Aborted.
[New process 20793]
[New process 20803]
[New process 20802]
[New process 20801]
[New process 20800]
[New process 20799]
[New process 20798]
[New process 20797]
[New process 20796]
[New process 20795]
[New process 20794]
#0 0x00007f99debe8ed5 in raise () from /lib/libc.so.6
(gdb) bt
#0 0x00007f99debe8ed5 in raise () from /lib/libc.so.6
#1 0x00007f99debea3f3 in abort () from /lib/libc.so.6
legacy/trac#2 0x00007f99debe1dc9 in __assert_fail () from /lib/libc.so.6
legacy/trac#3 0x00007f99df91c453 in ?? () from /usr/lib/libevent-1.3e.so.1
legacy/trac#4 0x00007f99df91c734 in event_add () from /usr/lib/libevent-1.3e.so.1
legacy/trac#5 0x0000000000496922 in evdns_request_transmit (req=0x7f99d0acee00)
at eventdns.c:482
legacy/trac#6 0x000000000049716a in evdns_requests_pump_waiting_queue ()
at eventdns.c:2168
legacy/trac#7 0x000000000049769a in reply_handle (req=0x7f99d36b3c00,
flags=<value optimized out>, ttl=<value optimized out>,
reply=<value optimized out>) at eventdns.c:826
legacy/trac#8 0x0000000000497f47 in nameserver_read (ns=0x7f99dff4e800)
at eventdns.c:1031
legacy/trac#9 0x00007f99df91cec1 in event_base_loop () from /usr/lib/libevent-1.3e.so.1
legacy/trac#10 0x000000000045f606 in do_main_loop () at main.c:1435
legacy/trac#11 0x000000000045f855 in tor_main (argc=1, argv=<value optimized out>)
at main.c:2060
legacy/trac#12 0x00007f99debd51a6 in __libc_start_main () from /lib/libc.so.6
legacy/trac#13 0x0000000000407689 in _start ()
(gdb)
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: Falo
0.2.1.x-final
https://gitlab.torproject.org/tpo/core/tor/-/issues/959
bodylen 501408 larger than 499999. Failing.
2020-06-27T14:09:58Z
Roger Dingledine
bodylen 501408 larger than 499999. Failing.
Tor directory authorities are refusing uploaded votes, since the votes
have grown larger than 500KB.
Mar 26 23:50:03.015 [warn] bodylen 501408 larger than 499999. Failing.
Mar 26 23:50:03.015 [warn] Invalid input from address '86.59.21....
Tor directory authorities are refusing uploaded votes, since the votes
have grown larger than 500KB.
Mar 26 23:50:03.015 [warn] bodylen 501408 larger than 499999. Failing.
Mar 26 23:50:03.015 [warn] Invalid input from address '86.59.21.38'. Closing.
moria1 (and others) have been doing this for the past 5 days, and the world
hasn't exploded. I think that's because the uploads are refused:
/** Maximum size, in bytes, for any directory object that we're accepting
* as an upload. */
#define MAX_DIR_UL_SIZE 500000
but then Tor falls back to fetching the votes, which succeeds:
/** Maximum size, in bytes, for any directory object that we've downloaded. */
#define MAX_DIR_DL_SIZE MAX_BUF_SIZE
Currently there are only four items that are uploaded:
/** A connection to a directory server: upload a server descriptor. */
#define DIR_PURPOSE_UPLOAD_DIR 8
/** A connection to a directory server: upload a rendezvous
* descriptor. */
#define DIR_PURPOSE_UPLOAD_RENDDESC 9
/** A connection to a directory server: upload a v3 networkstatus vote. */
#define DIR_PURPOSE_UPLOAD_VOTE 10
/** A connection to a directory server: upload a v3 consensus signature */
#define DIR_PURPOSE_UPLOAD_SIGNATURES 11
And once UPLOAD_DIR has finished, we limit the size of the objects we're
willing to add, in case we're attacked.
I think the right fix is to set MAX_DIR_UL_SIZE to MAX_BUF_SIZE also. Any
other fix will mean we reopen this bug in 18 months.
[Automatically added by flyspray2trac: Operating System: All]
https://gitlab.torproject.org/tpo/core/tor/-/issues/960
Tor believes bridges are offline at startup
2020-06-27T14:09:58Z
Andrew Lewman
Tor believes bridges are offline at startup
[07:42:32] < phobos> [Info] should_delay_dir_fetches(): delaying dir fetches (no running bridges known)
[07:42:34] < phobos> lies
[07:43:17] < phobos> it's been doing this for 10 minutes
[07:43:29] < phobos> yet I can connect to the ...
[07:42:32] < phobos> [Info] should_delay_dir_fetches(): delaying dir fetches (no running bridges known)
[07:42:34] < phobos> lies
[07:43:17] < phobos> it's been doing this for 10 minutes
[07:43:29] < phobos> yet I can connect to the bridges just fine
[07:45:56] < killerchicken_> heh
[07:46:09] < killerchicken_> if we could debug this, that would solve a lot of problem reports we had
[07:46:59] < phobos> forcing an app request through it makes it try
[07:47:03] < phobos> and succeed
[07:48:27] < killerchicken_> ah
[07:48:28] < killerchicken_> * are marked with purpose 'bridge' and are running. Else return 0.
[07:48:37] < killerchicken_> ups
[07:48:40] < killerchicken_> ./** Return 1 if any of our entry guards have descriptors that
[07:51:30] < killerchicken_> hm
[07:52:35] < killerchicken_> I'd love to debug this more, but it has to wait... Have you made a bug report?
[07:53:04] < phobos> on my to do list
[07:53:22] < killerchicken_> ok
[07:55:10] < killerchicken_> I think the problem is inside the any_bridge_descriptors_known() / choose_random_entry() logic
[07:55:37] < killerchicken_> I'll look at it more if nobody else finds the time. Can you please add this stuff from here to the bug?
Log file says:
ar 27 07:42:12.269 [Info] should_delay_dir_fetches(): delaying dir fetches (no running bridges known)
Mar 27 07:42:23.309 [Info] should_delay_dir_fetches(): delaying dir fetches (no running bridges known)
Mar 27 07:42:28.329 [Info] routerlist_remove_old_routers(): We have 1203 live routers and 0 old router descriptors.
Mar 27 07:42:28.334 [Info] should_delay_dir_fetches(): delaying dir fetches (no running bridges known)
Mar 27 07:42:34.348 [Info] should_delay_dir_fetches(): delaying dir fetches (no running bridges known)
Mar 27 07:42:45.388 [Info] should_delay_dir_fetches(): delaying dir fetches (no running bridges known)
Mar 27 07:42:56.420 [Info] should_delay_dir_fetches(): delaying dir fetches (no running bridges known)
Mar 27 07:43:07.461 [Info] should_delay_dir_fetches(): delaying dir fetches (no running bridges known)
Mar 27 07:43:18.500 [Info] should_delay_dir_fetches(): delaying dir fetches (no running bridges known)
Mar 27 07:43:29.541 [Info] should_delay_dir_fetches(): delaying dir fetches (no running bridges known)
forcing an app request through tor creates:
Mar 27 07:46:14.173 [Info] should_delay_dir_fetches(): delaying dir fetches (no running bridges known)
Mar 27 07:46:16.197 [Notice] Application request when we're believed to be offline. Optimistically trying known bridges again.
Mar 27 07:46:16.210 [Info] connection_edge_process_inbuf(): data from edge while in 'waiting for circuit' state. Leaving it on buffer.
Mar 27 07:46:25.220 [Info] update_consensus_router_descriptor_downloads(): 3 router descriptors downloadable. 0 delayed; 1201 present (0 of those were in old_routers); 0 would_reject; 0 wouldnt_use; 0 in progress.
Mar 27 07:46:25.233 [Info] launch_router_descriptor_downloads(): There are not many downloadable routerdescs, but we haven't tried downloading descriptors recently. Downloading.
Mar 27 07:46:25.248 [Info] launch_router_descriptor_downloads(): Launching 1 request for 3 routers, 4 at a time
[Automatically added by flyspray2trac: Operating System: Other Linux]
Tor: 0.2.3.x-final
https://gitlab.torproject.org/tpo/core/tor/-/issues/962
bandwidth change makes relay publish but authorities discard
2020-06-27T14:09:58Z
Roger Dingledine
bandwidth change makes relay publish but authorities discard
Apr 01 09:45:39.145 [info] dirserv_add_descriptor(): Added descriptor from 'fluxe3' (source: 78.47.18.110): Valid server updated.
Apr 01 18:52:28.976 [info] dirserv_add_descriptor(): Not replacing descriptor from 'fluxe3' (source: 78.47....
Apr 01 09:45:39.145 [info] dirserv_add_descriptor(): Added descriptor from 'fluxe3' (source: 78.47.18.110): Valid server updated.
Apr 01 18:52:28.976 [info] dirserv_add_descriptor(): Not replacing descriptor from 'fluxe3' (source: 78.47.18.110); differences are cosmetic.
shahn> I also reloaded it at 22:52 on April 1st
>what exactly did you change?
shahn> RelayBandwidthRate 150 KBytes (was at 10000 or something insanely high)
shahn> and RelayBandwidthBurst 200 KBytes (was at 15000)
> see options_transition_affects_descriptor() in config.c
> If
> * you changed your bandwidthrate but maxadvertisedbandwidth still
> * trumps, no need to republish.
> as part of an XXX
> then compare to router_differences_are_cosmetic()
> any differences between these two functions will cause bugs like yours.
> in the latter, it does
> /* Did bandwidth change a lot? */
> if ((r1->bandwidthcapacity < r2->bandwidthcapacity/2) ||
> (r2->bandwidthcapacity < r1->bandwidthcapacity/2))
> return 0;
> in the former, it says "did they change at all"
what the relay should do is make a new descriptor, and then call
router-differences-are-cosmetic on it, and revert if cosmetic.
that way we're using the same function, rather than trying to keep the
checks the same in both cases.
[Automatically added by flyspray2trac: Operating System: All]
Tor: 0.2.3.x-final
https://gitlab.torproject.org/tpo/core/tor/-/issues/965
Redo DNS tests when exit policy changes from reject *; avoid when policy chan...
2020-06-27T14:09:58Z
Sebastian Hahn
Redo DNS tests when exit policy changes from reject *; avoid when policy changes to reject *
> hm. I published my descriptor before doing DNS tests. Also, I'm rejecting all exit
traffic, and still do DNS tests. Isn't that supposed to be different?
<armadev> i've had a todo item for nick to not do dns tests if reject *:*. he didn...
> hm. I published my descriptor before doing DNS tests. Also, I'm rejecting all exit
traffic, and still do DNS tests. Isn't that supposed to be different?
<armadev> i've had a todo item for nick to not do dns tests if reject *:*. he didn't
want to put it in, though.
<armadev> i think that you would need to remember whether you did them, and if
not launch them, if exit policy changes from reject * to something else
> Can't we just redo them every time exit policy changes from reject to something?
<armadev> fine by me. open a flyspray, due 0.2.2.x?
> (in theory, we should probably redo them when the IP changes. This could mean
Laptop user in a new environment)
[Automatically added by flyspray2trac: Operating System: All]
Tor: unspecified
https://gitlab.torproject.org/tpo/core/tor/-/issues/966
Do positive DNS tests
2020-06-27T14:09:57Z
Sebastian Hahn
Do positive DNS tests
<armadev> yep. do we do some 'positive' dns tests too? that is, if we can't
resolve google or cnn or akamai, maybe we can't resolve anything.
<armadev> mikeperry found some relays that can't resolve anything
Maybe we should add some mor...
<armadev> yep. do we do some 'positive' dns tests too? that is, if we can't
resolve google or cnn or akamai, maybe we can't resolve anything.
<armadev> mikeperry found some relays that can't resolve anything
Maybe we should add some more tests to see if some well-known sites can
be resolved. Also, we should probably wait with publishing the descriptor
until DNS tests have run.
[Automatically added by flyspray2trac: Operating System: All]
Tor: unspecified
https://gitlab.torproject.org/tpo/core/tor/-/issues/968
Directory authority in private Tor network doesn't publish consensus
2020-06-27T14:09:57Z
Karsten Loesing
Directory authority in private Tor network doesn't publish consensus
Under certain circumstances a single directory authority in a private Tor
network does not manage to publish a consensus. For some reason the
directory adds itself to the list of trusted directory authorities *twice*.
The result is that ...
Under certain circumstances a single directory authority in a private Tor
network does not manage to publish a consensus. For some reason the
directory adds itself to the list of trusted directory authorities *twice*.
The result is that it thinks there are 2 directories and that a single
vote is not enough to publish a consensus.
The directory triggers the following warning:
Index: src/or/routerlist.c
===================================================================
--- src/or/routerlist.c (revision 19258)
+++ src/or/routerlist.c (working copy)
@@ -3706,6 +3706,18 @@
hostname = tor_strdup(address);
}
+ SMARTLIST_FOREACH(trusted_dir_servers, trusted_dir_server_t *, ent, {
+ if (ent->v3_identity_digest &&
+ !memcmp(v3_auth_digest, ent->v3_identity_digest, DIGEST_LEN))
+ log_warn(LD_CONFIG, "We already have a directory with the same "
+ "v3 identity digest %s, address %s, OR port %d, and Dir port %d. "
+ "Now we try to add one with address %s, OR port %d, and Dir port %d. "
+ "Something is wrong here!",
+ hex_str(ent->v3_identity_digest, DIGEST_LEN),
+ ent->address, ent->or_port, ent->dir_port,
+ hostname, or_port, dir_port);
+ });
+
ent = tor_malloc_zero(sizeof(trusted_dir_server_t));
ent->nickname = nickname ? tor_strdup(nickname) : NULL;
ent->address = hostname;
A workaround is to add a return statement to that loop. But it would be
better to find out why the directory adds itself to the list twice.
[Automatically added by flyspray2trac: Operating System: All]
Tor: 0.2.3.x-final
Sebastian Hahn
Sebastian Hahn
https://gitlab.torproject.org/tpo/core/tor/-/issues/969
Directory authorities have different opinions on MTBF and WFU
2020-06-27T14:09:57Z
Karsten Loesing
Directory authorities have different opinions on MTBF and WFU
It has turned out that directory authorities have very different opinions
on relays' MTBF (mean time between failure) and WFU (weighted fractional
uptime). The result is that they vote differently on Guard and Stable
flags:
http://freeh...
It has turned out that directory authorities have very different opinions
on relays' MTBF (mean time between failure) and WFU (weighted fractional
uptime). The result is that they vote differently on Guard and Stable
flags:
http://freehaven.net/~karsten/metrics/relayflags-2009-04-01.pdf
One reason might be false assumptions about running relays as reflected in
the router-stability files. If a relay is running, the corresponding MTBF
line contains the starting time. The starting time is used to include the
running session in MTBF and WFU calculation. An analysis of three
router-stability files shows that authorities think there are between 6K
and 24K relays currently running, which is wrong:
$ grep "MTBF" ides-2009-04-14 | grep "S=" | wc -l
24082
$ grep "MTBF" gabelmoo-2009-04-15 | grep "S=" | wc -l
9206
$ grep "MTBF" moria1-2009-04-15 | grep "S=" | wc -l
6395
These lines are never removed from router-stability files, so that whenever
these relays come back, they appear to be uber-stable which they of course
are not.
The problem lies in the fact that this starting time is only set to 0 in a
few edge cases using rep_hist_note_router_unreachable() in rephist.c. This
function should be called whenever a relay has gone offline, which is of
course difficult to know.
As a possible solution, Tor could check during maintenance when a relay was
contacted the last time. If this time lies more than twice the reachability
timeout in the past, the relay should be marked as unreachable in
rephist.c, too. A simple patch (with some code duplication from
dirserv_set_router_is_running() in dirserv.c) would look like this:
Index: src/or/rephist.c
===================================================================
--- src/or/rephist.c (revision 19341)
+++ src/or/rephist.c (working copy)
@@ -658,6 +658,22 @@
digestmap_iter_get(orhist_it, &d1, &or_history_p);
or_history = or_history_p;
+#define DOUBLE_REACHABLE_TIMEOUT (2*45*60)
+ /* If we are an authority, check if this router is still running. */
+ if (authority && !or_history->start_of_run) {
+ char time_buf[ISO_TIME_LEN+1];
+ routerinfo_t *router = router_get_by_digest(d1);
+ if (!router || (router_is_me(router) && we_are_hibernating()) ||
+ (!get_options()->AssumeReachable &&
+ before >= router->last_reachable + DOUBLE_REACHABLE_TIMEOUT)) {
+ format_iso_time(time_buf, before);
+ log_info(LD_DIR, "When cleaning the reputation history at %s, "
+ "we found that router %s is not running anymore.",
+ time_buf, hex_str(d1, DIGEST_LEN));
+ rep_hist_note_router_unreachable(d1, before);
+ }
+ }
+ /* Now decide if we want to keep it. */
remove = authority ? (or_history->total_run_weights < STABILITY_EPSILON &&
!or_history->start_of_run)
: (or_history->changed < before);
[Automatically added by flyspray2trac: Operating System: All]
Karsten Loesing
Karsten Loesing
https://gitlab.torproject.org/tpo/core/tor/-/issues/973
OSX uninstall script misses some files
2020-06-27T14:09:57Z
Andrew Lewman
OSX uninstall script misses some files
From: Danny Thomas <d.thomas@its.uq.edu.au>
To: tor-volunteer@torproject.org
Subject: OSX uninstall_tor_bundle.sh does not remove everything
Date: Tue, 21 Apr 2009 09:11:44 +1000
Sender: owner-tor-assistants@torproject.org
User-Agent: Th...
From: Danny Thomas <d.thomas@its.uq.edu.au>
To: tor-volunteer@torproject.org
Subject: OSX uninstall_tor_bundle.sh does not remove everything
Date: Tue, 21 Apr 2009 09:11:44 +1000
Sender: owner-tor-assistants@torproject.org
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
on https://www.torproject.org/docs/tor-doc-osx.html.en
4 corrections
should be hyphen in "/usr/bin/tor_resolve"
should be 'P' in "/Library/Receipts/privoxyconf.pkg/"
doesn't mention /Applications/Vidalia.app
doesn't mention /Library/Receipts/Vidalia.pkg
Unfortunately I forgot to check the version I was uninstalling but
am fairly confidant it was installed from
vidalia-bundle-0.2.0.34-0.1.10-universal.dmg
after manually finishing the uninstall, I installed
vidalia-bundle-0.2.1.14-rc-0.1.12-universal
and confirmed that its' uninstall script behaved the same,
i.e. the following items were left
it might be better saying to run /Library/Tor/uninstall_tor_bundle.sh
as that script deletes the directory you're in
"Tor and Privoxy are now completely removed from your system."
well that wasn't the case for me
first off the script reported errors and I've no idea whether these
prevented
items from being uninstalled or whether the script does not include
everything to be removed
bash-3.2# ./uninstall_tor_bundle.sh
ps: No user named 'ax'
. tor process appears to already be stopped
ps: No user named 'ax'
. privoxy process appears to already be stopped
./uninstall_tor_bundle.sh: line 123: /Library/Tor/package_list.txt: No
such file or directory
. Removing created user _tor
delete: Invalid Path
<dscl_cmd> DS Error: -14009 (eDSUnknownNodeName)
. Cleaning up
. Finished
after that I found the following were still there
so I manually deleted them
ls /Library/Vidalia/
CHANGELOG CREDITS README
ls -l /usr/bin/tor*
lrwxr-xr-x 1 root wheel 16 23 Jan 08:10 /usr/bin/tor -> /Library/Tor/tor
lrwxr-xr-x 1 root wheel 24 23 Jan 08:10 /usr/bin/tor-resolve ->
/Library/Tor/
ls -l /var/log/tor*
-rw-rw---- 1 root daemon 0 20 Jan 2008 /var/log/tor.log
bash-3.2# ls -alR /Library/Receipts/Priv*
/Library/Receipts/Privoxy.pkg:
total 0
drwxrwxr-x 3 root admin 102 23 Jan 08:10 .
drwxrwxr-x 94 root admin 3196 21 Apr 06:45 ..
drwxrwxr-x 6 root admin 204 23 Jan 08:10 Contents
/Library/Receipts/Privoxy.pkg/Contents:
total 96
drwxrwxr-x 6 root admin 204 23 Jan 08:10 .
drwxrwxr-x 3 root admin 102 23 Jan 08:10 ..
-rw-rw-r-- 1 root admin 40388 22 Nov 2006 Archive.bom
-rw-rw-r-- 1 root admin 1283 23 Jan 08:10 Info.plist
-rw-rw-r-- 1 root admin 8 22 Nov 2006 PkgInfo
drwxrwxr-x 16 root admin 544 23 Jan 08:10 Resources
/Library/Receipts/Privoxy.pkg/Contents/Resources:
total 200
drwxrwxr-x 16 root admin 544 23 Jan 08:10 .
drwxrwxr-x 6 root admin 204 23 Jan 08:10 ..
drwxrwxr-x 7 root admin 238 23 Jan 08:10 CVS
-rw-rw-r-- 1 root admin 1053 22 Nov 2006 Description.plist
-rwxrwxr-x 1 root admin 15623 22 Nov 2006 License.html
-rw-rw-r-- 1 root admin 40388 22 Nov 2006 Privoxy.bom
-rw-rw-r-- 1 root admin 864 22 Nov 2006 Privoxy.info
-rwxrwxr-x 1 root admin 2247 22 Nov 2006 Privoxy.post_install
-rwxrwxr-x 1 root admin 2693 22 Nov 2006 Privoxy.post_upgrade
-rwxrwxr-x 1 root admin 10 22 Nov 2006 Privoxy.pre_upgrade
-rw-rw-r-- 1 root admin 46 22 Nov 2006 Privoxy.sizes
-rwxrwxr-x 1 root admin 861 22 Nov 2006 ReadMe.txt
-rwxrwxr-x 1 root admin 2247 22 Nov 2006 postinstall
-rwxrwxr-x 1 root admin 2693 22 Nov 2006 postupgrade
-rwxrwxr-x 1 root admin 10 22 Nov 2006 preupgrade
-rwxrwxr-x 1 root admin 401 22 Nov 2006 welcome.txt
/Library/Receipts/Privoxy.pkg/Contents/Resources/CVS:
total 24
drwxrwxr-x 7 root admin 238 23 Jan 08:10 .
drwxrwxr-x 16 root admin 544 23 Jan 08:10 ..
drwxrwxr-x 2 root admin 68 23 Jan 08:10 Base
-rwxrwxr-x 1 root admin 0 22 Nov 2006 Baserev
-rwxrwxr-x 1 root admin 263 22 Nov 2006 Entries
-rwxrwxr-x 1 root admin 16 22 Nov 2006 Repository
-rwxrwxr-x 1 root admin 66 22 Nov 2006 Root
/Library/Receipts/Privoxy.pkg/Contents/Resources/CVS/Base:
total 0
drwxrwxr-x 2 root admin 68 23 Jan 08:10 .
drwxrwxr-x 7 root admin 238 23 Jan 08:10 ..
/Library/Receipts/PrivoxyConf.pkg:
total 0
drwxrwxr-x 3 root admin 102 23 Jan 08:10 .
drwxrwxr-x 94 root admin 3196 21 Apr 06:45 ..
drwxrwxr-x 6 root admin 204 23 Jan 08:10 Contents
/Library/Receipts/PrivoxyConf.pkg/Contents:
total 88
drwxrwxr-x 6 root admin 204 23 Jan 08:10 .
drwxrwxr-x 3 root admin 102 23 Jan 08:10 ..
-rw-rw-r-- 1 root admin 35268 3 Dec 12:07 Archive.bom
-rw-rw-r-- 1 root admin 1329 23 Jan 08:10 Info.plist
-rw-rw-r--@ 1 root admin 9 3 Dec 12:07 PkgInfo
drwxrwxr-x 5 root admin 170 23 Jan 08:10 Resources
/Library/Receipts/PrivoxyConf.pkg/Contents/Resources:
total 16
drwxrwxr-x 5 root admin 170 23 Jan 08:10 .
drwxrwxr-x 6 root admin 204 23 Jan 08:10 ..
drwxrwxr-x 3 root admin 102 23 Jan 08:10 en.lproj
-rw-rw-r--@ 1 root admin 17 3 Dec 12:07 package_version
-rwxrwxr-x 1 root admin 423 3 Dec 12:07 postflight
/Library/Receipts/PrivoxyConf.pkg/Contents/Resources/en.lproj:
total 8
drwxrwxr-x 3 root admin 102 23 Jan 08:10 .
drwxrwxr-x 5 root admin 170 23 Jan 08:10 ..
-rw-rw-r-- 1 root admin 387 3 Dec 12:07 Description.plist
bash-3.2# ls -al /Library/Receipts/Tor.pkg
total 0
drwxrwxr-x 3 root admin 102 23 Jan 08:10 .
drwxrwxr-x 92 root admin 3128 21 Apr 08:42 ..
drwxrwxr-x 6 root admin 204 23 Jan 08:10 Contents
bash-3.2# ls -alR /Library/Receipts/Tor.pkg
total 0
drwxrwxr-x 3 root admin 102 23 Jan 08:10 .
drwxrwxr-x 92 root admin 3128 21 Apr 08:42 ..
drwxrwxr-x 6 root admin 204 23 Jan 08:10 Contents
/Library/Receipts/Tor.pkg/Contents:
total 88
drwxrwxr-x 6 root admin 204 23 Jan 08:10 .
drwxrwxr-x 3 root admin 102 23 Jan 08:10 ..
-rw-rw-r-- 1 root admin 36008 3 Dec 12:07 Archive.bom
-rw-rw-r-- 1 root admin 1399 23 Jan 08:10 Info.plist
-rw-rw-r--@ 1 root admin 9 3 Dec 12:07 PkgInfo
drwxrwxr-x 9 root admin 306 23 Jan 08:10 Resources
/Library/Receipts/Tor.pkg/Contents/Resources:
total 48
drwxrwxr-x 9 root admin 306 23 Jan 08:10 .
drwxrwxr-x 6 root admin 204 23 Jan 08:10 ..
-rw-rw-r-- 1 root admin 3555 3 Dec 12:07 Tor_Uninstaller.applescript
drwxrwxr-x 7 root admin 238 23 Jan 08:10 documents
drwxrwxr-x 3 root admin 102 23 Jan 08:10 en.lproj
-rw-rw-r-- 1 root admin 53 3 Dec 12:07 package_list.txt
-rw-rw-r--@ 1 root admin 17 3 Dec 12:07 package_version
-rwxrwxr-x 1 root admin 1942 3 Dec 12:07 postflight
-rwxrwxr-x 1 root admin 4854 3 Dec 12:07 uninstall_tor_bundle.sh
/Library/Receipts/Tor.pkg/Contents/Resources/documents:
total 632
drwxrwxr-x 7 root admin 238 23 Jan 08:10 .
drwxrwxr-x 9 root admin 306 23 Jan 08:10 ..
-rw-rw-r-- 1 root admin 1305 3 Dec 12:07 AUTHORS.txt
drwxrwxr-x 11 root admin 374 23 Jan 08:10 Advanced
drwxrwxr-x 25 root admin 850 23 Jan 08:10 howto
-rw-rw-r-- 1 root admin 238952 3 Dec 12:07 tor-reference.pdf
-rw-rw-r-- 1 root admin 75588 3 Dec 12:07 tor-resolve.pdf
/Library/Receipts/Tor.pkg/Contents/Resources/documents/Advanced:
total 1032
drwxrwxr-x 11 root admin 374 23 Jan 08:10 .
drwxrwxr-x 7 root admin 238 23 Jan 08:10 ..
-rw-rw-r-- 1 root admin 341563 3 Dec 12:07 ChangeLog.txt
-rw-rw-r-- 1 root admin 5025 3 Dec 12:07 HACKING.txt
-rw-rw-r-- 1 root admin 2429 3 Dec 12:07 address-spec.txt
-rw-rw-r-- 1 root admin 64214 3 Dec 12:07 control-spec.txt
-rw-rw-r-- 1 root admin 19815 3 Dec 12:07 path-spec.txt
-rw-rw-r-- 1 root admin 35398 3 Dec 12:07 rend-spec.txt
-rw-rw-r-- 1 root admin 3339 3 Dec 12:07 socks-extensions.txt
-rw-rw-r-- 1 root admin 38209 3 Dec 12:07 tor-spec.txt
-rw-rw-r-- 1 root admin 2202 3 Dec 12:07 version-spec.txt
/Library/Receipts/Tor.pkg/Contents/Resources/documents/howto:
total 592
drwxrwxr-x 25 root admin 850 23 Jan 08:10 .
drwxrwxr-x 7 root admin 238 23 Jan 08:10 ..
-rw-rw-r-- 1 root admin 6172 3 Dec 12:07 stylesheet.css
-rw-rw-r-- 1 root admin 12010 3 Dec 12:07 tor-doc-osx.html.en
-rw-rw-r-- 1 root admin 12703 3 Dec 12:07 tor-doc-osx.html.es
-rw-rw-r-- 1 root admin 13522 3 Dec 12:07 tor-doc-osx.html.fr
-rw-rw-r-- 1 root admin 12545 3 Dec 12:07 tor-doc-osx.html.it
-rw-rw-r-- 1 root admin 13100 3 Dec 12:07 tor-doc-osx.html.pl
-rw-rw-r-- 1 root admin 17426 3 Dec 12:07 tor-doc-server.html.de
-rw-rw-r-- 1 root admin 3674 3 Dec 12:07 tor-doc-server.html.en
-rw-rw-r-- 1 root admin 4005 3 Dec 12:07 tor-doc-server.html.fr
-rw-rw-r-- 1 root admin 3996 3 Dec 12:07 tor-doc-server.html.it
-rw-rw-r-- 1 root admin 4043 3 Dec 12:07 tor-doc-server.html.pl
-rw-rw-r-- 1 root admin 4139 3 Dec 12:07 tor-doc-server.html.ru
-rw-rw-r-- 1 root admin 13830 3 Dec 12:07 tor-hidden-service.html.en
-rw-rw-r-- 1 root admin 14628 3 Dec 12:07 tor-hidden-service.html.es
-rw-rw-r-- 1 root admin 15816 3 Dec 12:07 tor-hidden-service.html.fr
-rw-rw-r-- 1 root admin 14471 3 Dec 12:07 tor-hidden-service.html.it
-rw-rw-r-- 1 root admin 15293 3 Dec 12:07 tor-hidden-service.html.pl
-rw-rw-r-- 1 root admin 20757 3 Dec 12:07 tor-hidden-service.html.ru
-rw-rw-r-- 1 root admin 13806 3 Dec 12:07 tor-hidden-service.html.zh-cn
-rw-rw-r-- 1 root admin 9267 3 Dec 12:07 tor-switchproxy.html.en
-rw-rw-r-- 1 root admin 9892 3 Dec 12:07 tor-switchproxy.html.es
-rw-rw-r-- 1 root admin 10000 3 Dec 12:07 tor-switchproxy.html.it
-rw-rw-r-- 1 root admin 10287 3 Dec 12:07 tor-switchproxy.html.pl
/Library/Receipts/Tor.pkg/Contents/Resources/en.lproj:
total 8
drwxrwxr-x 3 root admin 102 23 Jan 08:10 .
drwxrwxr-x 9 root admin 306 23 Jan 08:10 ..
-rw-rw-r-- 1 root admin 366 3 Dec 12:07 Description.plist
bash-3.2# ls -alR /Library/Receipts/torbutton.pkg
total 0
drwxrwxr-x 3 root admin 102 23 Jan 08:10 .
drwxrwxr-x 91 root admin 3094 21 Apr 08:44 ..
drwxrwxr-x 6 root admin 204 23 Jan 08:10 Contents
torbutton.pkg//Contents:
total 88
drwxrwxr-x 6 root admin 204 23 Jan 08:10 .
drwxrwxr-x 3 root admin 102 23 Jan 08:10 ..
-rw-rw-r-- 1 root admin 35293 3 Dec 12:07 Archive.bom
-rw-rw-r-- 1 root admin 1336 23 Jan 08:10 Info.plist
-rw-rw-r--@ 1 root admin 9 3 Dec 12:07 PkgInfo
drwxrwxr-x 4 root admin 136 23 Jan 08:10 Resources
torbutton.pkg//Contents/Resources:
total 8
drwxrwxr-x 4 root admin 136 23 Jan 08:10 .
drwxrwxr-x 6 root admin 204 23 Jan 08:10 ..
drwxrwxr-x 3 root admin 102 23 Jan 08:10 en.lproj
-rw-rw-r--@ 1 root admin 17 3 Dec 12:07 package_version
torbutton.pkg//Contents/Resources/en.lproj:
total 8
drwxrwxr-x 3 root admin 102 23 Jan 08:10 .
drwxrwxr-x 4 root admin 136 23 Jan 08:10 ..
-rw-rw-r-- 1 root admin 389 3 Dec 12:07 Description.plist
bash-3.2# ls -alR /Library/Receipts/Vidalia.pkg/
total 0
drwxrwxr-x 3 root admin 102 23 Jan 08:10 .
drwxrwxr-x 90 root admin 3060 21 Apr 08:45 ..
drwxrwxr-x 6 root admin 204 23 Jan 08:10 Contents
/Library/Receipts/Vidalia.pkg//Contents:
total 88
drwxrwxr-x 6 root admin 204 23 Jan 08:10 .
drwxrwxr-x 3 root admin 102 23 Jan 08:10 ..
-rw-rw-r-- 1 root admin 35970 3 Dec 12:07 Archive.bom
-rw-rw-r-- 1 root admin 1585 23 Jan 08:10 Info.plist
-rw-rw-r--@ 1 root admin 9 3 Dec 12:07 PkgInfo
drwxrwxr-x 5 root admin 170 23 Jan 08:10 Resources
/Library/Receipts/Vidalia.pkg//Contents/Resources:
total 16
drwxrwxr-x 5 root admin 170 23 Jan 08:10 .
drwxrwxr-x 6 root admin 204 23 Jan 08:10 ..
-rw-rw-r-- 1 root admin 379 3 Dec 12:07 TokenDefinitions.plist
drwxrwxr-x 3 root admin 102 23 Jan 08:10 en.lproj
-rw-rw-r--@ 1 root admin 17 3 Dec 12:07 package_version
/Library/Receipts/Vidalia.pkg//Contents/Resources/en.lproj:
total 8
drwxrwxr-x 3 root admin 102 23 Jan 08:10 .
drwxrwxr-x 5 root admin 170 23 Jan 08:10 ..
-rw-rw-r-- 1 root admin 368 3 Dec 12:07 Descrip
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]
Andrew Lewman
Andrew Lewman
https://gitlab.torproject.org/tpo/core/tor/-/issues/974
TBB 1.1.13-dev contains invalid preferences
2020-06-27T14:09:57Z
Andrew Lewman
TBB 1.1.13-dev contains invalid preferences
it appears that invalidprefs.js file is being generated, which is overriding some of
the prefs we set
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
it appears that invalidprefs.js file is being generated, which is overriding some of
the prefs we set
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
Andrew Lewman
Andrew Lewman
https://gitlab.torproject.org/tpo/core/tor/-/issues/977
buf_shrink_freelists: Assertion !n_to_free failed
2020-06-27T14:09:57Z
Roger Dingledine
buf_shrink_freelists: Assertion !n_to_free failed
dr|z3d> Nasty Tor crash: "May 05 21:08:52.448 [Error] Bug: buffers.c:281:
buf_shrink_freelists: Assertion !n_to_free failed; aborting."
It was 0.2.1.14-rc on Windows.
"DNSPort and 1 hidden service. Run from Vidalia, so ControlPort was ...
dr|z3d> Nasty Tor crash: "May 05 21:08:52.448 [Error] Bug: buffers.c:281:
buf_shrink_freelists: Assertion !n_to_free failed; aborting."
It was 0.2.1.14-rc on Windows.
"DNSPort and 1 hidden service. Run from Vidalia, so ControlPort was set too.
A few IRC connections, and probably idle other than that.
[Automatically added by flyspray2trac: Operating System: All]
https://gitlab.torproject.org/tpo/core/tor/-/issues/978
DirPortFrontPage gives 503 on loaded dirmirror
2020-06-27T14:09:57Z
Sebastian Hahn
DirPortFrontPage gives 503 on loaded dirmirror
When configuring DirPortFrontPage, a loaded mirror will return a 503
consistently when the DirPort is hit. A browser will simply display a
white page and not indicate the error condition at all, so the output
can be surprising to the ave...
When configuring DirPortFrontPage, a loaded mirror will return a 503
consistently when the DirPort is hit. A browser will simply display a
white page and not indicate the error condition at all, so the output
can be surprising to the average user. If we cannot "fix" this, at least
warning the user is probably a sane idea.
[Automatically added by flyspray2trac: Operating System: All]
https://gitlab.torproject.org/tpo/core/tor/-/issues/981
Proxy Info does not get cleared
2020-06-27T14:09:57Z
Trac
Proxy Info does not get cleared
I entered a proxy setting for tor during a visit to an office. Once I left that office, I could no longer connect to tor.
The error message is that it's still trying to find the proxy for https settings, and the server doesn't exist
(n...
I entered a proxy setting for tor during a visit to an office. Once I left that office, I could no longer connect to tor.
The error message is that it's still trying to find the proxy for https settings, and the server doesn't exist
(nor does it resolve)
[Automatically added by flyspray2trac: Operating System: Windows Vista]
**Trac**:
**Username**: laxamar
https://gitlab.torproject.org/tpo/core/tor/-/issues/982
Crash in closing tls connection
2020-06-27T14:09:56Z
Trac
Crash in closing tls connection
Happens seemingly at random after a long go of running.
"""
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you ar...
Happens seemingly at random after a long go of running.
"""
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...
warning: Can't read pathname for load map: Input/output error.
Reading symbols from /lib/libz.so.1...done.
Loaded symbols for /lib/libz.so.1
Reading symbols from /usr/lib/libevent-1.3e.so.1...done.
Loaded symbols for /usr/lib/libevent-1.3e.so.1
Reading symbols from /lib/libssl.so.0.9.8...done.
Loaded symbols for /lib/libssl.so.0.9.8
Reading symbols from /lib/libcrypto.so.0.9.8...done.
Loaded symbols for /lib/libcrypto.so.0.9.8
Reading symbols from /lib/libpthread.so.0...done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/libnsl.so.1...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/librt.so.1...done.
Loaded symbols for /lib/librt.so.1
Reading symbols from /lib/libresolv.so.2...done.
Loaded symbols for /lib/libresolv.so.2
Reading symbols from /lib/ld-linux-x86-64.so.2...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /lib/libnss_compat.so.2...done.
Loaded symbols for /lib/libnss_compat.so.2
Reading symbols from /lib/libnss_nis.so.2...done.
Loaded symbols for /lib/libnss_nis.so.2
Reading symbols from /lib/libnss_files.so.2...done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /lib/libnss_mdns4_minimal.so.2...done.
Loaded symbols for /lib/libnss_mdns4_minimal.so.2
Reading symbols from /lib/libnss_dns.so.2...done.
Loaded symbols for /lib/libnss_dns.so.2
Reading symbols from /lib/libgcc_s.so.1...done.
Loaded symbols for /lib/libgcc_s.so.1
Core was generated by `/usr/sbin/tor'.
Program terminated with signal 11, Segmentation fault.
[New process 16346]
[New process 23317]
[New process 23318]
[New process 23320]
[New process 23319]
#0 0x00007f9792a80693 in CRYPTO_add_lock () from /lib/libcrypto.so.0.9.8
(gdb) bt
#0 0x00007f9792a80693 in CRYPTO_add_lock () from /lib/libcrypto.so.0.9.8
#1 0x00007f9792aebc29 in EVP_PKEY_free () from /lib/libcrypto.so.0.9.8
legacy/trac#2 0x00007f9792dd8771 in ssl_cert_free () from /lib/libssl.so.0.9.8
legacy/trac#3 0x00007f9792dd71d8 in SSL_free () from /lib/libssl.so.0.9.8
legacy/trac#4 0x00000000004b6ab3 in tor_tls_free (tls=0x2159fa0) at tortls.c:922
legacy/trac#5 0x00000000004280bf in _connection_free (conn=0x50720d0) at connection.c:388
legacy/trac#6 0x000000000046093c in close_closeable_connections () at main.c:602
legacy/trac#7 0x0000000000461033 in second_elapsed_callback (fd=<value optimized out>, event=<value optimized out>, args=<value optimized out>)
at main.c:1094
legacy/trac#8 0x00007f9792ff867d in event_base_loop () from /usr/lib/libevent-1.3e.so.1
legacy/trac#9 0x00000000004619c6 in do_main_loop () at main.c:1435
legacy/trac#10 0x0000000000461c15 in tor_main (argc=1, argv=<value optimized out>) at main.c:2060
legacy/trac#11 0x00007f97922a65a6 in __libc_start_main () from /lib/libc.so.6
legacy/trac#12 0x0000000000407469 in _start ()
(gdb) info frame 4
Stack frame at 0x7fff9b642140:
rip = 0x4b6ab3 in tor_tls_free (tortls.c:922); saved rip 0x4280bf
called by frame at 0x7fff9b642180, caller of frame at 0x7fff9b642120
source language c.
Arglist at 0x7fff9b642118, args: tls=0x2159fa0
Locals at 0x7fff9b642118, Previous frame's sp is 0x7fff9b642140
Saved registers:
rbx at 0x7fff9b642130, rip at 0x7fff9b642138
(gdb) f 4
legacy/trac#4 0x00000000004b6ab3 in tor_tls_free (tls=0x2159fa0) at tortls.c:922
922 tortls.c: No such file or directory.
in tortls.c
(gdb) p *tls
$1 = {node = {hte_next = 0x0, hte_hash = 31986572}, context = 0x7f97883ce9f0, ssl = 0x7a04e30, socket = 1382, address = 0x7c344f0 "[scrubbed]",
state = TOR_TLS_ST_OPEN, isServer = 1, wasV2Handshake = 1, got_renegotiate = 0, wantwrite_n = 0, last_write_count = 130436,
last_read_count = 9660, negotiated_callback = 0, callback_arg = 0x0}
"""
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: neoeinstein
Tor: 0.2.2.x-final
https://gitlab.torproject.org/tpo/core/tor/-/issues/983
Abort crash in libcrypto malloc during onion handshake
2020-06-27T14:09:56Z
Trac
Abort crash in libcrypto malloc during onion handshake
Occurred after ~15 hours of uptime on an x86_64 box.
I keep all cores archived, so if you have requests for me
to run against the core, let me know.
"""
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv...
Occurred after ~15 hours of uptime on an x86_64 box.
I keep all cores archived, so if you have requests for me
to run against the core, let me know.
"""
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...
warning: Can't read pathname for load map: Input/output error.
Reading symbols from /lib/libz.so.1...done.
Loaded symbols for /lib/libz.so.1
Reading symbols from /usr/lib/libevent-1.3e.so.1...done.
Loaded symbols for /usr/lib/libevent-1.3e.so.1
Reading symbols from /lib/libssl.so.0.9.8...done.
Loaded symbols for /lib/libssl.so.0.9.8
Reading symbols from /lib/libcrypto.so.0.9.8...done.
Loaded symbols for /lib/libcrypto.so.0.9.8
Reading symbols from /lib/libpthread.so.0...done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/libnsl.so.1...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/librt.so.1...done.
Loaded symbols for /lib/librt.so.1
Reading symbols from /lib/libresolv.so.2...done.
Loaded symbols for /lib/libresolv.so.2
Reading symbols from /lib/ld-linux-x86-64.so.2...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /lib/libnss_compat.so.2...done.
Loaded symbols for /lib/libnss_compat.so.2
Reading symbols from /lib/libnss_nis.so.2...done.
Loaded symbols for /lib/libnss_nis.so.2
Reading symbols from /lib/libnss_files.so.2...done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /lib/libnss_mdns4_minimal.so.2...done.
Loaded symbols for /lib/libnss_mdns4_minimal.so.2
Reading symbols from /lib/libnss_dns.so.2...done.
Loaded symbols for /lib/libnss_dns.so.2
Reading symbols from /lib/libgcc_s.so.1...done.
Loaded symbols for /lib/libgcc_s.so.1
Core was generated by `/usr/sbin/tor'.
Program terminated with signal 6, Aborted.
[New process 3611]
[New process 19395]
[New process 3612]
[New process 3614]
[New process 3613]
#0 0x00007fd0ea7cbfb5 in raise () from /lib/libc.so.6
(gdb) bt
#0 0x00007fd0ea7cbfb5 in raise () from /lib/libc.so.6
#1 0x00007fd0ea7cdbc3 in abort () from /lib/libc.so.6
legacy/trac#2 0x00007fd0ea80b228 in ?? () from /lib/libc.so.6
legacy/trac#3 0x00007fd0ea811b2c in ?? () from /lib/libc.so.6
legacy/trac#4 0x00007fd0ea8138f1 in ?? () from /lib/libc.so.6
legacy/trac#5 0x00007fd0ea815828 in malloc () from /lib/libc.so.6
legacy/trac#6 0x00007fd0eaf91f33 in CRYPTO_malloc () from /lib/libcrypto.so.0.9.8
legacy/trac#7 0x00007fd0eafbc18f in BN_mod_exp_mont_consttime () from /lib/libcrypto.so.0.9.8
legacy/trac#8 0x00007fd0eafd8925 in ?? () from /lib/libcrypto.so.0.9.8
legacy/trac#9 0x00007fd0eafd92ab in ?? () from /lib/libcrypto.so.0.9.8
legacy/trac#10 0x00000000004b1786 in crypto_pk_private_decrypt (env=<value optimized out>, to=<value optimized out>, from=0x8 <Address 0x8 out of bounds>,
fromlen=518, padding=<value optimized out>, warnOnFailure=0) at crypto.c:762
legacy/trac#11 0x00000000004b2a7e in crypto_pk_private_hybrid_decrypt (env=0x16207c0, to=0x7fd0e9633c30 "",
from=0x7fd0e9633e70 "s\214\235½aNàÇå¯\030\adlf\233\021\206\\+\035\203{h ëÈâ\203AÉ®?\225Ï¢éôA\232ÙREC¨ÿÚÜí>¨\003\226ÚÔCd0¢1\211û~ÎMÖ\213W\t¿WB\223põ\024Ï3>è:rÆ\036\234.\233Á(2C3É,,\224ìÅ&.\\\237ÝÑ\017I\r/⸺\207\032\225\002\205á_}0\206o\005JÊÆ\216\234Ò]÷ÿ\231Ïß¡¾çWz\223\213\215j®\026ÐY<ç/µ<½\037âón¨\026ôÚfZBc4\031\b\221±ál\217Ùõ8Ç}\032ägæÂ{*", fromlen=186, padding=60002, warnOnFailure=0) at crypto.c:989
legacy/trac#12 0x0000000000466b85 in onion_skin_server_handshake (
onion_skin=0x7fd0e9633e70 "s\214\235½aNàÇå¯\030\adlf\233\021\206\\+\035\203{h ëÈâ\203AÉ®?\225Ï¢éôA\232ÙREC¨ÿÚÜí>¨\003\226ÚÔCd0¢1\211û~ÎMÖ\213W\t¿WB\223põ\024Ï3>è:rÆ\036\234.\233Á(2C3É,,\224ìÅ&.\\\237ÝÑ\017I\r/⸺\207\032\225\002\205á_}0\206o\005JÊÆ\216\234Ò]÷ÿ\231Ïß¡¾çWz\223\213\215j®\026ÐY<ç/µ<½\037âón¨\026ôÚfZBc4\031\b\221±ál\217Ùõ8Ç}\032ägæÂ{*", private_key=0x16207c0, prev_private_key=0x0,
handshake_reply_out=0x7fd0e9633f30 "å\002õ\006(Gf.%1|cÛL? IÜ\204g\031\036Å\016½\217\234µå9\215uEàCʨ¾Íá©xð\201)\f\233Ó\020ÃÎ\037¶\0041Z",
key_out=0x7fd0e9633fd0 "ãJ(v|ÈßBdð-3v\005QÛ\202±\211\022\205J&\0247öI\233\027G¥\034ƶÇ\022,#ÆïDJ*þ®,\vRú\217ûU\005$s>=MtßWßõò²ú\022\217:ÍHú",
key_out_len=72) at onion.c:232
legacy/trac#13 0x000000000044062a in cpuworker_main (data=<value optimized out>) at cpuworker.c:273
legacy/trac#14 0x00000000004a6ab5 in tor_pthread_helper_fn (_data=0x1620220) at compat.c:1694
legacy/trac#15 0x00007fd0ead163ba in start_thread () from /lib/libpthread.so.0
legacy/trac#16 0x00007fd0ea87efcd in clone () from /lib/libc.so.6
legacy/trac#17 0x0000000000000000 in ?? ()
"""
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: neoeinstein
https://gitlab.torproject.org/tpo/core/tor/-/issues/984
Tor using forbidden nodes
2020-06-27T14:09:56Z
Trac
Tor using forbidden nodes
Hello.
I have this in my torcc:
ExcludeNodes {us},{gb},{cn},{au}
but my log is showing this kind of lines:
[Warning] Requested exit node 'thegoddamnpenisblue' is in ExcludeNodes, or ExcludeExitNodes, using anyway.
[Warning] Requested exi...
Hello.
I have this in my torcc:
ExcludeNodes {us},{gb},{cn},{au}
but my log is showing this kind of lines:
[Warning] Requested exit node 'thegoddamnpenisblue' is in ExcludeNodes, or ExcludeExitNodes, using anyway.
[Warning] Requested exit node 'userbw20prfpis' is in ExcludeNodes, or ExcludeExitNodes, using anyway.
I'm also running as a relay, but this happened also when I was running Tor as client-only.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: G-Lo
0.2.1.x-final
https://gitlab.torproject.org/tpo/core/tor/-/issues/985
libevent error - Tor not starting - 0.2.0.26-rc works!
2020-06-27T14:09:56Z
Trac
libevent error - Tor not starting - 0.2.0.26-rc works!
Temporarily, I have to use 0.2.0.26-rc (r14597) until the libevent error is fixed as in:
https://bugs.torproject.org/flyspray/index.php?do=details&id=792
I went back one revision at a time from this ftp server:
ftp://ftp.osmirror.nl/p...
Temporarily, I have to use 0.2.0.26-rc (r14597) until the libevent error is fixed as in:
https://bugs.torproject.org/flyspray/index.php?do=details&id=792
I went back one revision at a time from this ftp server:
ftp://ftp.osmirror.nl/pub/tor/win32/
[Automatically added by flyspray2trac: Operating System: Windows Vista]
**Trac**:
**Username**: 80063r
https://gitlab.torproject.org/tpo/core/tor/-/issues/987
eventdns can't strerror() on windows?
2020-06-27T14:09:56Z
Roger Dingledine
eventdns can't strerror() on windows?
Mai 24 12:59:01.875 [Warnung] eventdns: Error Unknown error (10054) while reading request.
the line in question seems to be:
log(EVDNS_LOG_WARN, "Error %s (%d) while reading request.",
strerror(err), err);
Do we want a Windows-sty...
Mai 24 12:59:01.875 [Warnung] eventdns: Error Unknown error (10054) while reading request.
the line in question seems to be:
log(EVDNS_LOG_WARN, "Error %s (%d) while reading request.",
strerror(err), err);
Do we want a Windows-style tor_socket_strerror() wrapper here?
(and probably a variety of other places in eventdns)
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
https://gitlab.torproject.org/tpo/core/tor/-/issues/991
Unit tests broken in Tor master
2020-06-27T14:09:55Z
Sebastian Hahn
Unit tests broken in Tor master
<sebastian> unit tests in master are broken
<sebastian> 5f03d6c547629af73dea2cfdaf888bc3a7caab5d is first bad commit
<sebastian> commit 5f03d6c547629af73dea2cfdaf888bc3a7caab5d
<sebastian> Author: Karsten Loesing <karsten.loesing@gmx.net...
<sebastian> unit tests in master are broken
<sebastian> 5f03d6c547629af73dea2cfdaf888bc3a7caab5d is first bad commit
<sebastian> commit 5f03d6c547629af73dea2cfdaf888bc3a7caab5d
<sebastian> Author: Karsten Loesing <karsten.loesing@gmx.net>
<sebastian> Date: Tue May 26 21:41:42 2009 +0200
<sebastian> I'll look into fixing that tomorrow night if no-one else gets around to it
unit test output:
============================== geoip
..............
File test.c: line 4630 (test_geoip): Assertion failed: ("zz=24,ab=16,xy=8"==s)
("zz=24,ab=16,xy=8" != "ab=16")
make: *** [test] Error 1
[Automatically added by flyspray2trac: Operating System: All]
https://gitlab.torproject.org/tpo/core/tor/-/issues/996
tor-0.2.1.14-rc dies on SIGILL shortly after receiving SIGHUP
2020-06-27T14:09:55Z
Trac
tor-0.2.1.14-rc dies on SIGILL shortly after receiving SIGHUP
This bug report submitted on behalf of Scott.
On two successive tor runs as a relay, tor terminated abnormally on
SIGILL after receiving a SIGHUP. The operating system is FreeBSD
7-STABLE, and tor is 0.2.1.14-rc. A SIGHUP was sent to...
This bug report submitted on behalf of Scott.
On two successive tor runs as a relay, tor terminated abnormally on
SIGILL after receiving a SIGHUP. The operating system is FreeBSD
7-STABLE, and tor is 0.2.1.14-rc. A SIGHUP was sent to tor, which
issued the following messages to /var/log/notices.log in the second
case.
Jun 04 10:36:10.957 [notice] Received reload signal (hup). Reloading config and resetting internal state.
Jun 04 10:36:10.966 [notice] Tor 0.2.1.14-rc (r19307) opening log file.
Jun 04 10:36:10.966 [warn] Can't log to stdout with RunAsDaemon set; skipping stdout
Jun 04 10:36:10.966 [warn] Can't log to stdout with RunAsDaemon set; skipping stdout
It then terminated on a SIGILL, leaving a tor.core file in /var/db/tor,
and the FreeBSD kernel noted the following in /var/log/messages.
Jun 4 10:36:12 hellas kernel: pid 16788 (tor), uid 256: exited on signal 4 (core dumped)
The first case did exactly the same with, of course, different date and
timestamps and a different pid in the messages. In each case, I
appended the date to the name of the tor.core file to prevent it from
being overwritten/replaced by any later occurrence of this crash. The
two tor.core files do have different sizes:
-rw------- 1 _tor _tor 30973952 Jun 3 03:28 tor.core.03jun2009
-rw------- 1 _tor _tor 68128768 Jun 4 10:36 tor.core.04jun2009
gdb backtraces are shown for each tor.core file in the typescript file
below.
Script started on Fri Jun 5 00:40:45 2009
hellas# gdb /usr/local/bin/tor tor.core.03jun2009
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...
Core was generated by `tor'.
Program terminated with signal 4, Illegal instruction.
Reading symbols from /lib/libz.so.4...done.
Loaded symbols for /lib/libz.so.4
Reading symbols from /usr/local/lib/libevent-1.4.so.3...done.
Loaded symbols for /usr/local/lib/libevent-1.4.so.3
Reading symbols from /usr/lib/libssl.so.5...done.
Loaded symbols for /usr/lib/libssl.so.5
Reading symbols from /lib/libcrypto.so.5...done.
Loaded symbols for /lib/libcrypto.so.5
Reading symbols from /lib/libthr.so.3...done.
Loaded symbols for /lib/libthr.so.3
Reading symbols from /lib/libc.so.7...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /usr/lib/librt.so.1...done.
Loaded symbols for /usr/lib/librt.so.1
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0 0x080b0f1e in policies_parse_from_options (options=0x3499bc00)
at policies.c:431
431 if (load_policy_from_option(options->DirPolicy, &dir_policy, -1) < 0)
[New Thread 0x34102030 (LWP 100195)]
[New Thread 0x34101f20 (LWP 100194)]
[New Thread 0x34101040 (LWP 100193)]
(gdb) bt
#0 0x080b0f1e in policies_parse_from_options (options=0x3499bc00)
at policies.c:431
#1 0x08068824 in options_act (old_options=0x34123400) at config.c:1298
#2 0x080697b6 in set_options (new_val=0x3499bc00, msg=0xbfbfe4a8)
at config.c:807
#3 0x0806a262 in options_init_from_string (
cf=0x344f1000 "## Configuration file for a typical Tor user\n## Last updated 8 October 2006 for Tor 0.1.2.3-alpha.\n## (May or may not work for older or newer versions of Tor.)\n##\n## Lines that begin with \"## \" try to"...,
command=0, command_arg=0x0, msg=0xbfbfe4a8) at config.c:4087
#4 0x0806a909 in options_init_from_torrc (argc=11, argv=0xbfbfe694)
at config.c:3961
#5 0x080a715c in signal_callback (fd=1, events=8, arg=Variable "arg" is not available.
) at main.c:1306
#6 0x33d81565 in event_base_loop () from /usr/local/lib/libevent-1.4.so.3
#7 0x33d81899 in event_loop () from /usr/local/lib/libevent-1.4.so.3
#8 0x080a936a in do_main_loop () at main.c:1435
#9 0x080a951d in tor_main (argc=11, argv=0xbfbfe694) at main.c:2060
#10 0x080e5422 in main (argc=100193, argv=0x0) at tor_main.c:30
(gdb) quit
hellas# gdb /usr/local/bin/tor tor.core.04jun2009
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...
Core was generated by `tor'.
Program terminated with signal 4, Illegal instruction.
Reading symbols from /lib/libz.so.4...done.
Loaded symbols for /lib/libz.so.4
Reading symbols from /usr/local/lib/libevent-1.4.so.3...done.
Loaded symbols for /usr/local/lib/libevent-1.4.so.3
Reading symbols from /usr/lib/libssl.so.5...done.
Loaded symbols for /usr/lib/libssl.so.5
Reading symbols from /lib/libcrypto.so.5...done.
Loaded symbols for /lib/libcrypto.so.5
Reading symbols from /lib/libthr.so.3...done.
Loaded symbols for /lib/libthr.so.3
Reading symbols from /lib/libc.so.7...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /usr/lib/librt.so.1...done.
Loaded symbols for /usr/lib/librt.so.1
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0 0x080b0f1e in policies_parse_from_options (options=0x37df1c00)
at policies.c:431
431 if (load_policy_from_option(options->DirPolicy, &dir_policy, -1) < 0)
[New Thread 0x34102030 (LWP 100195)]
[New Thread 0x34101f20 (LWP 100194)]
[New Thread 0x34101040 (LWP 100240)]
(gdb) bt
#0 0x080b0f1e in policies_parse_from_options (options=0x37df1c00)
at policies.c:431
#1 0x08068824 in options_act (old_options=0x34123400) at config.c:1298
legacy/trac#2 0x080697b6 in set_options (new_val=0x37df1c00, msg=0xbfbfe4b8)
at config.c:807
legacy/trac#3 0x0806a262 in options_init_from_string (
cf=0x37ece000 "## Configuration file for a typical Tor user\n## Last updated 8 October 2006 for Tor 0.1.2.3-alpha.\n## (May or may not work for older or newer versions of Tor.)\n##\n## Lines that begin with \"## \" try to"...,
command=0, command_arg=0x0, msg=0xbfbfe4b8) at config.c:4087
legacy/trac#4 0x0806a909 in options_init_from_torrc (argc=11, argv=0xbfbfe6a0)
at config.c:3961
legacy/trac#5 0x080a715c in signal_callback (fd=1, events=8, arg=Variable "arg" is not available.
) at main.c:1306
legacy/trac#6 0x33d81565 in event_base_loop () from /usr/local/lib/libevent-1.4.so.3
legacy/trac#7 0x33d81899 in event_loop () from /usr/local/lib/libevent-1.4.so.3
legacy/trac#8 0x080a936a in do_main_loop () at main.c:1435
legacy/trac#9 0x080a951d in tor_main (argc=11, argv=0xbfbfe6a0) at main.c:2060
legacy/trac#10 0x080e5422 in main (argc=100240, argv=0x0) at tor_main.c:30
(gdb) quit
hellas# exit
exit
Script done on Fri Jun 5 00:42:13 2009
The torrc file can be made available upon request if needed.
Comments:
I have no recollection of any prior version of tor failing in this
manner in response to a SIGHUP. It is very restricting not to dare to
send SIGHUPs at all with this version in order to avoid causing yet
another crash. I am considering reviving 0.2.1.13-alpha to regain
this functionality. I have built 0.2.1.15-rc, but am reluctant to
install and use it, given that this bug most likely still exists in
0.2.1.15-rc, whereas it didn't seem to happen in the earlier version.
Submitted (via Jon <scream@nonvocalscream.com>) by:
Scott Bennett <bennett@cs.niu.edu>
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: JonCharge
https://gitlab.torproject.org/tpo/core/tor/-/issues/997
Hidden services fail to load if you have a stale descriptor
2020-06-27T14:09:55Z
Roger Dingledine
Hidden services fail to load if you have a stale descriptor
Using git head.
In connection_ap_handshake_rewrite_and_attach(), we check
rend_cache_lookup_entry(). If >0 (meaning we have a rend descriptor),
we then evaluate:
/** How long after we receive a hidden service descriptor do we consider
...
Using git head.
In connection_ap_handshake_rewrite_and_attach(), we check
rend_cache_lookup_entry(). If >0 (meaning we have a rend descriptor),
we then evaluate:
/** How long after we receive a hidden service descriptor do we consider
* it valid? */
#define NUM_SECONDS_BEFORE_HS_REFETCH (60*15)
if (now - entry->received < NUM_SECONDS_BEFORE_HS_REFETCH) {
and if it's stale (we got it more than 15 minutes ago), we call
log_info(LD_REND, "Stale descriptor %s. Re-fetching.",
safe_str(conn->rend_data->onion_address));
rend_client_refetch_v2_renddesc(conn->rend_data);
However, in rend_client_refetch_v2_renddesc() we don't care whether
it's stale. Towards the top of the function we call:
if (rend_cache_lookup_entry(rend_query->onion_address, -1, &e) > 0) {
log_info(LD_REND, "We would fetch a v2 rendezvous descriptor, but we "
"already have that descriptor here. Not fetching.");
return;
}
So now that we don't try to fetch v0 rend descriptors, that means that
Tor simply times out on all socks requests to hidden services for which
we have a stale descriptor.
Presumably this is a bug on 0.2.1.x and 0.2.0.x too.
My original rend desc design was "if you have a fresh one, use it. If
you have one but it's stale, fetch a new one; then whether you get a new
one or no, use the one you have." We seem to have clobbered that design
in 0.2.0.20-rc (r13540) when we added support for v0 and v2 rend descs.
In any case, refetching after 15 minutes was cheap back in the days of
Tor 0.0.9, but is expensive now.
So the two extremes we have are:
1) connection_ap_handshake_rewrite_and_attach() which says "it's stale
after 15 minutes; try to fetch a new one if it's stale" and
2) /** Time period for which a v2 descriptor will be valid. */
#define REND_TIME_PERIOD_V2_DESC_VALIDITY (24*60*60)
Do we want something in between?
(Thanks to neoeinstein for tracking down the bug.)
[Automatically added by flyspray2trac: Operating System: All]
Tor: 0.2.2.x-final
Karsten Loesing
Karsten Loesing
https://gitlab.torproject.org/tpo/core/tor/-/issues/1000
Latest maint-0.2.1 git update fails compile
2020-06-27T14:09:55Z
Trac
Latest maint-0.2.1 git update fails compile
Here was the latest update message:
From git://git.torproject.org/git/tor
bd0eaa0..3a5259e maint-0.2.0 -> origin/maint-0.2.0
c50098f..8453263 maint-0.2.1 -> origin/maint-0.2.1
358efe1..74bf885 master -> origin/master
Upda...
Here was the latest update message:
From git://git.torproject.org/git/tor
bd0eaa0..3a5259e maint-0.2.0 -> origin/maint-0.2.0
c50098f..8453263 maint-0.2.1 -> origin/maint-0.2.1
358efe1..74bf885 master -> origin/master
Updating 358efe1..74bf885
make failed, make clean + make failed and make clean + ./autogen.sh + make failed with the following:
gcc -g -O2 -Wall -g -O2 -fno-strict-aliasing -L/usr/pkg/lib -L/usr/pkg/lib -Wl,-R/usr/pkg/lib -o tor buffers.o circuitbuild.o circuitlist.o circuituse.o command.o config.o connection.o connection_edge.o connection_or.o control.o cpuworker.o directory.o dirserv.o dirvote.o dns.o dnsserv.o geoip.o hibernate.o main.o networkstatus.o onion.o policies.o reasons.o relay.o rendcommon.o rendclient.o rendmid.o rendservice.o rephist.o router.o routerlist.o routerparse.o eventdns.o config_codedigest.o tor_main.o ../common/libor.a ../common/libor-crypto.a -lz -levent -lssl -lcrypto -lpthread
config.o: In function `init_libevent':
/usr/local/src/tor/src/or/config.c:4810: undefined reference to `configure_libevent_logging'
/usr/local/src/tor/src/or/config.c:4814: undefined reference to `suppress_libevent_log_msg'
/usr/local/src/tor/src/or/config.c:4816: undefined reference to `tor_check_libevent_header_compatibility'
/usr/local/src/tor/src/or/config.c:4818: undefined reference to `tor_libevent_initialize'
/usr/local/src/tor/src/or/config.c:4820: undefined reference to `suppress_libevent_log_msg'
/usr/local/src/tor/src/or/config.c:4822: undefined reference to `tor_libevent_get_method'
/usr/local/src/tor/src/or/config.c:4822: undefined reference to `tor_check_libevent_version'
/usr/local/src/tor/src/or/config.c:4826: undefined reference to `tor_libevent_get_version_str'
/usr/local/src/tor/src/or/config.c:4827: undefined reference to `tor_libevent_get_method'
dns.o: In function `dns_launch_correctness_checks':
/usr/local/src/tor/src/or/dns.c:1571: undefined reference to `tor_evtimer_new'
main.o: In function `handle_signals':
/usr/local/src/tor/src/or/main.c:1741: undefined reference to `tor_libevent_get_base'
/usr/local/src/tor/src/or/main.c:1741: undefined reference to `tor_evsignal_new'
main.o: In function `connection_start_reading_from_linked_conn':
/usr/local/src/tor/src/or/main.c:423: undefined reference to `tor_libevent_get_base'
main.o: In function `connection_add':
/usr/local/src/tor/src/or/main.c:136: undefined reference to `tor_libevent_get_base'
/usr/local/src/tor/src/or/main.c:136: undefined reference to `tor_event_new'
/usr/local/src/tor/src/or/main.c:138: undefined reference to `tor_libevent_get_base'
/usr/local/src/tor/src/or/main.c:138: undefined reference to `tor_event_new'
main.o: In function `second_elapsed_callback':
/usr/local/src/tor/src/or/main.c:1166: undefined reference to `tor_libevent_get_base'
/usr/local/src/tor/src/or/main.c:1166: undefined reference to `tor_evtimer_new'
main.o: In function `do_main_loop':
/usr/local/src/tor/src/or/main.c:1450: undefined reference to `tor_libevent_get_base'
/usr/local/src/tor/src/or/main.c:1458: undefined reference to `tor_libevent_get_method'
*** Error code 1
Stop.
make: stopped in /usr/local/src/tor/src/or
*** Error code 1
Stop.
make: stopped in /usr/local/src/tor/src
*** Error code 1
Stop.
make: stopped in /usr/local/src/tor
*** Error code 1
Stop.
make: stopped in /usr/local/src/tor
[Automatically added by flyspray2trac: Operating System: BSD]
**Trac**:
**Username**: yancm
https://gitlab.torproject.org/tpo/core/tor/-/issues/1001
tor git master from bdd5785f075d89123f6ac8110ea86f31981ae3b1
2020-06-27T14:09:55Z
Andrew Lewman
tor git master from bdd5785f075d89123f6ac8110ea86f31981ae3b1
Tor from git master ( bdd5785f075d89123f6ac8110ea86f31981ae3b1) crashes with:
Jun 15 23:17:31.845 [Debug] connection_handle_write(): After TLS write of 512: 0 read, 586 written
Jun 15 23:17:31.846 [Debug] connection_or_flush_from_firs...
Tor from git master ( bdd5785f075d89123f6ac8110ea86f31981ae3b1) crashes with:
Jun 15 23:17:31.845 [Debug] connection_handle_write(): After TLS write of 512: 0 read, 586 written
Jun 15 23:17:31.846 [Debug] connection_or_flush_from_first_active_circuit(): Made a circuit inactive.
Jun 15 23:17:31.847 [Debug] conn_write_callback(): socket 87 wants to write.
Jun 15 23:17:31.847 [Debug] flush_chunk_tls(): flushed 512 bytes, 0 ready to flush, 0 remain.
Jun 15 23:17:31.848 [Debug] connection_handle_write(): After TLS write of 512: 0 read, 586 written
Jun 15 23:17:31.849 [Debug] conn_read_callback(): socket 39 wants to read.
Jun 15 23:17:31.849 [Debug] connection_read_to_buf(): 39: starting, inbuf_datalen 0 (0 pending in tls object). at_most 0.
Jun 15 23:17:31.850 [Debug] connection_read_to_buf(): After TLS read of 0: 0 read, 0 written
Jun 15 23:17:31.850 [Debug] connection_consider_empty_read_buckets(): global relayed read bucket exhausted. Pausing.
Jun 15 23:17:31.851 [Debug] connection_or_process_cells_from_inbuf(): 39: starting, inbuf_datalen 0 (0 pending in tls object).
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x000000000000001c
Crashed Thread: 0
Thread 0 Crashed:
0 tor 0x000d36c4 event_base_set + 26
1 tor 0x000d2aae tor_event_new + 78 (compat_libevent.c:119)
2 tor 0x000d2aef tor_evtimer_new + 47 (compat_libevent.c:126)
3 tor 0x0005f312 dns_launch_correctness_checks + 354 (dns.c:1571)
4 tor 0x0006b3b5 second_elapsed_callback + 1093 (main.c:1122)
5 tor 0x000d47a2 event_base_loop + 1087
6 tor 0x0006c712 do_main_loop + 386 (main.c:1454)
7 tor 0x0006c9ab tor_main + 91 (main.c:2075)
8 tor 0x00001aa2 _start + 216
9 tor 0x000019c9 start + 41
Thread 1:
0 libSystem.B.dylib 0x92d2eb96 recvfrom$NOCANCEL$UNIX2003 + 10
1 tor 0x000439e2 cpuworker_main + 114 (cpuworker.c:244)
2 tor 0x000bde63 tor_pthread_helper_fn + 67 (compat.c:1728)
3 libSystem.B.dylib 0x92d17155 _pthread_start + 321
4 libSystem.B.dylib 0x92d17012 thread_start + 34
Libevent 1.4.11 compiled as a universal binary.
[Automatically added by flyspray2trac: Operating System: OSX 10.5 Leopard]
Nick Mathewson
Nick Mathewson
https://gitlab.torproject.org/tpo/core/tor/-/issues/1002
tor writes logs too often (DoS)
2020-06-27T14:09:54Z
Trac
tor writes logs too often (DoS)
I recently switched from BandwithAccounting to RelayBandWidth rate, and tor promptly hit the file descriptor limit.
Instead of writing a helpful log entry and perhaps refusing new connections, tor wrote log entries over 20 times per seco...
I recently switched from BandwithAccounting to RelayBandWidth rate, and tor promptly hit the file descriptor limit.
Instead of writing a helpful log entry and perhaps refusing new connections, tor wrote log entries over 20 times per second, causing the resulting 1.9gb file to fill my /var partition and impact upon other running services.
Apart from being annoying, this looks like an easy way to DoS a relay.
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: gentootor
https://gitlab.torproject.org/tpo/core/tor/-/issues/1007
sending signals to tor process works only once
2020-06-27T14:09:54Z
Trac
sending signals to tor process works only once
The first time works, after that:
Program received signal SIGHUP, Hangup.
0x0000003006ade7a3 in __epoll_wait_nocancel () from /lib64/libc.so.6
(gdb) bt
#0 0x0000003006ade7a3 in __epoll_wait_nocancel () from /lib64/libc.so.6
#1 0x000000...
The first time works, after that:
Program received signal SIGHUP, Hangup.
0x0000003006ade7a3 in __epoll_wait_nocancel () from /lib64/libc.so.6
(gdb) bt
#0 0x0000003006ade7a3 in __epoll_wait_nocancel () from /lib64/libc.so.6
#1 0x000000300081307e in epoll_dispatch () from /usr/lib64/libevent-1.4.so.2
legacy/trac#2 0x00000030008067e6 in event_base_loop () from /usr/lib64/libevent-1.4.so.2
legacy/trac#3 0x0000000000466324 in do_main_loop ()
legacy/trac#4 0x000000000046651d in tor_main ()
legacy/trac#5 0x0000003006a1ea2d in __libc_start_main () from /lib64/libc.so.6
legacy/trac#6 0x0000000000407b29 in _start ()
(gdb) c
Continuing.
Program terminated with signal SIGHUP, Hangup.
The program no longer exists.
I have Linux 2.6.29.5, libevent-1.4.11,
$ git describe
tor-0.2.1.15-rc-154-g9cd9ab2
It does not matter do I send SIGHUP or SIGUSR1 ..
Tor from 20090601 works OK! I have not yet tried bisect.
[Automatically added by flyspray2trac: Operating System: Fedora Core Linux]
**Trac**:
**Username**: Safari
https://gitlab.torproject.org/tpo/core/tor/-/issues/1008
Constant crashes on freebsd
2020-06-27T14:09:54Z
Trac
Constant crashes on freebsd
I was running tor for months on freebsd on 0.2.0.19 with no problems.
Then I updated to 0.2.0.34 and started getting regular sometimes daily crashes,
i also then tried 0.2.1.13-rc and then 14-rc with the same problems.
Tor will randoml...
I was running tor for months on freebsd on 0.2.0.19 with no problems.
Then I updated to 0.2.0.34 and started getting regular sometimes daily crashes,
i also then tried 0.2.1.13-rc and then 14-rc with the same problems.
Tor will randomly crash on signal 11.
If i look at the core file with gdb I see its crashing in the ssl3_write function in libssl.
Complete gdb output:
gdb /usr/local/bin/tor tor.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols found)...
Core was generated by `tor'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libz.so.4...(no debugging symbols found)...done.
Loaded symbols for /lib/libz.so.4
Reading symbols from /usr/local/lib/libevent-1.4.so.3...(no debugging symbols found)...done.
Loaded symbols for /usr/local/lib/libevent-1.4.so.3
Reading symbols from /usr/local/lib/libssl.so.5...(no debugging symbols found)...done.
Loaded symbols for /usr/local/lib/libssl.so.5
Reading symbols from /usr/local/lib/libcrypto.so.5...(no debugging symbols found)...done.
Loaded symbols for /usr/local/lib/libcrypto.so.5
Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /usr/lib/librt.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/librt.so.1
Reading symbols from /lib/libthr.so.3...(no debugging symbols found)...done.
Loaded symbols for /lib/libthr.so.3
Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done.
Loaded symbols for /libexec/ld-elf.so.1
#0 0x080b3287 in ?? ()
[New Thread 0x28501100 (LWP 100125)]
[New LWP 100172]
(gdb)
(gdb) bt
#0 0x080b3287 in ?? ()
#1 0x286f4420 in ?? ()
legacy/trac#2 0x2991b000 in ?? ()
legacy/trac#3 0x29900000 in ?? ()
legacy/trac#4 0x281afcfa in ssl3_write () from /usr/local/lib/libssl.so.5
legacy/trac#5 0x287a1a10 in ?? ()
legacy/trac#6 0x28a17c50 in ?? ()
legacy/trac#7 0x2889ec00 in ?? ()
legacy/trac#8 0x2889ec04 in ?? ()
legacy/trac#9 0xbfbfe9f8 in ?? ()
legacy/trac#10 0x080b45e4 in ?? ()
legacy/trac#11 0x28a17c50 in ?? ()
legacy/trac#12 0x00000200 in ?? ()
legacy/trac#13 0x287a1a10 in ?? ()
legacy/trac#14 0x00000000 in ?? ()
legacy/trac#15 0x29900000 in ?? ()
legacy/trac#16 0x0813ddf8 in ?? ()
legacy/trac#17 0xbfbfea08 in ?? ()
legacy/trac#18 0x2889ec3c in ?? ()
legacy/trac#19 0x2889ec48 in ?? ()
legacy/trac#20 0x00000001 in ?? ()
legacy/trac#21 0x00000001 in ?? ()
legacy/trac#22 0x0000002c in ?? ()
legacy/trac#23 0x287a1a10 in ?? ()
legacy/trac#24 0x4a3964e6 in ?? ()
legacy/trac#25 0xbfbfea18 in ?? ()
legacy/trac#26 0x0807b6fb in ?? ()
legacy/trac#27 0x287a1a10 in ?? ()
legacy/trac#28 0x00000001 in ?? ()
legacy/trac#29 0x4a3964e6 in ?? ()
legacy/trac#30 0x287a1a10 in ?? ()
legacy/trac#31 0x00002b90 in ?? ()
legacy/trac#32 0x287a1a10 in ?? ()
legacy/trac#33 0xbfbfea48 in ?? ()
legacy/trac#34 0x0806e394 in ?? ()
legacy/trac#35 0x287a1a10 in ?? ()
legacy/trac#36 0x00000200 in ?? ()
legacy/trac#37 0x4a3964e6 in ?? ()
legacy/trac#38 0x00000d81 in ?? ()
legacy/trac#39 0x00000006 in ?? ()
legacy/trac#40 0x00000000 in ?? ()
legacy/trac#41 0x00002b90 in ?? ()
legacy/trac#42 0x000032d0 in ?? ()
legacy/trac#43 0x00002b90 in ?? ()
legacy/trac#44 0x000032d0 in ?? ()
legacy/trac#45 0xbfbfea98 in ?? ()
legacy/trac#46 0x0807218d in ?? ()
legacy/trac#47 0x00002b90 in ?? ()
legacy/trac#48 0xbfbfea80 in ?? ()
legacy/trac#49 0xbfbfea7c in ?? ()
legacy/trac#50 0x287a1a30 in ?? ()
legacy/trac#51 0x287a1a10 in ?? ()
legacy/trac#52 0x28fd1dd0 in ?? ()
legacy/trac#53 0xbfbfea98 in ?? ()
legacy/trac#54 0x0806d0cd in ?? ()
legacy/trac#55 0x294220a0 in ?? ()
legacy/trac#56 0x00000000 in ?? ()
legacy/trac#57 0x00000000 in ?? ()
legacy/trac#58 0x00002b90 in ?? ()
legacy/trac#59 0x00000000 in ?? ()
legacy/trac#60 0x00000004 in ?? ()
legacy/trac#61 0x4a3964e6 in ?? ()
legacy/trac#62 0x28194170 in __JCR_LIST__ () from /usr/local/lib/libevent-1.4.so.3
legacy/trac#63 0x287a1a10 in ?? ()
legacy/trac#64 0x28fd1dd0 in ?? ()
legacy/trac#65 0xbfbfeac8 in ?? ()
legacy/trac#66 0x080aa1a1 in ?? ()
legacy/trac#67 0x287a1a10 in ?? ()
legacy/trac#68 0x00000000 in ?? ()
legacy/trac#69 0x081228c3 in ?? ()
legacy/trac#70 0x08121336 in ?? ()
legacy/trac#71 0x00000029 in ?? ()
legacy/trac#72 0x00000000 in ?? ()
legacy/trac#73 0x0007434d in ?? ()
legacy/trac#74 0x28194170 in __JCR_LIST__ () from /usr/local/lib/libevent-1.4.so.3
legacy/trac#75 0x28194170 in __JCR_LIST__ () from /usr/local/lib/libevent-1.4.so.3
legacy/trac#76 0x080aa130 in ?? ()
legacy/trac#77 0xbfbfeb38 in ?? ()
legacy/trac#78 0x28184565 in event_base_loop () from /usr/local/lib/libevent-1.4.so.3
Previous frame inner to this frame (corrupt stack?)
(gdb) quit
[Automatically added by flyspray2trac: Operating System: BSD]
**Trac**:
**Username**: tortor
https://gitlab.torproject.org/tpo/core/tor/-/issues/1009
consensus parsing warnings
2020-06-27T14:09:54Z
Sebastian Hahn
consensus parsing warnings
In Fluxe3's logfile, these warnings were repeated over
and over again. When I restarted it without clearing out
the data directory, the warnings disappeared
Jun 19 06:29:24.838 [warn] Error decoding identity digest "s"
Jun 19 06:29:24.8...
In Fluxe3's logfile, these warnings were repeated over
and over again. When I restarted it without clearing out
the data directory, the warnings disappeared
Jun 19 06:29:24.838 [warn] Error decoding identity digest "s"
Jun 19 06:29:24.854 [warn] Got a bad signature on a networkstatus vote
Jun 19 06:29:24.854 [warn] Got a bad signature on a networkstatus vote
Jun 19 06:29:24.854 [warn] Got a bad signature on a networkstatus vote
Jun 19 06:29:24.855 [warn] Got a bad signature on a networkstatus vote
Jun 19 06:29:24.855 [warn] Got a bad signature on a networkstatus vote
Jun 19 06:29:24.855 [warn] 0 unknown, 0 missing key, 0 good, 5 bad, 0 no signature, 4 required
Jun 19 06:29:24.855 [warn] Not enough good signatures on networkstatus consensus
Jun 19 06:29:24.857 [warn] Unable to load consensus directory downloaded from server '128.31.0.34:9031'. I'll try again soon.
Jun 19 08:19:12.988 [warn] ISO time "Es09-06-19 03:42:06" was unparseable
Jun 19 08:19:12.989 [warn] Error parsing time 'Es09-06-19 03:42:06'
[Automatically added by flyspray2trac: Operating System: All]
https://gitlab.torproject.org/tpo/core/tor/-/issues/1011
TOR 2.1.16 rc don't accept more the libevent 1.4 on jaunty 64
2020-06-27T14:09:54Z
Trac
TOR 2.1.16 rc don't accept more the libevent 1.4 on jaunty 64
Hello,
i have updated my TOR to 2.1.16 rc on linux jaunty 64 bits intel and now are no more possible for TOR to find
or reconize libevent 1.4.
I have try to install from source , reposery, package and no one will accept it..
Only the...
Hello,
i have updated my TOR to 2.1.16 rc on linux jaunty 64 bits intel and now are no more possible for TOR to find
or reconize libevent 1.4.
I have try to install from source , reposery, package and no one will accept it..
Only the officiel 1.3e for jaunty are found...
I think the reposery need absolutly updated to 1.4 or give a update source, after need change the path to
TOR can find the right livevent.
Well in all case it's work fine in 1.3e but are better to be updated.
Thanks in advance
my best
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: stars
https://gitlab.torproject.org/tpo/core/tor/-/issues/1013
DirPortFrontPage gets rate limited and goes silent
2020-06-27T14:09:54Z
Roger Dingledine
DirPortFrontPage gets rate limited and goes silent
http://tor.sebastianhahn.net:443/ should say 'test', but instead it fails quietly
because the relay has hit its rate limits recently and doesn't want to waste any
bytes on frivolous directory stuff.
I think this is a bug, since people i...
http://tor.sebastianhahn.net:443/ should say 'test', but instead it fails quietly
because the relay has hit its rate limits recently and doesn't want to waste any
bytes on frivolous directory stuff.
I think this is a bug, since people intentionally set DirPortFrontPage, so they
really do want their relay to serve that page when it's asked for. Having it
appear only sometimes (or roughly never in Sebastian's case) makes it way less
useful.
[Automatically added by flyspray2trac: Operating System: All]
0.2.1.x-final
https://gitlab.torproject.org/tpo/core/tor/-/issues/1015
Control port closes on QUIT before flushing
2020-06-27T14:09:53Z
Trac
Control port closes on QUIT before flushing
If a synchronous command is issued to the control port which
has a long reply, and is followed immediately by a QUIT command,
the connection may be closed before the first command's reply
can be flushed.
"""
cat <<EOF | nc localhost 90...
If a synchronous command is issued to the control port which
has a long reply, and is followed immediately by a QUIT command,
the connection may be closed before the first command's reply
can be flushed.
"""
cat <<EOF | nc localhost 9051 > consensus
AUTHENTICATE
GETINFO dir/status-vote/current/consensus
QUIT
EOF
"""
The above will cut off before reaching the end of the consensus
document and close the connection.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: neoeinstein
https://gitlab.torproject.org/tpo/core/tor/-/issues/1016
Bug warning reported on Control bad AUTH & QUIT
2020-06-27T14:09:53Z
Trac
Bug warning reported on Control bad AUTH & QUIT
If a QUIT command is issued to the control port immediately after
a bad AUTHENTICATE command, a Bug warning is logged:
Jun 23 23:19:02.647 [warn] Bug: Duplicate call to connection_mark_for_close at control.c:2894 (first at control.c:109...
If a QUIT command is issued to the control port immediately after
a bad AUTHENTICATE command, a Bug warning is logged:
Jun 23 23:19:02.647 [warn] Bug: Duplicate call to connection_mark_for_close at control.c:2894 (first at control.c:1096)
To reproduce:
"""
cat <<EOF | nc localhost 9051
AUTHENTICATE totally-malformed
QUIT
EOF
"""
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: neoeinstein
https://gitlab.torproject.org/tpo/core/tor/-/issues/1018
GEOIP file not found
2020-06-27T14:09:53Z
Trac
GEOIP file not found
i am trying to create a bridge on tor but in the message log it says that the GEOIP file isnt found.
Jun27 22:56:44.370 [Warning] Failed to open GEOIP file C:\Documents and Settings\Administrator\Application Data\tor\geoip.
[Automat...
i am trying to create a bridge on tor but in the message log it says that the GEOIP file isnt found.
Jun27 22:56:44.370 [Warning] Failed to open GEOIP file C:\Documents and Settings\Administrator\Application Data\tor\geoip.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: jamescart
Andrew Lewman
Andrew Lewman
https://gitlab.torproject.org/tpo/core/tor/-/issues/1022
eventdns setting truncated bit wrong?
2020-06-27T14:09:53Z
Roger Dingledine
eventdns setting truncated bit wrong?
<optimist> eventdns.c "buf[3] |= 0x02; /* set the truncated bit. */". why it
is buf[3]? isn't should be buf[2]?
> »·······APPEND16(req->trans_id);
> »·······APPEND16(flags);
> »·······»·······buf[3] |= 0x02; /* set the truncated bit. */...
<optimist> eventdns.c "buf[3] |= 0x02; /* set the truncated bit. */". why it
is buf[3]? isn't should be buf[2]?
> »·······APPEND16(req->trans_id);
> »·······APPEND16(flags);
> »·······»·······buf[3] |= 0x02; /* set the truncated bit. */
> i haven't looked much yet. but perhaps the truncated bit is in the second
byte of flags?
> where are the possible flags listed? how horrible
optimist> in first, for network order, so it [2]. I think
optimist> flags placed in [2] and [3]
> if this is a bug, what problems would it make?
optimist> it rewrites actual RCODE - Response code
[Automatically added by flyspray2trac: Operating System: All]
Nick Mathewson
Nick Mathewson
https://gitlab.torproject.org/tpo/core/tor/-/issues/1023
Authorities should avoid voting on Running if they just came up
2020-06-27T14:09:53Z
Roger Dingledine
Authorities should avoid voting on Running if they just came up
the reason this came up is when an authority comes up near to voting time,
it ends all the uptimes in its router-stability file, because it votes 'no'
on all of them, and the act of deciding its vote changes the router-stability
line.
<...
the reason this came up is when an authority comes up near to voting time,
it ends all the uptimes in its router-stability file, because it votes 'no'
on all of them, and the act of deciding its vote changes the router-stability
line.
<nickm> Proposed other behavior: If we have been up less than N minutes, don't
vote on Running. For N == 30? 45?
> 30 should be fine
<nickm> We'd probably want this to be overridable for test networks, alas.
> hey, we have a config option for that.
> V(TestingTorNetwork, BOOL, "0"),
> which could override it automatically
[Automatically added by flyspray2trac: Operating System: All]
post 0.2.1.x
https://gitlab.torproject.org/tpo/core/tor/-/issues/1024
rend_client_send_introduction(): Bug: Internal error: could not find intro key.
2020-06-27T14:09:53Z
Trac
rend_client_send_introduction(): Bug: Internal error: could not find intro key.
hello,
i have this bug error in my log:
juin 30 18:20:56.587 [Avertissement] rend_client_send_introduction(): Bug: Internal error: could not find intro key.
i am on ubuntu jaunty 64 bits x86 64
relay: swisstorexit
[Automatically...
hello,
i have this bug error in my log:
juin 30 18:20:56.587 [Avertissement] rend_client_send_introduction(): Bug: Internal error: could not find intro key.
i am on ubuntu jaunty 64 bits x86 64
relay: swisstorexit
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: stars
https://gitlab.torproject.org/tpo/core/tor/-/issues/1025
Completion of error handling
2020-06-27T14:09:53Z
Trac
Completion of error handling
Some checks for return codes are missing.
Examples:
Would you like to add more error handling for return values from "pthread_cond_signal" like in the function
"tor_cond_signal_one" and from "fprintf" in the function "write_pidfile"?
h...
Some checks for return codes are missing.
Examples:
Would you like to add more error handling for return values from "pthread_cond_signal" like in the function
"tor_cond_signal_one" and from "fprintf" in the function "write_pidfile"?
https://svn.torproject.org/cgi-bin/viewvc.cgi/tor/trunk/src/common/compat.c?view=markup&revision=18761
https://svn.torproject.org/cgi-bin/viewvc.cgi/tor/trunk/src/common/util.c?view=markup&revision=18761
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: elfring
https://gitlab.torproject.org/tpo/core/tor/-/issues/1026
tor-0.2.1.15-rc posts inappropriate descriptor update, resulting in eventual ...
2020-06-27T14:09:53Z
Trac
tor-0.2.1.15-rc posts inappropriate descriptor update, resulting in eventual expiration from consen
-- Submitted on behalf of "Scott Bennett <bennett@cs.niu.edu>" --
If a currently valid descriptor (#1) is on file at the authorities
based upon the following data rate information from torrc:
BandwidthRate 100 KB
Bandwidt...
-- Submitted on behalf of "Scott Bennett <bennett@cs.niu.edu>" --
If a currently valid descriptor (#1) is on file at the authorities
based upon the following data rate information from torrc:
BandwidthRate 100 KB
BandwidthBurst 140 KB
MaxAdvertisedBandwidth 85 KB
and torrc is changed to read:
BandwidthRate 85 KB
BandwidthBurst 140 KB
and no other torrc information has changed and the observed peak
ten-second data rate in the previous 24 hours is unchanged since the
publication of descriptor #1, a SIGHUP sent to tor causes a new
descriptor (#2) to be posted to the authorities, where the only
changed information is the publication timestamp. The authorities
then reject descriptor #2 as "not new". The tor relay, however, has
changed its own idea of when the next descriptor update should be
posted to ~18 hours later than the timestamp on #2. At ~18 hours
after the posting of descriptor #1, the authorities assume for the
next consensus vote that the relay is no longer running because they
have not received an update around ~18 hours from the posting of #1.
This results in the relay being dropped from consensus documents
until the relay posts an update ~18 hours from the timestamp of #2.
This can cause a running tor relay to be dropped inappropriately
from the consensus documents for many hours before the situation is
corrected.
Relays should not post early descriptor updates that will be rejected
by the authorities, or alternatively, relays should not reset their
18-hour timers for descriptor updates until a majority of the
authorities has accepted the new updates.
This bug may also be related to bug report #962.
Submitted by:
Scott Bennett <bennett@cs.niu.edu>
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Jon_Scream
https://gitlab.torproject.org/tpo/core/tor/-/issues/1027
tor logs data that it should not
2020-06-27T14:09:53Z
Trac
tor logs data that it should not
[warn] Invalid hostname www.abcdefghijklmnop.onion; rejecting
Onion hostnames being accessed are confidential information. Tor should never log details of what's going through it to disk by default, even on error. All data like this s...
[warn] Invalid hostname www.abcdefghijklmnop.onion; rejecting
Onion hostnames being accessed are confidential information. Tor should never log details of what's going through it to disk by default, even on error. All data like this should be masked unless debugging is enabled explicitly. This is a major breach of reasonable expectations.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: anonyuser
https://gitlab.torproject.org/tpo/core/tor/-/issues/1028
Tor don't can't reachable port, dir and work not long time when it start
2020-06-27T14:09:52Z
Trac
Tor don't can't reachable port, dir and work not long time when it start
Hello,
tor will almost never reachable the Dir and Ort port on jaunty 64 bits. / version tor 0.2.16 rc noreply
First i have think was a error from me but with the package debian 0.2.16 rc 64 bits and libevent 1.4.2 stable
it start in...
Hello,
tor will almost never reachable the Dir and Ort port on jaunty 64 bits. / version tor 0.2.16 rc noreply
First i have think was a error from me but with the package debian 0.2.16 rc 64 bits and libevent 1.4.2 stable
it start instantaneously and reachable the port in a few secound.
Well seem really a big bug or problem on it ..
What need i reinstall my hybrid version ? The problem i will not have the update like this....
thanks in advance for the answer..
Swisstorexit
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: stars
https://gitlab.torproject.org/tpo/core/tor/-/issues/1034
Memory Leak When nofile Limit Hit
2020-06-27T14:09:52Z
Trac
Memory Leak When nofile Limit Hit
In src/or/command.c, line 280, control is returned while not freeing memory allocated on line 273.
273: char *onionskin = tor_malloc(ONIONSKIN_CHALLENGE_LEN);
280: return;
[Automatically added by flyspray2trac: Operating System: All]
...
In src/or/command.c, line 280, control is returned while not freeing memory allocated on line 273.
273: char *onionskin = tor_malloc(ONIONSKIN_CHALLENGE_LEN);
280: return;
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: BarkerJr
https://gitlab.torproject.org/tpo/core/tor/-/issues/1035
Relay on dynamic IP marked as stable and guard
2020-06-27T14:09:52Z
Trac
Relay on dynamic IP marked as stable and guard
Hi,
I'm running a Tor relay on a dynamic IP which changes every day. At the moment
my node is marked as stable and guard which AFAIK shouldn't happen as it isn't
stable. I got the information from https://trunk.torstatus.kgprog.com:444/...
Hi,
I'm running a Tor relay on a dynamic IP which changes every day. At the moment
my node is marked as stable and guard which AFAIK shouldn't happen as it isn't
stable. I got the information from https://trunk.torstatus.kgprog.com:444/.
This may be related to bug legacy/trac#969 which was marked as fixed.
Thanks,
Simon
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: rudis
Tor: 0.2.4.x-final
Sebastian Hahn
Sebastian Hahn
https://gitlab.torproject.org/tpo/core/tor/-/issues/1037
make test and make check-spaces report errors on stdout
2020-06-27T14:09:52Z
Sebastian Hahn
make test and make check-spaces report errors on stdout
Hey, I just noticed that make check-spaces and test report
their errors on stdout. Is that the behaviour we want for any
reason? If not, I'll write a fix
[Automatically added by flyspray2trac: Operating System: All]
Hey, I just noticed that make check-spaces and test report
their errors on stdout. Is that the behaviour we want for any
reason? If not, I'll write a fix
[Automatically added by flyspray2trac: Operating System: All]
https://gitlab.torproject.org/tpo/core/tor/-/issues/1038
Problem facing connecting a Tor client to a Tor hidden server
2020-06-27T14:09:52Z
Trac
Problem facing connecting a Tor client to a Tor hidden server
This is with regards to an email exchange that took place few days back on the or-talk mailing list. The anonymous
client connects to the hidden service quite intermittently . However it does sometimes connects (say in 1 in 20 chances)....
This is with regards to an email exchange that took place few days back on the or-talk mailing list. The anonymous
client connects to the hidden service quite intermittently . However it does sometimes connects (say in 1 in 20 chances).
The client and server are properly configured using default configuration for the client and configuration for the server
which indicates the appropriate directory where the server stores the appropriate files and the appropriate hidden service port
number where service requests are to be directed. I am sure of it since I the client works fine otherwise (when not connecting
anonymously to a non-anonymous service) and so does the server (when being used as a client). Only in some instances is the
client able to communicate with the hidden service (as mentioned earlier).
This is what Roger Dingledine has to say regarding the issue :
"
I think there's a real bug here. I've been playing with it on and off. I
think that when Tor has a rendezvous circuit that it thinks it should
like, and suddenly changes its mind, then it discards that circuit and
starts working on a new one (which is good), but at the same time it
closes the socks stream (which is bad).
Fixing that bug, if it turns out to actually be a bug, would mean that
hidden services are dirt slow when making the initial connection (until
we make Tor itself faster at least), but they're not as flaky as they
currently appear.
--Roger
"
I can send the notices.log and debug.log files from both the client and the hidden service to you as and when needed . They
are too big to fit in here . Let me know if it is needed , and I can send to you those files to appropriate email ids where
you would like them .
Thanks
Sambuddho
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: sambuddho
https://gitlab.torproject.org/tpo/core/tor/-/issues/1042
rate-limit MaxOnionsPending warns
2020-06-27T14:09:51Z
Roger Dingledine
rate-limit MaxOnionsPending warns
If your cpu can't keep up with the number of create cells you get, you'll
fill your logs with warnings:
if (ol_length >= get_options()->MaxOnionsPending) {
log_warn(LD_GENERAL,
"Your computer is too slow to handle thi...
If your cpu can't keep up with the number of create cells you get, you'll
fill your logs with warnings:
if (ol_length >= get_options()->MaxOnionsPending) {
log_warn(LD_GENERAL,
"Your computer is too slow to handle this many circuit "
"creation requests! Please consider using the "
"MaxAdvertisedBandwidth config option or choosing a more "
"restricted exit policy.");
We should make the warning only happen once a minute or something.
[Automatically added by flyspray2trac: Operating System: All]
Tor: 0.2.2.x-final
https://gitlab.torproject.org/tpo/core/tor/-/issues/1043
"LongLivesPorts" don't work, bandwitch trafic , eventDNS, overloads
2020-06-27T14:09:51Z
Trac
"LongLivesPorts" don't work, bandwitch trafic , eventDNS, overloads
Hello,
I have found a few bugs on Master 2.2 alpha dev with "circvum windows" patch on ubuntu
jaunty x86 64, libevent 1.3e
"LongLivesPorts" don't work, all programs like irc, chat ect... close the connections in a
couple secounds or mi...
Hello,
I have found a few bugs on Master 2.2 alpha dev with "circvum windows" patch on ubuntu
jaunty x86 64, libevent 1.3e
"LongLivesPorts" don't work, all programs like irc, chat ect... close the connections in a
couple secounds or minutes.
i have added manualy the command in torrc but make no difference.
Tor become many more trafic "recieve" as "send" ex: 200KB in and only 130 KB out . i run with "DirPort" so
it don't seem normal.
many warn "eventDNS" , in 2 days 3 times tor was overloaded and crashed vidalia. ( i run 4 cpus ) and tor
prcocess was only 2 %
With the patch "circvum windows", when i connect me to a site who open some page or connections on same
circuit, the page don't load or are extrem slow.
ex: when will try a speed test or decloak, when are on the last speed test or when decloak will give the
final result, the page don't load and some connections stay connected on the circuit. so need many time
close it manually
about logs, are nothing who can help except the many "eventDnS" error
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: stars
https://gitlab.torproject.org/tpo/core/tor/-/issues/1044
Make it actually work.
2020-06-27T14:09:51Z
Trac
Make it actually work.
I've been trying to use TOR for a few years now. Every single instance I've installed on more than 8 different computers using both windows and linux fails to operate.
TOR is failware. Every forum I read says "we'll fix that bug next tim...
I've been trying to use TOR for a few years now. Every single instance I've installed on more than 8 different computers using both windows and linux fails to operate.
TOR is failware. Every forum I read says "we'll fix that bug next time."
It is next time. And another next time.
Torbutton is the worst pile I've seen since freenet, another vaporware project of fail.
Tell me, is there any plan to have this firefox addon actually function at ALL?
It's a POS.
I'm writing the guys at firefox to ask them to strip this plugin off their recommended list until the ONE major bug is repaired: It doesn't fucking work.
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: demopoly
https://gitlab.torproject.org/tpo/core/tor/-/issues/1045
Framing TLS records violates the protocol specification.
2020-06-27T14:09:51Z
Trac
Framing TLS records violates the protocol specification.
The problem is _connection_write_to_buf_impl(), if it
flushes forcely a some bytes from outbuf.
For queued cells (in_flushed_some is true), it never plays
with outbuf_flushlen. So call for connection_handle_write()
triggered only in ca...
The problem is _connection_write_to_buf_impl(), if it
flushes forcely a some bytes from outbuf.
For queued cells (in_flushed_some is true), it never plays
with outbuf_flushlen. So call for connection_handle_write()
triggered only in case of overlapping sets of conditions;
If outbuf_flushlen was equal 15360 before cell_destroy
(or cell_padding) was appended, then flushes of 15872
bytes to TLS record.
Such behavior can leak a type of the last cell, and a some
internal information likes a outbuf's length.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: OTU
https://gitlab.torproject.org/tpo/core/tor/-/issues/1051
couldn't find start of hashed material "network-status-version"
2020-06-27T14:09:51Z
Trac
couldn't find start of hashed material "network-status-version"
hello,
i think i have found a new bug on 2.17 rc on ubuntu jaunty 64 x86 64 , libevent 1.3e
août 06 11:16:43.602 [Avertissement] couldn't find start of hashed material "network-status-version"
août 06 11:16:43.680 [Avertissement] Unabl...
hello,
i think i have found a new bug on 2.17 rc on ubuntu jaunty 64 x86 64 , libevent 1.3e
août 06 11:16:43.602 [Avertissement] couldn't find start of hashed material "network-status-version"
août 06 11:16:43.680 [Avertissement] Unable to compute digest of network-status
août 06 11:16:43.680 [Avertissement] Unable to parse networkstatus consensus
août 06 11:16:43.680 [Avertissement] Unable to load consensus directory downloaded from server '80.190.246.100:80'. I'll try again soon.
août 06 11:55:23.720 [Avertissement] eventdns: All nameservers have failed
août 06 11:55:26.783 [Signalement] eventdns: Nameserver 192.168.2.1 is back up
my best
SwissTorExit / John
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: stars
https://gitlab.torproject.org/tpo/core/tor/-/issues/1059
key unknow, error load consensus, and some more
2020-06-27T14:09:51Z
Trac
key unknow, error load consensus, and some more
hello,
new bugs founds on master branch 2.2 alpha on jaunty x86 64 , libevent 1.3e version update then 9.08.09
août 10 07:58:35.121 [Avertissement] eventdns: All nameservers have failed
août 10 07:58:37.664 [Signalement] eventdns: Nam...
hello,
new bugs founds on master branch 2.2 alpha on jaunty x86 64 , libevent 1.3e version update then 9.08.09
août 10 07:58:35.121 [Avertissement] eventdns: All nameservers have failed
août 10 07:58:37.664 [Signalement] eventdns: Nameserver 192.168.2.1 is back up
août 10 08:15:17.728 [Avertissement] 1 unknown, 0 missing key, 3 good, 0 bad, 2 no signature, 4 required
août 10 08:15:17.729 [Avertissement] Not enough good signatures on networkstatus consensus
août 10 08:15:17.729 [Avertissement] Unable to load consensus directory downloaded from server '216.224.124.114:9030'. I'll try again soon.
août 10 08:54:53.073 [Signalement] We tried for 15 seconds to connect to '[scrubbed]' using exit 'blutmagie'. Retrying on a new circuit.
août 10 09:18:20.627 [Signalement] We're missing a certificate from authority with signing key B7A209B31ACDD633258D0F07715482BD04F88F4F: launching request.
août 10 09:18:20.691 [Avertissement] Received http status code 404 ("Not found") from server '86.59.21.38:80' while fetching "/tor/keys/fp/80550987E1D626E3EBA5E5E75A458DE0626D088C".
août 10 09:20:20.368 [Signalement] We're missing a certificate from authority with signing key B7A209B31ACDD633258D0F07715482BD04F88F4F: launching request.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: stars
https://gitlab.torproject.org/tpo/core/tor/-/issues/1060
Stack smashing detected in getinfo_helper_events()
2020-06-27T14:09:50Z
anonym
Stack smashing detected in getinfo_helper_events()
When I try to connect to the control port using TorK, tor is killed due to a stack smashing "attack" in
getinfo_helper_events(). This is on Hardened Gentoo, with gcc 3.4.6 (old, yes, but that's what's considered
stable in Hardened Gentoo...
When I try to connect to the control port using TorK, tor is killed due to a stack smashing "attack" in
getinfo_helper_events(). This is on Hardened Gentoo, with gcc 3.4.6 (old, yes, but that's what's considered
stable in Hardened Gentoo). Recompiling without SSP fixes it. The old stable 0.2.0.x branch does not have
this problem.
[Automatically added by flyspray2trac: Operating System: Other Linux]
https://gitlab.torproject.org/tpo/core/tor/-/issues/1064
warnings in log related to consensus problems
2020-06-27T14:09:50Z
Sebastian Hahn
warnings in log related to consensus problems
Yesterday I had this in my logs:
Aug 19 06:25:08.854 [notice] Tor 0.2.1.19 opening new log file.
Aug 19 11:11:24.080 [warn] couldn't find start of hashed material "network-status-version"
Aug 19 11:11:24.080 [warn] Unable to compute dig...
Yesterday I had this in my logs:
Aug 19 06:25:08.854 [notice] Tor 0.2.1.19 opening new log file.
Aug 19 11:11:24.080 [warn] couldn't find start of hashed material "network-status-version"
Aug 19 11:11:24.080 [warn] Unable to compute digest of network-status
Aug 19 11:11:24.080 [warn] Unable to parse networkstatus consensus
Aug 19 11:11:24.080 [warn] Unable to load consensus directory downloaded from server '80.190.246.100:80'. I'll try again soon.
Aug 19 14:15:21.864 [warn] 1 unknown, 0 missing key, 3 good, 0 bad, 2 no signature, 4 required
Aug 19 14:15:21.864 [warn] Not enough good signatures on networkstatus consensus
Aug 19 14:15:21.866 [warn] Unable to load consensus directory downloaded from server '128.31.0.34:9031'. I'll try again soon.
Aug 19 14:25:30.496 [warn] 1 unknown, 0 missing key, 3 good, 0 bad, 2 no signature, 4 required
Aug 19 14:25:30.496 [warn] Not enough good signatures on networkstatus consensus
Aug 19 14:25:30.498 [warn] Unable to load consensus directory downloaded from server '86.59.21.38:80'. I'll try again soon.
Aug 19 14:56:01.852 [warn] 1 unknown, 0 missing key, 3 good, 0 bad, 2 no signature, 4 required
Aug 19 14:56:01.852 [warn] Not enough good signatures on networkstatus consensus
Aug 19 14:56:01.854 [warn] Unable to load consensus directory downloaded from server '216.224.124.114:9030'. I'll try again soon.
Aug 20 06:25:09.481 [notice] Received reload signal (hup). Reloading config and resetting internal state.
No idea where these warnings would come from. Does anyone with an authority have any useful logs?
[Automatically added by flyspray2trac: Operating System: All]
https://gitlab.torproject.org/tpo/core/tor/-/issues/1066
Restarting all the authorities at once would halt all the clients.
2020-06-27T14:09:50Z
Nick Mathewson
Restarting all the authorities at once would halt all the clients.
For a while after an authority has started, it doesn't have any opinion about which routers are Running,
so it doesn't vote on that. But if every authority were restarted at once right before it was time to
vote, no authority would vote...
For a while after an authority has started, it doesn't have any opinion about which routers are Running,
so it doesn't vote on that. But if every authority were restarted at once right before it was time to
vote, no authority would vote on the Running flag, and so no router would be listed as Running in the
next consensus. Clients would then think that all the routers were down.
Let's fix this DOS before it happens. One possible fix would be for authorities to refuse to build a consensus
if nobody has voted on certain essential flags, to include running. As a belt-and-suspenders approach, newer
clients could assume every router was Running if nobody voted on Running, rather than assuming no router was
Running.
[Automatically added by flyspray2trac: Operating System: All]
Nick Mathewson
Nick Mathewson
https://gitlab.torproject.org/tpo/core/tor/-/issues/1072
Gzip decompression returned an error: incorrect data check
2020-06-27T14:09:50Z
Trac
Gzip decompression returned an error: incorrect data check
hello ,
Here are a new message in my log, never see before.
Gzip decompression returned an error: incorrect data check
master commit: commit 1092fdca53ec0110b4e4c0bf51a5881ee68c4ac8
on kubuntu karmic 64 x86 64 , libevent 1.4.11
MyFa...
hello ,
Here are a new message in my log, never see before.
Gzip decompression returned an error: incorrect data check
master commit: commit 1092fdca53ec0110b4e4c0bf51a5881ee68c4ac8
on kubuntu karmic 64 x86 64 , libevent 1.4.11
MyFamily $F377AAB595C2C4C03252E041E44AA1C718082F3A,$7DC062E8D8995878BD6B2930AEE5C1EAB43C64C7
NumCPUs 4
ExcludeNodes 204.8.156.142, 206.222.29.14, 82.28.95.21, 76.23.145.197, 89.248.169.108, 89.248.169.109, 116.24.101.113, 149.9.0.27, 149.9.0.108, 149.9.0.57, 149.9.0.59, 149.9.0.58, 77.201.144.80, 82.13.0.145, 81.221.119.140, 68.200.57.221
ExcludeExitNodes 204.8.156.142, 206.222.29.14, 82.28.95.21, 76.23.145.197, 89.248.169.108, 89.248.169.109, 116.24.101.113,149.9.0.27, 149.9.0.108, 149.9.0.57, 149.9.0.59, 149.9.0.58, 77.201.144.80, 82.13.0.145, 81.221.119.140, 68.200.57.221
NumEntryGuards 8
DirReqStatistics 1
EntryStatistics 1
CellStatistics 1
ExitPortStatistics 1
GeoIPFile /home/starslights/tor/src/config/geoip
SocksPort 9050
SocksListenAddress 127.0.0.1
ControlPort 9051
HashedControlPassword 16:B85F607D5FFD40826036205F237ACC64B0D51D741C7AC0C98529749EAC
Nickname SwissTorExit
ContactInfo starslights AT breakthru dot com
ORPort 80
ORListenAddress 0.0.0.0:9090
DirPort 443
DirListenAddress 0.0.0.0:9091
ExitPolicy accept *:*
BandwidthRate 200 KB
BandwidthBurst 3000 KB
ExtraInfoStatistics 1
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: stars
https://gitlab.torproject.org/tpo/core/tor/-/issues/1073
tor crashed, core dumped
2020-06-27T14:09:50Z
aaronsw
tor crashed, core dumped
I was running tor when it crashed abruptly. Unfortunately the binary was stripped so this backtrace is rather uninformative. I've built a new binary with symbols in it and will try to catch it next time.
Core was generated by `/usr/sbin...
I was running tor when it crashed abruptly. Unfortunately the binary was stripped so this backtrace is rather uninformative. I've built a new binary with symbols in it and will try to catch it next time.
Core was generated by `/usr/sbin/tor'.
Program terminated with signal 11, Segmentation fault.
[New process 8221]
#0 0x0000000000474bea in ?? ()
(gdb) bt
#0 0x0000000000474bea in ?? ()
#1 0x0000000000419338 in ?? ()
legacy/trac#2 0x000000000042fb10 in ?? ()
legacy/trac#3 0x000000000040ed12 in ?? ()
legacy/trac#4 0x000000000046e4c9 in ?? ()
legacy/trac#5 0x000000000046effb in ?? ()
legacy/trac#6 0x000000000041a376 in ?? ()
legacy/trac#7 0x0000000000434a1d in ?? ()
legacy/trac#8 0x0000000000435e7c in ?? ()
legacy/trac#9 0x000000000042bcc8 in ?? ()
legacy/trac#10 0x00000000004620be in ?? ()
legacy/trac#11 0x00007f293171f67d in event_base_loop () from /usr/lib/libevent-1.3e.so.1
legacy/trac#12 0x0000000000461cc6 in ?? ()
legacy/trac#13 0x0000000000461f15 in ?? ()
legacy/trac#14 0x00007f29309cd466 in __libc_start_main () from /lib/libc.so.6
legacy/trac#15 0x0000000000407419 in ?? ()
legacy/trac#16 0x00007fff39d685c8 in ?? ()
legacy/trac#17 0x000000000000001c in ?? ()
legacy/trac#18 0x0000000000000001 in ?? ()
legacy/trac#19 0x00007fff39d68a50 in ?? ()
legacy/trac#20 0x0000000000000000 in ?? ()
(gdb)
[Automatically added by flyspray2trac: Operating System: Other Linux]
https://gitlab.torproject.org/tpo/core/tor/-/issues/1074
Tor sends clock_skew status event warn too liberally
2020-06-27T14:09:50Z
Roger Dingledine
Tor sends clock_skew status event warn too liberally
In command.c, if netinfo tells us our clock is skewed, we log based on:
if (router_digest_is_trusted_dir(conn->identity_digest))
severity = LOG_WARN;
else
severity = LOG_INFO;
But then we complain to the controller r...
In command.c, if netinfo tells us our clock is skewed, we log based on:
if (router_digest_is_trusted_dir(conn->identity_digest))
severity = LOG_WARN;
else
severity = LOG_INFO;
But then we complain to the controller regardless of whether it's an authority:
control_event_general_status(LOG_WARN,
"CLOCK_SKEW SKEW=%ld SOURCE=OR:%s:%d",
apparent_skew, conn->_base.address, conn->_base.port);
So the simple fix is for 0.2.1.20 to only send the status event if
severity == LOG_WARN.
Then Vidalia should workaround it by ignoring SOURCE=OR: clock skew events
from Tor <= 0.2.1.19 and 0.2.2.1-alpha.
The broader challenge is that tor clients avoid going to the authorities, so
if their clock is wrong, they'll never do more than log at log-level info, and
all this status event work is for naught.
We should fix this in 0.2.2.x, either with a more aggressive proposal, or at least
with a bit we remember that makes us connect to an authority (and thus get a
trusted opinion on our time) if we keep getting skew problems from other relays.
[Automatically added by flyspray2trac: Operating System: All]
Tor: unspecified
https://gitlab.torproject.org/tpo/core/tor/-/issues/1075
reachability controller status events too liberal
2020-06-27T14:09:50Z
Roger Dingledine
reachability controller status events too liberal
<edmanm:#vidalia> arma: so i guess tor throws a REACHABILITY_FAILED event for
+every testing circuit that fails (but not necessarily a CHECKING_REACHABILITY
+event for every testing circuit it launches).
<edmanm:#vidalia> is there a part...
<edmanm:#vidalia> arma: so i guess tor throws a REACHABILITY_FAILED event for
+every testing circuit that fails (but not necessarily a CHECKING_REACHABILITY
+event for every testing circuit it launches).
<edmanm:#vidalia> is there a particular threshold of failures at which tor
+decides "ok, i'm really not reachable. user needs to fix his network."?
<edmanm:#vidalia> or if i wait long enough will i finally get a
+REACHABILITY_FAILED event with an ERR severity?
[Automatically added by flyspray2trac: Operating System: All]
Tor: unspecified
https://gitlab.torproject.org/tpo/core/tor/-/issues/1076
unit parsing broken/changed from 0.2.1.19
2020-06-27T14:09:49Z
Sebastian Hahn
unit parsing broken/changed from 0.2.1.19
It appears that d4b31cf98f85550155156726ad9f3424def07fb7
changed the behaviour of option parsing when a line like
"RelayBandwidthRate 50KBytes" is present. This will be interpreted as
50 bytes. Changing the line to read "RelayBandwidthR...
It appears that d4b31cf98f85550155156726ad9f3424def07fb7
changed the behaviour of option parsing when a line like
"RelayBandwidthRate 50KBytes" is present. This will be interpreted as
50 bytes. Changing the line to read "RelayBandwidthRate 50 KBytes"
fixes the issue.
I'm unsure how to fix, it seems certain that we can't use
smartlist_split_string because we don't know where to split.
Problem found by Tas
[Automatically added by flyspray2trac: Operating System: All]
https://gitlab.torproject.org/tpo/core/tor/-/issues/1090
Warning about using an excluded node for exit
2020-06-27T14:09:49Z
Sebastian Hahn
Warning about using an excluded node for exit
Quite a few people have reported warnings in their logs when using
Exclude*Nodes in their torrc. We should track down why this happens,
and fix.
I opened the bug so we can keep track of ideas/problem reports. A
typical log line would be...
Quite a few people have reported warnings in their logs when using
Exclude*Nodes in their torrc. We should track down why this happens,
and fix.
I opened the bug so we can keep track of ideas/problem reports. A
typical log line would be
[Warning] Requested exit node '..' is in ExcludeNodes or ExcludeExitNodes.. Using anyway.
[Automatically added by flyspray2trac: Operating System: All]
Tor: 0.2.2.x-final
Nick Mathewson
Nick Mathewson
https://gitlab.torproject.org/tpo/core/tor/-/issues/1092
Hidden Service is up after some hours
2020-06-27T14:09:49Z
Trac
Hidden Service is up after some hours
Ok so I've configured hidden service for use with tor 0.2.1.19 with my ubuntu 9.04 xen vps box, and it went up after about 3-4 hours, which i think is DAMN LONG. about 1:30 hours before my hs went up i enabled debug.log in my torrc file ...
Ok so I've configured hidden service for use with tor 0.2.1.19 with my ubuntu 9.04 xen vps box, and it went up after about 3-4 hours, which i think is DAMN LONG. about 1:30 hours before my hs went up i enabled debug.log in my torrc file (contents below).
here are the details:
box: Ubuntu 9.04 x86_64 xen VPS
kernel: 2.6.18-128.1.10.el5xen
tor version: 0.2.1.19 from http://mirror.noreply.org/pub/tor repo
/var/log/tor/debug.log:
Sep 12 13:20:28.479 [info] rend_service_load_keys(): Loading hidden-service keys from "/var/lib/tor/6ircn/"
Sep 12 13:20:28.511 [info] rend_service_load_keys(): Loading hidden-service keys from "/var/lib/tor/6ircn/"
Sep 12 13:20:31.364 [info] circuit_predict_and_launch_new(): Have 2 clean circs (0 internal), need another internal circ for my hidden service.
Sep 12 13:20:32.368 [info] circuit_predict_and_launch_new(): Have 3 clean circs (1 internal), need another internal circ for my hidden service.
Sep 12 13:20:33.372 [info] circuit_predict_and_launch_new(): Have 4 clean circs (2 internal), need another internal circ for my hidden service.
Sep 12 13:21:12.525 [info] upload_service_descriptor(): Sending publish request for hidden service coimvmqgv2m33j7g
Sep 12 13:21:12.525 [debug] directory_initiate_command_rend(): Initiating hidden-service v2 descriptor upload
Sep 12 13:21:12.526 [info] directory_post_to_hs_dir(): Sending publish request for v2 descriptor for service '[scrubbed]' with descriptor ID '[scrubbed]' with validity of 31916 seconds to hidden service directory '42' on port 9030.
Sep 12 13:21:12.526 [debug] directory_initiate_command_rend(): Initiating hidden-service v2 descriptor upload
Sep 12 13:21:12.528 [info] directory_post_to_hs_dir(): Sending publish request for v2 descriptor for service '[scrubbed]' with descriptor ID '[scrubbed]' with validity of 31916 seconds to hidden service directory 'sophia' on port 0.
Sep 12 13:21:12.528 [debug] directory_initiate_command_rend(): Initiating hidden-service v2 descriptor upload
Sep 12 13:21:12.530 [info] directory_post_to_hs_dir(): Sending publish request for v2 descriptor for service '[scrubbed]' with descriptor ID '[scrubbed]' with validity of 31916 seconds to hidden service directory 'HW1' on port 9030.
Sep 12 13:21:12.530 [debug] directory_initiate_command_rend(): Initiating hidden-service v2 descriptor upload
Sep 12 13:21:12.532 [info] directory_post_to_hs_dir(): Sending publish request for v2 descriptor for service '[scrubbed]' with descriptor ID '[scrubbed]' with validity of 31916 seconds to hidden service directory 'minespar2c70fb' on port 0.
Sep 12 13:21:12.532 [debug] directory_initiate_command_rend(): Initiating hidden-service v2 descriptor upload
Sep 12 13:21:12.534 [info] directory_post_to_hs_dir(): Sending publish request for v2 descriptor for service '[scrubbed]' with descriptor ID '[scrubbed]' with validity of 31916 seconds to hidden service directory 'ZbiG' on port 9030.
Sep 12 13:21:12.534 [debug] directory_initiate_command_rend(): Initiating hidden-service v2 descriptor upload
Sep 12 13:21:12.536 [info] directory_post_to_hs_dir(): Sending publish request for v2 descriptor for service '[scrubbed]' with descriptor ID '[scrubbed]' with validity of 31916 seconds to hidden service directory 'PPrivComGermany4' on port 0.
Sep 12 13:21:14.543 [info] upload_service_descriptor(): Sending publish request for hidden service coimvmqgv2m33j7g
Sep 12 13:21:14.543 [debug] directory_initiate_command_rend(): Initiating hidden-service descriptor upload
Sep 12 13:21:14.546 [debug] directory_initiate_command_rend(): Initiating hidden-service descriptor upload
Sep 12 13:21:14.548 [debug] directory_initiate_command_rend(): Initiating hidden-service descriptor upload
Sep 12 13:21:29.803 [info] circuit_predict_and_launch_new(): Have 9 clean circs (2 internal), need another internal circ for my hidden service.
Sep 12 13:21:31.811 [info] circuit_predict_and_launch_new(): Have 8 clean circs (2 internal), need another internal circ for my hidden service.
Sep 12 13:21:33.820 [info] circuit_predict_and_launch_new(): Have 8 clean circs (2 internal), need another internal circ for my hidden service.
Sep 12 13:22:01.935 [info] upload_service_descriptor(): Sending publish request for hidden service coimvmqgv2m33j7g
Sep 12 13:22:01.935 [debug] directory_initiate_command_rend(): Initiating hidden-service descriptor upload
Sep 12 13:22:01.935 [debug] directory_initiate_command_rend(): Initiating hidden-service descriptor upload
Sep 12 13:22:01.935 [debug] directory_initiate_command_rend(): Initiating hidden-service descriptor upload
Sep 12 13:22:13.993 [info] upload_service_descriptor(): Sending publish request for hidden service coimvmqgv2m33j7g
Sep 12 13:22:13.993 [debug] directory_initiate_command_rend(): Initiating hidden-service v2 descriptor upload
Sep 12 13:22:13.993 [info] directory_post_to_hs_dir(): Sending publish request for v2 descriptor for service '[scrubbed]' with descriptor ID '[scrubbed]' with validity of 31855 seconds to hidden service directory '42' on port 9030.
Sep 12 13:22:13.993 [debug] directory_initiate_command_rend(): Initiating hidden-service v2 descriptor upload
Sep 12 13:22:13.993 [info] directory_post_to_hs_dir(): Sending publish request for v2 descriptor for service '[scrubbed]' with descriptor ID '[scrubbed]' with validity of 31855 seconds to hidden service directory 'sophia' on port 0.
Sep 12 13:22:13.993 [debug] directory_initiate_command_rend(): Initiating hidden-service v2 descriptor upload
Sep 12 13:22:13.993 [info] directory_post_to_hs_dir(): Sending publish request for v2 descriptor for service '[scrubbed]' with descriptor ID '[scrubbed]' with validity of 31855 seconds to hidden service directory 'HW1' on port 9030.
Sep 12 13:22:13.993 [debug] directory_initiate_command_rend(): Initiating hidden-service v2 descriptor upload
Sep 12 13:22:13.993 [info] directory_post_to_hs_dir(): Sending publish request for v2 descriptor for service '[scrubbed]' with descriptor ID '[scrubbed]' with validity of 31855 seconds to hidden service directory 'minespar2c70fb' on port 0.
Sep 12 13:22:13.993 [debug] directory_initiate_command_rend(): Initiating hidden-service v2 descriptor upload
Sep 12 13:22:13.993 [info] directory_post_to_hs_dir(): Sending publish request for v2 descriptor for service '[scrubbed]' with descriptor ID '[scrubbed]' with validity of 31855 seconds to hidden service directory 'ZbiG' on port 9030.
Sep 12 13:22:13.993 [debug] directory_initiate_command_rend(): Initiating hidden-service v2 descriptor upload
Sep 12 13:22:13.993 [info] directory_post_to_hs_dir(): Sending publish request for v2 descriptor for service '[scrubbed]' with descriptor ID '[scrubbed]' with validity of 31855 seconds to hidden service directory 'PPrivComGermany4' on port 0.
Sep 12 13:22:29.103 [info] circuit_predict_and_launch_new(): Have 7 clean circs (2 internal), need another internal circ for my hidden service.
Sep 12 13:22:33.120 [info] circuit_predict_and_launch_new(): Have 7 clean circs (2 internal), need another internal circ for my hidden service.
Sep 12 13:23:01.236 [info] upload_service_descriptor(): Sending publish request for hidden service coimvmqgv2m33j7g
Sep 12 13:23:01.236 [debug] directory_initiate_command_rend(): Initiating hidden-service v2 descriptor upload
Sep 12 13:23:01.236 [info] directory_post_to_hs_dir(): Sending publish request for v2 descriptor for service '[scrubbed]' with descriptor ID '[scrubbed]' with validity of 31807 seconds to hidden service directory '42' on port 9030.
Sep 12 13:23:01.236 [debug] directory_initiate_command_rend(): Initiating hidden-service v2 descriptor upload
Sep 12 13:23:01.236 [info] directory_post_to_hs_dir(): Sending publish request for v2 descriptor for service '[scrubbed]' with descriptor ID '[scrubbed]' with validity of 31807 seconds to hidden service directory 'sophia' on port 0.
Sep 12 13:23:01.236 [debug] directory_initiate_command_rend(): Initiating hidden-service v2 descriptor upload
Sep 12 13:23:01.236 [info] directory_post_to_hs_dir(): Sending publish request for v2 descriptor for service '[scrubbed]' with descriptor ID '[scrubbed]' with validity of 31807 seconds to hidden service directory 'HW1' on port 9030.
Sep 12 13:23:01.236 [debug] directory_initiate_command_rend(): Initiating hidden-service v2 descriptor upload
Sep 12 13:23:01.236 [info] directory_post_to_hs_dir(): Sending publish request for v2 descriptor for service '[scrubbed]' with descriptor ID '[scrubbed]' with validity of 31807 seconds to hidden service directory 'minespar2c70fb' on port 0.
Sep 12 13:23:01.236 [debug] directory_initiate_command_rend(): Initiating hidden-service v2 descriptor upload
Sep 12 13:23:01.236 [info] directory_post_to_hs_dir(): Sending publish request for v2 descriptor for service '[scrubbed]' with descriptor ID '[scrubbed]' with validity of 31807 seconds to hidden service directory 'ZbiG' on port 9030.
Sep 12 13:23:01.236 [debug] directory_initiate_command_rend(): Initiating hidden-service v2 descriptor upload
Sep 12 13:23:01.236 [info] directory_post_to_hs_dir(): Sending publish request for v2 descriptor for service '[scrubbed]' with descriptor ID '[scrubbed]' with validity of 31807 seconds to hidden service directory 'PPrivComGermany4' on port 0.
Sep 12 13:23:29.351 [info] circuit_predict_and_launch_new(): Have 5 clean circs (2 internal), need another internal circ for my hidden service.
Sep 12 13:23:33.367 [info] circuit_predict_and_launch_new(): Have 5 clean circs (2 internal), need another internal circ for my hidden service.
Sep 12 13:24:29.595 [info] circuit_predict_and_launch_new(): Have 3 clean circs (2 internal), need another internal circ for my hidden service.
Sep 12 13:24:33.612 [info] circuit_predict_and_launch_new(): Have 3 clean circs (2 internal), need another internal circ for my hidden service.
Sep 12 13:25:33.779 [info] circuit_predict_and_launch_new(): Have 3 clean circs (2 internal), need another internal circ for my hidden service.
Sep 12 14:21:58.919 [info] circuit_predict_and_launch_new(): Have 4 clean circs (2 internal), need another internal circ for my hidden service.
Sep 12 14:22:02.932 [info] upload_service_descriptor(): Sending publish request for hidden service coimvmqgv2m33j7g
Sep 12 14:22:02.932 [debug] directory_initiate_command_rend(): Initiating hidden-service descriptor upload
Sep 12 14:22:02.933 [debug] directory_initiate_command_rend(): Initiating hidden-service descriptor upload
Sep 12 14:22:02.934 [debug] directory_initiate_command_rend(): Initiating hidden-service descriptor upload
Sep 12 14:22:58.087 [info] circuit_predict_and_launch_new(): Have 2 clean circs (2 internal), need another internal circ for my hidden service.
Sep 12 14:23:02.101 [info] upload_service_descriptor(): Sending publish request for hidden service coimvmqgv2m33j7g
Sep 12 14:23:02.101 [debug] directory_initiate_command_rend(): Initiating hidden-service v2 descriptor upload
Sep 12 14:23:02.103 [info] directory_post_to_hs_dir(): Sending publish request for v2 descriptor for service '[scrubbed]' with descriptor ID '[scrubbed]' with validity of 28206 seconds to hidden service directory '42' on port 9030.
Sep 12 14:23:02.103 [debug] directory_initiate_command_rend(): Initiating hidden-service v2 descriptor upload
Sep 12 14:23:02.105 [info] directory_post_to_hs_dir(): Sending publish request for v2 descriptor for service '[scrubbed]' with descriptor ID '[scrubbed]' with validity of 28206 seconds to hidden service directory 'sophia' on port 0.
Sep 12 14:23:02.105 [debug] directory_initiate_command_rend(): Initiating hidden-service v2 descriptor upload
Sep 12 14:23:02.107 [info] directory_post_to_hs_dir(): Sending publish request for v2 descriptor for service '[scrubbed]' with descriptor ID '[scrubbed]' with validity of 28206 seconds to hidden service directory 'HW1' on port 9030.
Sep 12 14:23:02.107 [debug] directory_initiate_command_rend(): Initiating hidden-service v2 descriptor upload
Sep 12 14:23:02.109 [info] directory_post_to_hs_dir(): Sending publish request for v2 descriptor for service '[scrubbed]' with descriptor ID '[scrubbed]' with validity of 28206 seconds to hidden service directory 'minespar2c70fb' on port 0.
Sep 12 14:23:02.110 [debug] directory_initiate_command_rend(): Initiating hidden-service v2 descriptor upload
Sep 12 14:23:02.111 [info] directory_post_to_hs_dir(): Sending publish request for v2 descriptor for service '[scrubbed]' with descriptor ID '[scrubbed]' with validity of 28206 seconds to hidden service directory 'ZbiG' on port 9030.
Sep 12 14:23:02.111 [debug] directory_initiate_command_rend(): Initiating hidden-service v2 descriptor upload
Sep 12 14:23:02.113 [info] directory_post_to_hs_dir(): Sending publish request for v2 descriptor for service '[scrubbed]' with descriptor ID '[scrubbed]' with validity of 28206 seconds to hidden service directory 'PPrivComGermany4' on port 0.
Sep 12 14:23:14.533 [debug] connection_dir_client_reached_eof(): Received response from directory server '94.78.156.90:65006': 503 "Currently not acting as v2 hidden service directory"
Sep 12 14:23:14.533 [info] connection_dir_client_reached_eof(): Received http status code 503 ("Currently not acting as v2 hidden service directory") from server '94.78.156.90:65006'. I'll try again soon.
Sep 12 14:23:58.343 [info] circuit_predict_and_launch_new(): Have 5 clean circs (2 internal), need another internal circ for my hidden service.
Sep 12 14:24:33.480 [info] circuit_predict_and_launch_new(): Have 3 clean circs (2 internal), need another internal circ for my hidden service.
Sep 12 14:24:58.582 [info] circuit_predict_and_launch_new(): Have 3 clean circs (2 internal), need another internal circ for my hidden service.
Sep 12 14:25:33.633 [info] circuit_predict_and_launch_new(): Have 2 clean circs (2 internal), need another internal circ for my hidden service.
Sep 12 14:25:35.636 [info] circuit_predict_and_launch_new(): Have 2 clean circs (2 internal), need another internal circ for my hidden service.
Sep 12 14:25:58.646 [info] circuit_predict_and_launch_new(): Have 2 clean circs (2 internal), need another internal circ for my hidden service.
Sep 12 14:26:33.664 [info] circuit_predict_and_launch_new(): Have 2 clean circs (2 internal), need another internal circ for my hidden service.
Sep 12 14:26:35.672 [info] circuit_predict_and_launch_new(): Have 2 clean circs (2 internal), need another internal circ for my hidden service.
Sep 12 14:47:24.908 [info] circuit_predict_and_launch_new(): Have 2 clean circs (2 internal), need another internal circ for my hidden service.
Sep 12 14:48:24.955 [info] circuit_predict_and_launch_new(): Have 2 clean circs (2 internal), need another internal circ for my hidden service.
Sep 12 14:49:24.999 [info] circuit_predict_and_launch_new(): Have 2 clean circs (2 internal), need another internal circ for my hidden service.
Sep 12 14:50:48.060 [info] circuit_predict_and_launch_new(): Have 2 clean circs (2 internal), need another internal circ for my hidden service.
Sep 12 14:51:48.096 [info] circuit_predict_and_launch_new(): Have 2 clean circs (2 internal), need another internal circ for my hidden service.
Sep 12 14:59:04.451 [info] circuit_predict_and_launch_new(): Have 2 clean circs (2 internal), need another internal circ for my hidden service.
Sep 12 15:00:30.532 [info] circuit_predict_and_launch_new(): Have 2 clean circs (2 internal), need another internal circ for my hidden service.
/var/log/tor/notices.log:
Sep 12 13:20:28.477 [notice] Tor 0.2.1.19 opening new log file.
Sep 12 13:20:28.533 [notice] Parsing GEOIP file.
Sep 12 13:20:29.067 [notice] We now have enough directory information to build circuits.
Sep 12 13:20:29.067 [notice] Bootstrapped 80%: Connecting to the Tor network.
Sep 12 13:20:29.356 [notice] Bootstrapped 85%: Finishing handshake with first hop.
Sep 12 13:20:30.538 [notice] Bootstrapped 90%: Establishing a Tor circuit.
Sep 12 13:20:33.567 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Sep 12 13:20:33.567 [notice] Bootstrapped 100%: Done.
Sep 12 15:01:19.591 [notice] Our directory information is no longer up-to-date enough to build circuits: We have no recent network-status consensus.
/var/log/tor/log:
Sep 12 12:20:00.163 [notice] Tor 0.2.1.19 opening log file.
Sep 12 12:20:00.305 [notice] Parsing GEOIP file.
Sep 12 12:20:00.959 [notice] We now have enough directory information to build circuits.
Sep 12 12:20:00.960 [notice] Bootstrapped 80%: Connecting to the Tor network.
Sep 12 12:25:01.075 [notice] Bootstrapped 85%: Finishing handshake with first hop.
Sep 12 12:25:02.281 [notice] Bootstrapped 90%: Establishing a Tor circuit.
Sep 12 12:25:05.788 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Sep 12 12:25:05.788 [notice] Bootstrapped 100%: Done.
Sep 12 12:26:01.577 [notice] No Tor server allows exit to [scrubbed]:6667. Rejecting.
Sep 12 12:28:46.771 [notice] No Tor server allows exit to [scrubbed]:6667. Rejecting.
Sep 12 12:28:50.337 [notice] No Tor server allows exit to [scrubbed]:22. Rejecting.
Sep 12 12:36:31.089 [warn] Socks version 99 not recognized. (Tor is not an http proxy.)
Sep 12 12:36:31.116 [warn] Fetching socks handshake failed. Closing.
Sep 12 12:43:13.989 [notice] Received reload signal (hup). Reloading config and resetting internal state.
Sep 12 12:43:13.991 [notice] Tor 0.2.1.19 opening log file.
Sep 12 12:44:07.010 [notice] Interrupt: exiting cleanly.
Sep 12 12:44:09.083 [notice] Tor 0.2.1.19 opening log file.
Sep 12 12:44:09.118 [notice] Parsing GEOIP file.
Sep 12 12:44:09.643 [notice] We now have enough directory information to build circuits.
Sep 12 12:44:09.643 [notice] Bootstrapped 80%: Connecting to the Tor network.
Sep 12 12:44:09.900 [notice] Bootstrapped 85%: Finishing handshake with first hop.
Sep 12 12:44:11.078 [notice] Bootstrapped 90%: Establishing a Tor circuit.
Sep 12 12:44:12.874 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Sep 12 12:44:12.874 [notice] Bootstrapped 100%: Done.
Sep 12 12:46:31.132 [notice] Interrupt: exiting cleanly.
Sep 12 12:46:33.163 [notice] Tor 0.2.1.19 opening log file.
Sep 12 12:46:33.197 [notice] Parsing GEOIP file.
Sep 12 12:46:33.724 [notice] We now have enough directory information to build circuits.
Sep 12 12:46:33.724 [notice] Bootstrapped 80%: Connecting to the Tor network.
Sep 12 12:46:33.960 [notice] Bootstrapped 85%: Finishing handshake with first hop.
Sep 12 12:46:35.137 [notice] Bootstrapped 90%: Establishing a Tor circuit.
Sep 12 12:46:36.827 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Sep 12 12:46:36.827 [notice] Bootstrapped 100%: Done.
Sep 12 12:50:33.190 [notice] Interrupt: exiting cleanly.
Sep 12 12:50:35.222 [notice] Tor 0.2.1.19 opening log file.
Sep 12 12:50:35.234 [notice] Parsing GEOIP file.
Sep 12 12:50:35.710 [notice] We now have enough directory information to build circuits.
Sep 12 12:50:35.710 [notice] Bootstrapped 80%: Connecting to the Tor network.
Sep 12 12:50:35.947 [notice] Bootstrapped 85%: Finishing handshake with first hop.
Sep 12 12:50:37.126 [notice] Bootstrapped 90%: Establishing a Tor circuit.
Sep 12 12:50:39.443 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Sep 12 12:50:39.443 [notice] Bootstrapped 100%: Done.
Sep 12 13:20:26.450 [notice] Interrupt: exiting cleanly.
i've talked with Sebastian on #tor and he asked me to file this bug report.
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: illuminai
https://gitlab.torproject.org/tpo/core/tor/-/issues/1095
Possible Back Door in Tor Reported
2020-06-27T14:09:49Z
Trac
Possible Back Door in Tor Reported
Comments like this are popping up all over the net vis-a-vie the fact that tor is
reporting in it's log that it is using excluded nodes with impunity...
This bug should be fixed urgently as it has the potential to serious undermine tor'...
Comments like this are popping up all over the net vis-a-vie the fact that tor is
reporting in it's log that it is using excluded nodes with impunity...
This bug should be fixed urgently as it has the potential to serious undermine tor's
user base and confidence in it's functional anonymity.
"The fact that Tor ignores very specific instructions to connect to a
place I certainly do not want to connect to, and the amount of times
these nodes come up, really, really, makes me wonder about the
trustworthiness of the entire project. I'd like to hear from Roger or
another one of the Tor devs - what's with Tor being hell-bent on
connecting to a series of systems in DC with sequential IP addresses
and no hostnames? Why is traffic being sent to those mysterious
systems, despite my instructions and wishes? "
"Its working for normal internet and has
been doing so for years, it's only ONION sites where they deliberatly
let this "NSA spy feature" remain, to decrease privacy."
"Agreed. Happened to me just now also. My report of it is under the Bad
Exit Nodes topic. Further more, I've never seen this happen with
non-NSA spy nodes, period. Mine was "jalopy".
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: harris
https://gitlab.torproject.org/tpo/core/tor/-/issues/1097
Very recent version of Windows [major=6,minor=1]
2020-06-27T14:09:49Z
Roger Dingledine
Very recent version of Windows [major=6,minor=1]
Our Windows version detection code needs an update, now that
major=6 minor=1 is out (whatever that is).
[Automatically added by flyspray2trac: Operating System: All]
Our Windows version detection code needs an update, now that
major=6 minor=1 is out (whatever that is).
[Automatically added by flyspray2trac: Operating System: All]
Nick Mathewson
Nick Mathewson
https://gitlab.torproject.org/tpo/core/tor/-/issues/1099
Spurious bootstrap warnings if no-route-to-host
2020-06-27T14:09:49Z
Roger Dingledine
Spurious bootstrap warnings if no-route-to-host
Sep 19 22:42:11.251 [warn] Problem bootstrapping. Stuck at 85%: Finishing handshake with first hop. (No route to host; NOROUTE; count 1; recommendation warn)
$ telnet 89.54.142.227 443
Trying 89.54.142.227...
telnet: Unable to connect t...
Sep 19 22:42:11.251 [warn] Problem bootstrapping. Stuck at 85%: Finishing handshake with first hop. (No route to host; NOROUTE; count 1; recommendation warn)
$ telnet 89.54.142.227 443
Trying 89.54.142.227...
telnet: Unable to connect to remote host: No route to host
This isn't a problem with my network, it's a problem with that host.
And it looks like Tor can't tell the difference:
$ grep END_OR_CONN_REASON_NO_ROUTE *.h
or.h:#define END_OR_CONN_REASON_NO_ROUTE 6 /* no route to host/net */
We should teach it the difference.
Step one is to do this in errno_to_orconn_end_reason(), which I think will
solve the particular issue here.
Step two would be to solve it in tls_error_to_orconn_end_reason(), but I
bet that might be trickier.
[Automatically added by flyspray2trac: Operating System: All]
Tor: unspecified
https://gitlab.torproject.org/tpo/core/tor/-/issues/1100
problem to connecting to tor network
2020-06-27T14:09:48Z
Trac
problem to connecting to tor network
hi
i am from Iran, and i use tor for passing filtering,
from the uprising of people on friday(18 sep) at
first government stop https protocol and tor obviously has stoped,
and now after 2 days;
gmail, yahoo and many https services has ...
hi
i am from Iran, and i use tor for passing filtering,
from the uprising of people on friday(18 sep) at
first government stop https protocol and tor obviously has stoped,
and now after 2 days;
gmail, yahoo and many https services has been back but tor is not working
please help me slove this problem
the vidalia has been stoped at "establishing an encrypted directory connection"
status message
here is my log
Sep 20 19:56:14.937 [Notice] Tor v0.2.1.19. This is experimental software. Do not rely on it for strong anonymity. (Running on Windows "Longhorn" Service Pack 2 [workstation] {terminal services, single user})
Sep 20 19:56:14.937 [Notice] Initialized libevent version 1.4.11-stable using method win32. Good.
Sep 20 19:56:14.938 [Notice] Opening Socks listener on 127.0.0.1:9050
Sep 20 19:56:14.938 [Notice] Opening Control listener on 127.0.0.1:9051
Sep 20 19:56:15.045 [Notice] Parsing GEOIP file.
Sep 20 19:56:18.012 [Notice] Bootstrapped 10%: Finishing handshake with directory server.
Sep 20 19:56:47.990 [Notice] No current certificate known for authority moria1; launching request.
Sep 20 19:56:47.990 [Notice] No current certificate known for authority tor26; launching request.
Sep 20 19:56:47.990 [Notice] No current certificate known for authority dizum; launching request.
Sep 20 19:56:47.990 [Notice] No current certificate known for authority ides; launching request.
Sep 20 19:56:47.991 [Notice] No current certificate known for authority gabelmoo; launching request.
Sep 20 19:56:47.991 [Notice] No current certificate known for authority dannenberg; launching request.
Sep 20 19:58:19.065 [Notice] No current certificate known for authority moria1; launching request.
Sep 20 19:58:19.065 [Notice] No current certificate known for authority tor26; launching request.
Sep 20 19:58:19.065 [Notice] No current certificate known for authority dizum; launching request.
Sep 20 19:58:19.066 [Notice] No current certificate known for authority ides; launching request.
Sep 20 19:58:19.066 [Notice] No current certificate known for authority gabelmoo; launching request.
Sep 20 19:58:19.067 [Notice] No current certificate known for authority dannenberg; launching request.
Sep 20 20:04:25.521 [Notice] No current certificate known for authority moria1; launching request.
Sep 20 20:04:25.521 [Notice] No current certificate known for authority tor26; launching request.
Sep 20 20:04:25.521 [Notice] No current certificate known for authority dizum; launching request.
Sep 20 20:04:25.522 [Notice] No current certificate known for authority ides; launching request.
Sep 20 20:04:25.522 [Notice] No current certificate known for authority gabelmoo; launching request.
Sep 20 20:04:25.522 [Notice] No current certificate known for authority dannenberg; launching request.
Sep 20 20:15:36.221 [Notice] No current certificate known for authority moria1; launching request.
Sep 20 20:15:36.221 [Notice] No current certificate known for authority tor26; launching request.
Sep 20 20:15:36.222 [Notice] No current certificate known for authority dizum; launching request.
Sep 20 20:15:36.222 [Notice] No current certificate known for authority ides; launching request.
Sep 20 20:15:36.222 [Notice] No current certificate known for authority gabelmoo; launching request.
Sep 20 20:15:36.222 [Notice] No current certificate known for authority dannenberg; launching request.
thanks for your time
Mohsen
[Automatically added by flyspray2trac: Operating System: Windows Vista]
**Trac**:
**Username**: Mohsen
https://gitlab.torproject.org/tpo/core/tor/-/issues/1101
getinfo config-file doesn't handle relative paths well
2020-06-27T14:09:48Z
Roger Dingledine
getinfo config-file doesn't handle relative paths well
Here's how getinfo config-file is supposed to go:
getinfo config-file
250-config-file=/usr/local/etc/tor/torrc
250 OK
But I started my tor like "path/to/tor -f moria2-orrc", so getinfo
config-file simply returns "moria2-orrc" with no h...
Here's how getinfo config-file is supposed to go:
getinfo config-file
250-config-file=/usr/local/etc/tor/torrc
250 OK
But I started my tor like "path/to/tor -f moria2-orrc", so getinfo
config-file simply returns "moria2-orrc" with no hint about where
it is. That means controllers like arm don't know where to look.
Should we change Tor so it prepends an absolute path when answering
the controller?
[Automatically added by flyspray2trac: Operating System: All]
Tor: 0.2.3.x-final
https://gitlab.torproject.org/tpo/core/tor/-/issues/1103
circuit_build_times_generate_sample() asserting
2020-06-27T14:09:48Z
Roger Dingledine
circuit_build_times_generate_sample() asserting
Apparently running 0.2.2.2-alpha.
<hexa> my relay just died with 15:12:00 [ERR] Bug: circuitbuild.c:576:
circuit_build_times_generate_sample: Assertion q_lo < q_hi failed; aborting.
Looks like we should a) make this not fatal, and b) f...
Apparently running 0.2.2.2-alpha.
<hexa> my relay just died with 15:12:00 [ERR] Bug: circuitbuild.c:576:
circuit_build_times_generate_sample: Assertion q_lo < q_hi failed; aborting.
Looks like we should a) make this not fatal, and b) figure out if there's a
further bug.
[Automatically added by flyspray2trac: Operating System: All]
Mike Perry
Mike Perry
https://gitlab.torproject.org/tpo/core/tor/-/issues/1104
We should have an option that disables connections to bridge auth and fallback
2020-06-27T14:09:48Z
Sebastian Hahn
We should have an option that disables connections to bridge auth and fallback
] I meant UpdateBridgesFromAuthority 0
] Or does that not prevent connections to the Authority?
] If it doesn't, I think we should have some config option that means
"never talk to the bridge authority". Else it's easier to spot that
...
] I meant UpdateBridgesFromAuthority 0
] Or does that not prevent connections to the Authority?
] If it doesn't, I think we should have some config option that means
"never talk to the bridge authority". Else it's easier to spot that
someone is trying to use Tor
arma] right. we've never really solved that part of the problem. i
figured i'd do it once somebody blocks it.
arma] whether tor decides to go to the bridge authority directly
depends on a couple of things.
[Automatically added by flyspray2trac: Operating System: All]
Tor: unspecified
https://gitlab.torproject.org/tpo/core/tor/-/issues/1107
PublishServerDescriptor allows options 0 and 1 simultaneously
2020-06-27T14:09:48Z
Sebastian Hahn
PublishServerDescriptor allows options 0 and 1 simultaneously
That doesn't make sense, and I think we should reject a config like that.
[Automatically added by flyspray2trac: Operating System: All]
That doesn't make sense, and I think we should reject a config like that.
[Automatically added by flyspray2trac: Operating System: All]
Tor: 0.2.2.x-final
https://gitlab.torproject.org/tpo/core/tor/-/issues/1108
Assertion Failed
2020-06-27T14:09:48Z
Trac
Assertion Failed
I have to roll back to version 0.2.1.19-alpha
cause version 0.2.2.2-alpha did not start
[code]
Sep 28 11:04:21.640 [Notice] Tor v0.2.2.2-alpha (git-54ba86d9d0cff2ce). This is experimental software. Do not rely on it for strong anon...
I have to roll back to version 0.2.1.19-alpha
cause version 0.2.2.2-alpha did not start
[code]
Sep 28 11:04:21.640 [Notice] Tor v0.2.2.2-alpha (git-54ba86d9d0cff2ce). This is experimental software. Do not rely on it for strong anonymity. (Running on Windows XP Service Pack 3 [workstation] {terminal services, single user})
Sep 28 11:04:21.750 [Notice] Initialized libevent version 1.4.12-stable using method win32. Good.
Sep 28 11:04:21.750 [Notice] Opening OR listener on 0.0.0.0:9001
Sep 28 11:04:21.750 [Notice] Opening Directory listener on 0.0.0.0:563
Sep 28 11:04:21.750 [Notice] Opening Socks listener on 127.0.0.1:9050
Sep 28 11:04:21.750 [Notice] Opening Socks listener on 192.168.254.1:9050
Sep 28 11:04:21.750 [Notice] Opening DNS listener on 127.0.0.1:53
Sep 28 11:04:21.750 [Notice] Opening Control listener on 127.0.0.1:9051
Sep 28 11:04:21.796 [Error] Bug: circuitbuild.c:380: circuit_build_times_shuffle_array: Assertion cbt->total_build_times == cbt->build_times_idx failed; aborting.
Sep 28 11:05:28.062 [Notice] Tor v0.2.2.2-alpha (git-54ba86d9d0cff2ce). This is experimental software. Do not rely on it for strong anonymity. (Running on Windows XP Service Pack 3 [workstation] {terminal services, single user})
Sep 28 11:05:28.171 [Notice] Initialized libevent version 1.4.12-stable using method win32. Good.
Sep 28 11:05:28.171 [Notice] Opening OR listener on 0.0.0.0:9001
Sep 28 11:05:28.171 [Notice] Opening Directory listener on 0.0.0.0:563
Sep 28 11:05:28.171 [Notice] Opening Socks listener on 127.0.0.1:9050
Sep 28 11:05:28.171 [Notice] Opening Socks listener on 192.168.254.1:9050
Sep 28 11:05:28.171 [Notice] Opening DNS listener on 127.0.0.1:53
Sep 28 11:05:28.171 [Notice] Opening Control listener on 127.0.0.1:9051
Sep 28 11:05:28.218 [Error] Bug: circuitbuild.c:380: circuit_build_times_shuffle_array: Assertion cbt->total_build_times == cbt->build_times_idx failed; aborting.
Sep 28 11:08:06.468 [Notice] Tor v0.2.2.2-alpha (git-54ba86d9d0cff2ce). This is experimental software. Do not rely on it for strong anonymity. (Running on Windows XP Service Pack 3 [workstation] {terminal services, single user})
Sep 28 11:08:06.468 [Notice] Initialized libevent version 1.4.12-stable using method win32. Good.
Sep 28 11:08:06.468 [Notice] Opening OR listener on 0.0.0.0:9001
Sep 28 11:08:06.562 [Notice] Opening Directory listener on 0.0.0.0:563
Sep 28 11:08:06.562 [Notice] Opening Socks listener on 127.0.0.1:9050
Sep 28 11:08:06.562 [Notice] Opening Socks listener on 192.168.254.1:9050
Sep 28 11:08:06.562 [Notice] Opening DNS listener on 127.0.0.1:53
Sep 28 11:08:06.562 [Notice] Opening Control listener on 127.0.0.1:9051
[/code]
Thanks
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: crp
https://gitlab.torproject.org/tpo/core/tor/-/issues/1109
Assertion Failed
2020-06-27T14:09:48Z
Trac
Assertion Failed
I was´nt able to re-open , nor to add data to task 1108
thus, I am reporting this again
thanks
> Sep 28 15:06:13.968 [Notice] Tor v0.2.2.3-alpha
> (git-0f3417d1dbffdf7a). This is experimental software. Do not rely on
> it for strong a...
I was´nt able to re-open , nor to add data to task 1108
thus, I am reporting this again
thanks
> Sep 28 15:06:13.968 [Notice] Tor v0.2.2.3-alpha
> (git-0f3417d1dbffdf7a). This is experimental software. Do not rely on
> it for strong anonymity. (Running on Windows XP Service Pack 3
> [workstation] {terminal services, single user})
> Sep 28 15:06:14.187 [Notice] Initialized libevent version
> 1.4.12-stable using method win32. Good.
> Sep 28 15:06:14.187 [Notice] Opening OR listener on 0.0.0.0:9001
> Sep 28 15:06:14.296 [Notice] Opening Directory listener on 0.0.0.0:563
> Sep 28 15:06:14.406 [Notice] Opening Socks listener on 127.0.0.1:9050
> Sep 28 15:06:14.406 [Notice] Opening Socks listener on 192.168.254.1:9050
> Sep 28 15:06:14.406 [Notice] Opening DNS listener on 127.0.0.1:53
> Sep 28 15:06:14.406 [Notice] Opening Control listener on 127.0.0.1:9051
> Sep 28 15:06:14.437 [Error] Bug: circuitbuild.c:380:
> circuit_build_times_shuffle_array: Assertion cbt->total_build_times ==
> cbt->build_times_idx failed; aborting.
> Sep 28 15:07:19.296 [Notice] Tor v0.2.2.3-alpha
> (git-0f3417d1dbffdf7a). This is experimental software. Do not rely on
> it for strong anonymity. (Running on Windows XP Service Pack 3
> [workstation] {terminal services, single user})
> Sep 28 15:07:19.406 [Notice] Initialized libevent version
> 1.4.12-stable using method win32. Good.
> Sep 28 15:07:19.406 [Notice] Opening OR listener on 0.0.0.0:9001
> Sep 28 15:07:19.406 [Notice] Opening Directory listener on 0.0.0.0:563
> Sep 28 15:07:19.406 [Notice] Opening Socks listener on 127.0.0.1:9050
> Sep 28 15:07:19.406 [Notice] Opening Socks listener on 192.168.254.1:9050
> Sep 28 15:07:19.406 [Notice] Opening DNS listener on 127.0.0.1:53
> Sep 28 15:07:19.406 [Notice] Opening Control listener on 127.0.0.1:9051
> Sep 28 15:07:19.453 [Error] Bug: circuitbuild.c:380:
> circuit_build_times_shuffle_array: Assertion cbt->total_build_times ==
> cbt->build_times_idx failed; aborting.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: crp
https://gitlab.torproject.org/tpo/core/tor/-/issues/1111
assert on start up of 0.2.2.3-alpha
2020-06-27T14:09:47Z
Andrew Lewman
assert on start up of 0.2.2.3-alpha
On start up, Oct 02 07:38:44.749 [Error] Bug: circuitbuild.c:380: circuit_build_times_shuffle_array:
Assertion cbt->total_build_times == cbt->build_times_idx failed; aborting.
full log is:
Oct 02 07:42:06.995 [notice] Initialized libev...
On start up, Oct 02 07:38:44.749 [Error] Bug: circuitbuild.c:380: circuit_build_times_shuffle_array:
Assertion cbt->total_build_times == cbt->build_times_idx failed; aborting.
full log is:
Oct 02 07:42:06.995 [notice] Initialized libevent version 1.3e using method epoll. Good.
Oct 02 07:42:06.995 [notice] Opening Socks listener on 127.0.0.1:9050
Oct 02 07:42:06.995 [notice] Opening Control listener on 127.0.0.1:9051
Oct 02 07:42:07.011 [err] Bug: circuitbuild.c:380: circuit_build_times_shuffle_array: Assertion cbt->total_build_times == cbt->build_times_idx failed; aborting.
(gdb) bt
#0 0x00007ffe9e44afb5 in raise () from /lib/libc.so.6
#1 0x00007ffe9e44cbc3 in abort () from /lib/libc.so.6
legacy/trac#2 0x000000000040feb0 in circuit_build_times_parse_state (cbt=0x719f00, state=0x8918b0, msg=0x7fffa7a56a38) at circuitbuild.c:380
legacy/trac#3 0x0000000000425fbb in set_options (new_val=<value optimized out>, msg=<value optimized out>) at config.c:5075
legacy/trac#4 0x0000000000426561 in options_init_from_string (
cf=0x87d540 "# This file was generated by Tor; if you edit it, comments will not be preserved\n# The old torrc file was renamed to torrc.orig.1 or similar, and Tor will ignore it\n\nBridge 97.107.129.143:80 06008EDA5"..., command=<value optimized out>, command_arg=0x0, msg=0x7fffa7a56b40) at config.c:4287
legacy/trac#5 0x000000000042696a in options_init_from_torrc (argc=3, argv=0x7fffa7a56dd8) at config.c:4161
legacy/trac#6 0x0000000000463115 in tor_init (argc=3, argv=0x7fffa7a56dd8) at main.c:1873
legacy/trac#7 0x0000000000466d16 in tor_main (argc=3, argv=<value optimized out>) at main.c:2120
legacy/trac#8 0x00007ffe9e4365a6 in __libc_start_main () from /lib/libc.so.6
legacy/trac#9 0x0000000000407819 in _start () at ../sysdeps/x86_64/elf/start.S:113
[Automatically added by flyspray2trac: Operating System: Other Linux]
https://gitlab.torproject.org/tpo/core/tor/-/issues/1112
Tor can´t open directory
2020-06-27T14:09:47Z
Trac
Tor can´t open directory
After I installed Tor it ran. (I wanted to create a bridge, as requested in the blog ). After restarted the computer,
it doesn´t work. The message protocol says :
Okt 03 00:35:24.218 [Warnung] Error creating directory "C:\\Dokumente und...
After I installed Tor it ran. (I wanted to create a bridge, as requested in the blog ). After restarted the computer,
it doesn´t work. The message protocol says :
Okt 03 00:35:24.218 [Warnung] Error creating directory "C:\\Dokumente und Einstellungen\\*****\366rg\\Anwendungsdaten\\tor": Invalid argument
Okt 03 00:35:24.218 [Warnung] Failed to parse/validate config: Couldn't access/create private data directory ""C:\\Dokumente und Einstellungen\\*****\366rg\\Anwendungsdaten\\tor""
Okt 03 00:35:24.218 [Fehler] Reading config failed--see warnings above.
Im not the only one, this question I found, but it wasn´t solved:
http://www.multimediaxis.de/showthread.php?t=119538
Also other directorys I can´t open to write since then.
But I´ll wait for an answer, before I try to deinstall tor.
MfG h
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: h
https://gitlab.torproject.org/tpo/core/tor/-/issues/1113
Bridge relays should deny all exits by default
2020-06-27T14:09:47Z
Sebastian Hahn
Bridge relays should deny all exits by default
I think we should make it explicit that Bridges are entry points into
the Tor network, and not allow the default exit policy if no ExitPolicy
line is given.
Does that sound plausible?
[Automatically added by flyspray2trac: Operating Sy...
I think we should make it explicit that Bridges are entry points into
the Tor network, and not allow the default exit policy if no ExitPolicy
line is given.
Does that sound plausible?
[Automatically added by flyspray2trac: Operating System: All]
https://gitlab.torproject.org/tpo/core/tor/-/issues/1114
DH key warn message
2020-06-27T14:09:47Z
Trac
DH key warn message
Hello,
got this warnings on Debian Etch with Tor 0.2.0.35:
Sep 19 06:00:09.581 [warn] DH key must be at least 2.
Sep 19 06:00:09.581 [warn] Rejecting insecure DH key [0]
Sep 19 06:00:09.581 [warn] Rejected invalid g!^x
Sep 21 08:25:16....
Hello,
got this warnings on Debian Etch with Tor 0.2.0.35:
Sep 19 06:00:09.581 [warn] DH key must be at least 2.
Sep 19 06:00:09.581 [warn] Rejecting insecure DH key [0]
Sep 19 06:00:09.581 [warn] Rejected invalid g!^x
Sep 21 08:25:16.213 [warn] DH key must be at least 2.
Sep 21 08:25:16.213 [warn] Rejecting insecure DH key [0]
Sep 21 08:25:16.213 [warn] Rejected invalid g!^x
Sep 24 05:22:43.076 [warn] DH key must be at least 2.
Sep 24 05:22:43.077 [warn] Rejecting insecure DH key [0]
Sep 24 05:22:43.077 [warn] Rejected invalid g!^x
Sep 27 15:15:39.650 [warn] DH key must be at least 2.
Sep 27 15:15:39.650 [warn] Rejecting insecure DH key [0]
Sep 27 15:15:39.650 [warn] Rejected invalid g!^x
Sep 28 09:13:31.569 [warn] DH key must be at least 2.
Sep 28 09:13:31.569 [warn] Rejecting insecure DH key [0]
Sep 28 09:13:31.569 [warn] Rejected invalid g!^x
Sep 28 12:13:14.071 [warn] DH key must be at least 2.
Sep 28 12:13:14.071 [warn] Rejecting insecure DH key [0]
Sep 28 12:13:14.071 [warn] Rejected invalid g!^x
Sep 28 19:41:23.658 [warn] DH key must be at least 2.
Sep 28 19:41:23.659 [warn] Rejecting insecure DH key [0]
Sep 28 19:41:23.659 [warn] Rejected invalid g!^x
And also on Debian Lenny with Tor 0.2.2.3-alpha:
Sep 30 07:50:05.236 [warn] DH key must be at least 2.
Sep 30 07:50:05.236 [warn] Rejecting insecure DH key [0]
Sep 30 07:50:05.236 [warn] Rejected invalid g!^x
Oct 06 02:51:08.319 [warn] DH key must be at least 2.
Oct 06 02:51:08.319 [warn] Rejecting insecure DH key [0]
Oct 06 02:51:08.319 [warn] Rejected invalid g!^x
Anoyone else seeing them?
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: dragonfly
https://gitlab.torproject.org/tpo/core/tor/-/issues/1116
'Stable' flag assignment inconsistant
2020-06-27T14:09:47Z
Tom Lowenthal
'Stable' flag assignment inconsistant
Looking at a consensus document [though I used torstatus.all.de for ease of sorting data] it seems that the 'stable' flag
is not being consistently assigned.
According to the v3 directory specification at https://git.torproject.org/che...
Looking at a consensus document [though I used torstatus.all.de for ease of sorting data] it seems that the 'stable' flag
is not being consistently assigned.
According to the v3 directory specification at https://git.torproject.org/checkout/tor/master/doc/spec/dir-spec.txt ,
routers with a weighted MTBF more than either the median or seven days should be marked stable, and MTBF data more
than a month old shouldn't be that relevant when assigning the flag. Since the median uptime is about 3 days, one should
roughly expect that any router with more than 30 days of uptime (and which are still valid) should have the stable flag.
However when relays are sorted in order of uptime, several apparently-longrunning routers do not have the flag.
Since this data is liable to change as relays go up an down, here are some noted not-'stable' routers at the time of
writing. The routers have uptimes more than a month, so their (correctly) weighted MTBF should certainly be more than
a week, and more than the median, about three days.
wie6ud6be - 148d
anonymde - 112d
torpfaffenederorg - 110d
rentalsponge - 70d
xhyG5r96QGlRqL - 57d
niugnip - 56d
oeiwuqej - 49d
gremlin - 42d
editingconfigishard - 39d
[Automatically added by flyspray2trac: Operating System: All]
Tor: unspecified
https://gitlab.torproject.org/tpo/core/tor/-/issues/1117
bridge authorities mark every bridge stable+guard
2020-06-27T14:09:47Z
Roger Dingledine
bridge authorities mark every bridge stable+guard
Tonga lists every bridge as Stable and Guard.
Nick suggests this is because "bridge authorities don't count a
bridge as having Failed for MTBF purposes when they find it to be
non-Running"
[Automatically added by flyspray2trac: Operati...
Tonga lists every bridge as Stable and Guard.
Nick suggests this is because "bridge authorities don't count a
bridge as having Failed for MTBF purposes when they find it to be
non-Running"
[Automatically added by flyspray2trac: Operating System: All]
Tor: unspecified
Matthew Finkel
Matthew Finkel
https://gitlab.torproject.org/tpo/core/tor/-/issues/1118
0.2.2.4 fails to compile on osx x86
2020-06-27T14:09:47Z
Andrew Lewman
0.2.2.4 fails to compile on osx x86
gcc -DHAVE_CONFIG_H -I. -I../.. -DSHARE_DATADIR="\"/Library/Tor/share\"" -DLOCALSTATEDIR="\"/Library/Tor/var\"" -DBINDIR="\"/Library/Tor\"" -I../../src/common -I/usr/local/include -I../or -O -g -mmacosx-version-min=10.4 -isysroot /Dev...
gcc -DHAVE_CONFIG_H -I. -I../.. -DSHARE_DATADIR="\"/Library/Tor/share\"" -DLOCALSTATEDIR="\"/Library/Tor/var\"" -DBINDIR="\"/Library/Tor\"" -I../../src/common -I/usr/local/include -I../or -O -g -mmacosx-version-min=10.4 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -Wall -g -O2 -fno-strict-aliasing -c test.c
test.c:46:18: error: test.h: No such file or directory
test.c: In function ‘test_buffers’:
test.c:181: warning: implicit declaration of function ‘test_fail’
test.c:184: warning: implicit declaration of function ‘test_eq’
test.c:196: warning: implicit declaration of function ‘test_memeq’
test.c:400: warning: label ‘done’ defined but not used
test.c: In function ‘test_onion_handshake’:
test.c:427: warning: implicit declaration of function ‘test_assert’
test.c:445: warning: implicit declaration of function ‘test_memneq’
test.c:447: warning: label ‘done’ defined but not used
test.c: In function ‘test_circuit_timeout’:
test.c:612: warning: label ‘done’ defined but not used
test.c: In function ‘test_policy_summary_helper’:
test.c:637: warning: implicit declaration of function ‘test_streq’
test.c:639: warning: label ‘done’ defined but not used
test.c: In function ‘test_policies’:
test.c:792: warning: label ‘done’ defined but not used
test.c: In function ‘test_rend_fns’:
test.c:998: warning: label ‘done’ defined but not used
test.c: In function ‘test_geoip’:
test.c:1071: warning: label ‘done’ defined but not used
test.c: At top level:
test.c:1076: warning: ‘struct testcase_t’ declared inside parameter list
test.c:1076: warning: its scope is only this definition or declaration, which is probably not what you want
test.c: In function ‘legacy_test_setup’:
test.c:1078: error: dereferencing pointer to incomplete type
test.c: At top level:
test.c:1089: warning: ‘struct testcase_t’ declared inside parameter list
test.c:1096: error: variable ‘legacy_setup’ has initializer but incomplete type
test.c:1097: warning: excess elements in struct initializer
test.c:1097: warning: (near initialization for ‘legacy_setup’)
test.c:1098: warning: excess elements in struct initializer
test.c:1098: warning: (near initialization for ‘legacy_setup’)
test.c:1108: error: array type has incomplete element type
test.c:1116: error: ‘TT_SKIP’ undeclared here (not in a function)
test.c:1119: error: ‘END_OF_TESTCASES’ undeclared here (not in a function)
test.c:1121: error: array type has incomplete element type
test.c:1122: error: array type has incomplete element type
test.c:1123: error: array type has incomplete element type
test.c:1124: error: array type has incomplete element type
test.c:1125: error: array type has incomplete element type
test.c:1127: error: array type has incomplete element type
test.c:1135: error: ‘END_OF_GROUPS’ undeclared here (not in a function)
test.c: In function ‘main’:
test.c:1199: warning: implicit declaration of function ‘tinytest_main’
make[4]: *** [test.o] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all] Error 2
make: *** [dist-osx] Error 2
[Automatically added by flyspray2trac: Operating System: OSX 10.5 Leopard]
https://gitlab.torproject.org/tpo/core/tor/-/issues/1119
Tor 0.2.2.4-alpha build failure
2020-06-27T14:09:47Z
Andrew Lewman
Tor 0.2.2.4-alpha build failure
gcc -DHAVE_CONFIG_H -I. -I../.. -DSHARE_DATADIR="\"/Library/Tor/share\"" -DLOCALSTATEDIR="\"/Library/Tor/var\"" -DBINDIR="\"/Library/Tor\"" -I../../src/common -I../or -g -O2 -Wall -g -O2 -fno-strict-aliasing -MT test.o -MD -MP -MF .d...
gcc -DHAVE_CONFIG_H -I. -I../.. -DSHARE_DATADIR="\"/Library/Tor/share\"" -DLOCALSTATEDIR="\"/Library/Tor/var\"" -DBINDIR="\"/Library/Tor\"" -I../../src/common -I../or -g -O2 -Wall -g -O2 -fno-strict-aliasing -MT test.o -MD -MP -MF .deps/test.Tpo -c -o test.o test.c
test.c:46:18: test.h: No such file or directory
test.c: In function `test_buffers':
test.c:181: warning: implicit declaration of function `test_fail'
test.c:184: warning: implicit declaration of function `test_eq'
test.c:196: warning: implicit declaration of function `test_memeq'
test.c:400: warning: label `done' defined but not used
test.c: In function `test_onion_handshake':
test.c:427: warning: implicit declaration of function `test_assert'
test.c:445: warning: implicit declaration of function `test_memneq'
test.c:447: warning: label `done' defined but not used
test.c: In function `test_circuit_timeout':
test.c:612: warning: label `done' defined but not used
test.c: In function `test_policy_summary_helper':
test.c:637: warning: implicit declaration of function `test_streq'
test.c:639: warning: label `done' defined but not used
test.c: In function `test_policies':
test.c:792: warning: label `done' defined but not used
test.c: In function `test_rend_fns':
test.c:998: warning: label `done' defined but not used
test.c: In function `test_geoip':
test.c:1071: warning: label `done' defined but not used
test.c: In function `legacy_test_setup':
test.c:1078: error: dereferencing pointer to incomplete type
test.c: At top level:
test.c:1096: error: variable `legacy_setup' has initializer but incomplete type
test.c:1097: warning: excess elements in struct initializer
test.c:1097: warning: (near initialization for `legacy_setup')
test.c:1098: warning: excess elements in struct initializer
test.c:1098: warning: (near initialization for `legacy_setup')
test.c:1108: error: elements of array `test_array' have incomplete type
test.c:1109: warning: excess elements in struct initializer
test.c:1109: warning: (near initialization for `test_array[0]')
test.c:1109: warning: excess elements in struct initializer
test.c:1109: warning: (near initialization for `test_array[0]')
test.c:1109: warning: excess elements in struct initializer
test.c:1109: warning: (near initialization for `test_array[0]')
test.c:1109: warning: excess elements in struct initializer
test.c:1109: warning: (near initialization for `test_array[0]')
test.c:1109: warning: excess elements in struct initializer
test.c:1109: warning: (near initialization for `test_array[0]')
test.c:1110: warning: excess elements in struct initializer
test.c:1110: warning: (near initialization for `test_array[1]')
test.c:1110: warning: excess elements in struct initializer
test.c:1110: warning: (near initialization for `test_array[1]')
test.c:1110: warning: excess elements in struct initializer
test.c:1110: warning: (near initialization for `test_array[1]')
test.c:1110: warning: excess elements in struct initializer
test.c:1110: warning: (near initialization for `test_array[1]')
test.c:1110: warning: excess elements in struct initializer
test.c:1110: warning: (near initialization for `test_array[1]')
test.c:1111: warning: excess elements in struct initializer
test.c:1111: warning: (near initialization for `test_array[2]')
test.c:1111: warning: excess elements in struct initializer
test.c:1111: warning: (near initialization for `test_array[2]')
test.c:1111: warning: excess elements in struct initializer
test.c:1111: warning: (near initialization for `test_array[2]')
test.c:1111: warning: excess elements in struct initializer
test.c:1111: warning: (near initialization for `test_array[2]')
test.c:1111: warning: excess elements in struct initializer
test.c:1111: warning: (near initialization for `test_array[2]')
test.c:1112: warning: excess elements in struct initializer
test.c:1112: warning: (near initialization for `test_array[3]')
test.c:1112: warning: excess elements in struct initializer
test.c:1112: warning: (near initialization for `test_array[3]')
test.c:1112: warning: excess elements in struct initializer
test.c:1112: warning: (near initialization for `test_array[3]')
test.c:1112: warning: excess elements in struct initializer
test.c:1112: warning: (near initialization for `test_array[3]')
test.c:1112: warning: excess elements in struct initializer
test.c:1112: warning: (near initialization for `test_array[3]')
test.c:1113: warning: excess elements in struct initializer
test.c:1113: warning: (near initialization for `test_array[4]')
test.c:1113: warning: excess elements in struct initializer
test.c:1113: warning: (near initialization for `test_array[4]')
test.c:1113: warning: excess elements in struct initializer
test.c:1113: warning: (near initialization for `test_array[4]')
test.c:1113: warning: excess elements in struct initializer
test.c:1113: warning: (near initialization for `test_array[4]')
test.c:1113: warning: excess elements in struct initializer
test.c:1113: warning: (near initialization for `test_array[4]')
test.c:1114: warning: excess elements in struct initializer
test.c:1114: warning: (near initialization for `test_array[5]')
test.c:1114: warning: excess elements in struct initializer
test.c:1114: warning: (near initialization for `test_array[5]')
test.c:1114: warning: excess elements in struct initializer
test.c:1114: warning: (near initialization for `test_array[5]')
test.c:1114: warning: excess elements in struct initializer
test.c:1114: warning: (near initialization for `test_array[5]')
test.c:1114: warning: excess elements in struct initializer
test.c:1114: warning: (near initialization for `test_array[5]')
test.c:1116: warning: excess elements in struct initializer
test.c:1116: warning: (near initialization for `test_array[6]')
test.c:1116: warning: excess elements in struct initializer
test.c:1116: warning: (near initialization for `test_array[6]')
test.c:1116: error: `TT_SKIP' undeclared here (not in a function)
test.c:1116: warning: excess elements in struct initializer
test.c:1116: warning: (near initialization for `test_array[6]')
test.c:1116: warning: excess elements in struct initializer
test.c:1116: warning: (near initialization for `test_array[6]')
test.c:1116: warning: excess elements in struct initializer
test.c:1116: warning: (near initialization for `test_array[6]')
test.c:1117: warning: excess elements in struct initializer
test.c:1117: warning: (near initialization for `test_array[7]')
test.c:1117: warning: excess elements in struct initializer
test.c:1117: warning: (near initialization for `test_array[7]')
test.c:1117: error: `TT_SKIP' undeclared here (not in a function)
test.c:1117: warning: excess elements in struct initializer
test.c:1117: warning: (near initialization for `test_array[7]')
test.c:1117: warning: excess elements in struct initializer
test.c:1117: warning: (near initialization for `test_array[7]')
test.c:1117: warning: excess elements in struct initializer
test.c:1117: warning: (near initialization for `test_array[7]')
test.c:1119: error: `END_OF_TESTCASES' undeclared here (not in a function)
test.c:1119: error: initializer element is not constant
test.c:1119: error: (near initialization for `test_array[8]')
test.c:1127: error: elements of array `testgroups' have incomplete type
test.c:1128: warning: excess elements in struct initializer
test.c:1128: warning: (near initialization for `testgroups[0]')
test.c:1128: warning: excess elements in struct initializer
test.c:1128: warning: (near initialization for `testgroups[0]')
test.c:1129: warning: excess elements in struct initializer
test.c:1129: warning: (near initialization for `testgroups[1]')
test.c:1129: warning: excess elements in struct initializer
test.c:1129: warning: (near initialization for `testgroups[1]')
test.c:1130: warning: excess elements in struct initializer
test.c:1130: warning: (near initialization for `testgroups[2]')
test.c:1130: warning: excess elements in struct initializer
test.c:1130: warning: (near initialization for `testgroups[2]')
test.c:1131: warning: excess elements in struct initializer
test.c:1131: warning: (near initialization for `testgroups[3]')
test.c:1131: warning: excess elements in struct initializer
test.c:1131: warning: (near initialization for `testgroups[3]')
test.c:1132: warning: excess elements in struct initializer
test.c:1132: warning: (near initialization for `testgroups[4]')
test.c:1132: warning: excess elements in struct initializer
test.c:1132: warning: (near initialization for `testgroups[4]')
test.c:1133: warning: excess elements in struct initializer
test.c:1133: warning: (near initialization for `testgroups[5]')
test.c:1133: warning: excess elements in struct initializer
test.c:1133: warning: (near initialization for `testgroups[5]')
test.c:1135: error: `END_OF_GROUPS' undeclared here (not in a function)
test.c:1135: error: initializer element is not constant
test.c:1135: error: (near initialization for `testgroups[6]')
test.c: In function `main':
test.c:1199: warning: implicit declaration of function `tinytest_main'
../or/or.h: At top level:
test.c:1096: error: storage size of `legacy_setup' isn't known
make[4]: *** [test.o] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all] Error 2
make: *** [dist-osx] Error 2
[Automatically added by flyspray2trac: Operating System: OSX 10.3 Panther]
https://gitlab.torproject.org/tpo/core/tor/-/issues/1121
reason unexpected while uploading descriptor
2020-06-27T14:09:47Z
Trac
reason unexpected while uploading descriptor
Hi,
since i upgraded my relay to 0.2.2.5-alpha i am getting these warn message below.
Oct 12 13:15:10.985 [notice] Bootstrapped 90%: Establishing a Tor circuit.
Oct 12 13:15:18.207 [notice] Tor has successfully opened a circuit. Looks...
Hi,
since i upgraded my relay to 0.2.2.5-alpha i am getting these warn message below.
Oct 12 13:15:10.985 [notice] Bootstrapped 90%: Establishing a Tor circuit.
Oct 12 13:15:18.207 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Oct 12 13:15:18.207 [notice] Bootstrapped 100%: Done.
Oct 12 13:16:09.666 [warn] http status 404 ("Not Found") reason unexpected while uploading descriptor to server '194.109.206.212:80').
Oct 12 13:16:17.277 [notice] Self-testing indicates your DirPort is reachable from the outside. Excellent.
Oct 12 13:16:18.508 [notice] Performing bandwidth self-test...done.
Oct 12 13:17:10.924 [warn] http status 404 ("Not Found") reason unexpected while uploading descriptor to server '194.109.206.212:80').
Oct 12 13:23:16.169 [warn] http status 404 ("Not Found") reason unexpected while uploading descriptor to server '194.109.206.212:80').
Some kind of new bug?
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: dragonfly
Tor: 0.3.1.x-final
https://gitlab.torproject.org/tpo/core/tor/-/issues/1122
reachability and bandwidth tests are not carried over
2020-06-27T14:09:46Z
Trac
reachability and bandwidth tests are not carried over
hello, i run Kubuntu 9.10 x86 64 ,
commit 4b55ef26c93c5cadd866ca0be1e65547df7b6031 on branch origin/master 0.2.2.5 alpha
since last update, the tests of reachability and bandwidth are not carried over.. i think all tests are not exe...
hello, i run Kubuntu 9.10 x86 64 ,
commit 4b55ef26c93c5cadd866ca0be1e65547df7b6031 on branch origin/master 0.2.2.5 alpha
since last update, the tests of reachability and bandwidth are not carried over.. i think all tests are not executed for unknown reason .
i run as Bridge server
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: stars
https://gitlab.torproject.org/tpo/core/tor/-/issues/1124
Proxy error 504 connecting hidden serrvice
2020-06-27T14:09:46Z
Trac
Proxy error 504 connecting hidden serrvice
this url used to works OK
http://3xofiggysc6rgygv.onion:8181/
this is yacy hidden search engine, available for all tor users.
use: well , to seach for objectionable things , et all
However stopped working after I update tor software...
this url used to works OK
http://3xofiggysc6rgygv.onion:8181/
this is yacy hidden search engine, available for all tor users.
use: well , to seach for objectionable things , et all
However stopped working after I update tor software
the error is
[code]
504 Connect to 3xofiggysc6rgygv.onion:8181 failed: SOCKS error: host unreachable
The following error occurred while trying to access http://3xofiggysc6rgygv.onion:8181/:
504 Connect to 3xofiggysc6rgygv.onion:8181 failed: SOCKS error: host unreachable
Generated Fri, 16 Oct 2009 21:34:47 E. South America Standard Time by Polipo on localhost:8118.
[/code]
Thanks
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: crp
https://gitlab.torproject.org/tpo/core/tor/-/issues/1125
(*chp)->next assertion fail?
2020-06-27T14:09:46Z
Roger Dingledine
(*chp)->next assertion fail?
I found this on irc. So I have no idea if it's for real. The person indicated
it was on 0.2.2.5-alpha.
[Info] buf_shrink_freelists():
Cleaning freelist for 4096-byte chunks: keeping 9, dropping 1.
[Error] Bug: buffers.c:269: buf_shrink_...
I found this on irc. So I have no idea if it's for real. The person indicated
it was on 0.2.2.5-alpha.
[Info] buf_shrink_freelists():
Cleaning freelist for 4096-byte chunks: keeping 9, dropping 1.
[Error] Bug: buffers.c:269: buf_shrink_freelists: Assertion
(*chp)->next fail
He also said "polipo still not starting with vidalai 2.5", so I'm thinking
probably Windows.
[Automatically added by flyspray2trac: Operating System: All]
Tor: 0.2.2.x-final
Nick Mathewson
Nick Mathewson
https://gitlab.torproject.org/tpo/core/tor/-/issues/1126
Error from libevent setting read event state for 1023
2020-06-27T14:09:46Z
Trac
Error from libevent setting read event state for 1023
Hello,
This morning i have a error in my log:
oct. 18 11:23:48.810 [Warning] Error from libevent setting read event state for 1023 to watched: No such file or directory
oct. 18 11:23:58.355 [Warning] Couldn't open "/home/moonlights/Tor...
Hello,
This morning i have a error in my log:
oct. 18 11:23:48.810 [Warning] Error from libevent setting read event state for 1023 to watched: No such file or directory
oct. 18 11:23:58.355 [Warning] Couldn't open "/home/moonlights/TorTeamHelp/state.tmp" (/home/moonlights/TorTeamHelp/state) for writing: Too many open files
oct. 18 11:23:58.355 [Warning] Unable to write state to file "/home/moonlights/TorTeamHelp/state"
oct. 18 11:23:59.291 [Warning] Couldn't open "/home/moonlights/TorTeamHelp/state.tmp" (/home/moonlights/TorTeamHelp/state) for writing: Too many open files
oct. 18 11:23:59.291 [Warning] Unable to write state to file "/home/moonlights/TorTeamHelp/state"
oct. 18 11:24:01.577 [Warning] Couldn't open "/home/moonlights/TorTeamHelp/state.tmp" (/home/moonlights/TorTeamHelp/state) for writing: Too many open files
oct. 18 11:24:01.577 [Warning] Unable to write state to file "/home/moonlights/TorTeamHelp/state"
oct. 18 11:24:02.724 [Warning] Couldn't open "/home/moonlights/TorTeamHelp/state.tmp" (/home/moonlights/TorTeamHelp/state) for writing: Too many open files
oct. 18 11:24:02.725 [Warning] Unable to write state to file "/home/moonlights/TorTeamHelp/state"
oct. 18 11:24:04.593 [Warning] Couldn't open "/home/moonlights/TorTeamHelp/state.tmp" (/home/moonlights/TorTeamHelp/state) for writing: Too many open files
oct. 18 11:24:04.594 [Warning] Unable to write state to file "/home/moonlights/TorTeamHelp/state"
oct. 18 11:24:05.923 [Warning] Couldn't open "/home/moonlights/TorTeamHelp/state.tmp" (/home/moonlights/TorTeamHelp/state) for writing: Too many open files
oct. 18 11:24:05.923 [Warning] Unable to write state to file "/home/moonlights/TorTeamHelp/state"
i run Kubuntu KArmic 9.10 x86 64 on 64 bits 4 cores
Tor origin/master commit 5ef97ddd42dfd51fc296bb51b612780aec09c5c7
torrc spec: ports exit policy reject all */*
libevent + libevent extra 1.4.2 1.4.11-stable-1 (amd64)
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: stars
https://gitlab.torproject.org/tpo/core/tor/-/issues/1127
no shutdown descriptor published when ORPort is closed but client stays up
2020-06-27T14:09:46Z
Nick Mathewson
no shutdown descriptor published when ORPort is closed but client stays up
(Posted by request from Scott Bennett.)
Category: tor router -> tor client
Operating System: observed on FreeBSD 7.2-STABLE
Reported Version: 0.2.2.3-alpha ...
(Posted by request from Scott Bennett.)
Category: tor router -> tor client
Operating System: observed on FreeBSD 7.2-STABLE
Reported Version: 0.2.2.3-alpha
Title: no shutdown descriptor published when ORPort is closed but client stays up
Reported By: Scott Bennett
Description: When tor is running as both a router and a client, if a SIGINT
is sent to tor, tor closes the ORPort (and DirPort if applicable),
publishes a shutdown descriptor (i.e., a new descriptor in which the
"observed maximum 10s data rate in previous 24 hrs" is set to 0 to
discourage further attempts to include the node in new circuits), and
proceeds with the rest of the shutdown procedure. However, given the
same starting conditions, if the ORPort line in torrc is commented out
and a SIGHUP is sent to tor, tor will read the updated torrc, notice
that the ORPort is no longer to be used, close the ORPort (and DirPort
if applicable), and continue operation as a client process *without*
publishing a shutdown procedure. This situation results in many
unnecessary attempts by clients and routers to connect to the ORPort
(and DirPort if applicable) after it has been closed, wasting time and
causing avoidable circuit construction failures. This was observed in
tor 0.2.2.3-alpha. I haven't yet tried it in 0.2.2.5-alpha.
[Automatically added by flyspray2trac: Operating System: BSD]
Tor: unspecified
https://gitlab.torproject.org/tpo/core/tor/-/issues/1136
When Tor is offline, it doesn't quite run out of relays, so doesn't realize i...
2020-06-27T14:09:46Z
Roger Dingledine
When Tor is offline, it doesn't quite run out of relays, so doesn't realize it's offline
If your Tor client goes offline, it will keep trying to establish circuits,
and as each TLS connection fails, it will mark that relay down.
In update_router_have_minimum_dir_info() Tor checks whether (num_present < 2)
but we never actua...
If your Tor client goes offline, it will keep trying to establish circuits,
and as each TLS connection fails, it will mark that relay down.
In update_router_have_minimum_dir_info() Tor checks whether (num_present < 2)
but we never actually mark down the last few relays, either because we don't
have enough left to make a circuit so we don't ever try another TLS connection,
or because none of the remaining relays are suitable exit nodes so we can't
pick a path that would be a useful circuit so we don't try.
I think we need to catch the case where we failed to pick a path because we
don't have enough circuits, and if it case occurs and many of our relays are
marked down, we should mark them up.
That will cause us to attempt circuits for a lot longer than currently, but on
the other hand Tor will actually work when you come back to the network and
try to make a new application request.
[Automatically added by flyspray2trac: Operating System: All]
Tor: unspecified
https://gitlab.torproject.org/tpo/core/tor/-/issues/1137
Mac OS X Tor crash
2020-06-27T14:09:46Z
cypherpunks
Mac OS X Tor crash
I'm running Vidalia 0.2.4 with Tor 0.2.2.3-alpha (git-0f3417d1dbffdf7a). It appears that Mr. Mike Perry has caused some bugs with his circuit build time "improvements" in Tor. :-)
Here's the crash log:
Process: tor [204]
Path: ...
I'm running Vidalia 0.2.4 with Tor 0.2.2.3-alpha (git-0f3417d1dbffdf7a). It appears that Mr. Mike Perry has caused some bugs with his circuit build time "improvements" in Tor. :-)
Here's the crash log:
Process: tor [204]
Path: /Applications/Vidalia.app/Contents/MacOS/tor
Identifier: tor
Version: ??? (???)
Code Type: X86 (Native)
Parent Process: Vidalia [188]
Interval Since Last Report: 2883864 sec
Crashes Since Last Report: 2
Per-App Interval Since Last Report: 0 sec
Per-App Crashes Since Last Report: 2
Date/Time: 2009-10-25 21:40:30.778 -0700
OS Version: Mac OS X 10.5.8 (9L31a)
Report Version: 6
Anonymous UUID: 40FE94CF-131D-4773-90D7-DCB7EFF18865
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Crashed Thread: 0
Thread 0 Crashed:
0 libSystem.B.dylib 0x91a70e42 __kill + 10
1 libSystem.B.dylib 0x91ae323a raise + 26
2 libSystem.B.dylib 0x91aef679 abort + 73
3 tor 0x0000db0e circuit_build_times_parse_state + 958
4 tor 0x0002131a or_state_load + 602
5 tor 0x00022435 options_act + 3285
6 tor 0x0002267d set_options + 365
7 tor 0x000263c7 options_init_from_string + 567
8 tor 0x000267f6 options_init_from_torrc + 694
9 tor 0x0006f453 tor_init + 259
10 tor 0x000735d3 tor_main + 67
11 tor 0x00001ee2 _start + 216
12 tor 0x00001e09 start + 41
Thread 0 crashed with X86 Thread State (32-bit):
eax: 0x00000000 ebx: 0x91aef639 ecx: 0xbfffeffc edx: 0x91a70e42
edi: 0x000e5e80 esi: 0x000e5fd8 ebp: 0xbffff018 esp: 0xbfffeffc
ss: 0x0000001f efl: 0x00000286 eip: 0x91a70e42 cs: 0x00000007
ds: 0x0000001f es: 0x0000001f fs: 0x00000000 gs: 0x00000037
cr2: 0xa02e1690
Binary Images:
0x1000 - 0x11bfef +tor ??? (???) <d67657b9b5e05c547bfeb1ac91c0ad69> /Applications/Vidalia.app/Contents/MacOS/tor
0x8fe00000 - 0x8fe2db43 dyld 97.1 (???) <458eed38a009e5658a79579e7bc26603> /usr/lib/dyld
0x90676000 - 0x9067dfe9 libgcc_s.1.dylib ??? (???) <f53c808e87d1184c0f9df63aef53ce0b> /usr/lib/libgcc_s.1.dylib
0x91a02000 - 0x91b69ff3 libSystem.B.dylib ??? (???) <ae47ca9b1686b065f8ac4d2de09cc432> /usr/lib/libSystem.B.dylib
0x940b2000 - 0x94164ffb libcrypto.0.9.7.dylib ??? (???) <9d714c92872a93dd127ea8556b2c8945> /usr/lib/libcrypto.0.9.7.dylib
0x94cd6000 - 0x94cfafeb libssl.0.9.7.dylib ??? (???) <8084593b773bec8f2b9614fd23c5ed73> /usr/lib/libssl.0.9.7.dylib
0x9529e000 - 0x952acffd libz.1.dylib ??? (???) <5ddd8539ae2ebfd8e7cc1c57525385c7> /usr/lib/libz.1.dylib
0x9608c000 - 0x96090fff libmathCommon.A.dylib ??? (???) /usr/lib/system/libmathCommon.A.dylib
0xffff0000 - 0xffff1780 libSystem.B.dylib ??? (???) /usr/lib/libSystem.B.dylib
Here's my system info:
Model: Macmini2,1, BootROM MM21.009A.B00, 2 processors, Intel Core 2 Duo, 2 GHz, 1 GB
Graphics: kHW_IntelGMA950Item, GMA 950, spdisplays_builtin, spdisplays_integrated_vram
Memory Module: global_name
AirPort: spairport_wireless_card_type_airport_extreme (0x168C, 0x86), 1.4.16.2
Bluetooth: Version 2.1.8f2, 2 service, 1 devices, 1 incoming serial ports
Network Service: Ethernet, Ethernet, en0
Serial ATA Device: Hitachi HTS541612J9SA00, 111.79 GB
Parallel ATA Device: PIONEER DVD-RW DVR-K06
USB Device: My Book, (null) mA
USB Device: Extreme III USB2.0 Reader/Writer, (null) mA
USB Device: Back-UPS ES 550 FW:840.B2.D USB FW:B2, (null) mA
USB Device: Apple Optical USB Mouse, (null) mA
USB Device: Bluetooth USB Host Controller, (null) mA
USB Device: IR Receiver, (null) mA
Tor crashes every time that I attempt to start it with Vidalia:
Oct 25 21:46:26.909 [Notice] Tor v0.2.2.3-alpha (git-0f3417d1dbffdf7a). This is experimental software. Do not rely on it for strong anonymity. (Running on Darwin i386)
Oct 25 21:46:26.910 [Notice] Initialized libevent version 1.4.12-stable using method kqueue. Good.
Oct 25 21:46:26.910 [Notice] Opening OR listener on 0.0.0.0:9001
Oct 25 21:46:26.910 [Notice] Opening Directory listener on 0.0.0.0:9030
Oct 25 21:46:26.911 [Notice] Opening Socks listener on 127.0.0.1:9050
Oct 25 21:46:26.911 [Notice] Opening Control listener on 127.0.0.1:9051
Oct 25 21:46:26.912 [Error] Bug: circuitbuild.c:380: circuit_build_times_shuffle_array: Assertion cbt->total_build_times == cbt->build_times_idx failed; aborting.
If I remove the state file from my ~/.tor/ directory, I am able to start Tor as expected. I do however expect it to crash or have this problem again at some point. I sadly unlinked the state file or I would have included it in this bug report.
[Automatically added by flyspray2trac: Operating System: OSX 10.5 Leopard]
https://gitlab.torproject.org/tpo/core/tor/-/issues/1138
If bridge authority is unreachable, client doesn't fallback to bridge
2020-06-27T14:09:45Z
Roger Dingledine
If bridge authority is unreachable, client doesn't fallback to bridge
When a Tor client starts up using a bridge, and UpdateBridgesFromAuthority is
set (which it is when Vidalia configures you to use a bridge), Tor will go to
the authority first and look up the bridge by fingerprint.
If the bridge authori...
When a Tor client starts up using a bridge, and UpdateBridgesFromAuthority is
set (which it is when Vidalia configures you to use a bridge), Tor will go to
the authority first and look up the bridge by fingerprint.
If the bridge authority doesn't have the bridge, or Tor doesn't know the
fingerprint, then Tor will fall back to asking the bridge directly.
If the bridge authority is filtered, though, then Tor will never notice that
the bridge authority lookup failed. So it will never fall back. Fail.
Our workaround for now is to stop giving out fingerprints via bridgedb.
[Automatically added by flyspray2trac: Operating System: All]
Tor: 0.2.2.x-final
Robert Hogan
Robert Hogan
https://gitlab.torproject.org/tpo/core/tor/-/issues/1139
alpha gcc bug: circuitbuild.c:608: circuit_build_times_generate_sample: Asser...
2020-06-27T14:09:45Z
weasel (Peter Palfrader)
alpha gcc bug: circuitbuild.c:608: circuit_build_times_generate_sample: Assertion q_lo < q_hi failed
Hi,
on alpha, in 0.2.2.4 and latest git the testsuite fails with:
[sid] weasel@albeniz:~/tmp/tor$ ./src/test/test --info
Oct 26 09:07:09.931 [info] crypto_global_init(): NOT using OpenSSL engine support.
Oct 26 09:07:09.932 [info] crypt...
Hi,
on alpha, in 0.2.2.4 and latest git the testsuite fails with:
[sid] weasel@albeniz:~/tmp/tor$ ./src/test/test --info
Oct 26 09:07:09.931 [info] crypto_global_init(): NOT using OpenSSL engine support.
Oct 26 09:07:09.932 [info] crypto_seed_rng(): Seeding RNG from "/dev/urandom"
Oct 26 09:07:09.934 [info] crypto_seed_rng(): Seeding RNG from "/dev/urandom"
buffers: OK
onion_handshake: OK
circuit_timeout: Oct 26 09:07:10.206 [err] Bug: circuitbuild.c:608: circuit_build_times_generate_sample: Assertion q_lo < q_hi failed; aborting.
circuitbuild.c:608 circuit_build_times_generate_sample: Assertion q_lo < q_hi failed; aborting.
zsh: abort (core dumped) ./src/test/test --info
See also http://experimental.ftbfs.de/fetch.php?pkg=tor&arch=alpha&ver=0.2.2.4-alpha-1&stamp=1255305733&file=log&as=raw
[Automatically added by flyspray2trac: Operating System: All]
Nick Mathewson
Nick Mathewson
https://gitlab.torproject.org/tpo/core/tor/-/issues/1141
bug in networkstatus.c using 0.2.1.20
2020-06-27T14:09:45Z
Trac
bug in networkstatus.c using 0.2.1.20
Here is the config from the Tor client where the crash is happening:
TestingTorNetwork 1
DirServer bridgedirauth v3ident=3C1DA30FB6C8760E43C89ED36A700F429C5763E5 orport=443 172.16.234.136:995 B8F4F6B623E787C47A70111E7E5DE4A53A7A1840
Dat...
Here is the config from the Tor client where the crash is happening:
TestingTorNetwork 1
DirServer bridgedirauth v3ident=3C1DA30FB6C8760E43C89ED36A700F429C5763E5 orport=443 172.16.234.136:995 B8F4F6B623E787C47A70111E7E5DE4A53A7A1840
DataDirectory /root/.tor/
UseBridges 1
Bridge 172.16.234.136:443
ClientOnly 1
Here is the output from Tor when the bug happens:
(gdb) run -f torrc log info
Starting program: /root/tor-0.2.1.20/src/or/tor -f torrc log info
Oct 31 19:18:12.716 [notice] Tor v0.2.1.20. This is experimental software. Do not rely on it for strong anonymity. (Running on OpenBSD amd64)
Oct 31 19:18:12.720 [warn] You have used DirServer or AlternateDirAuthority to specify alternate directory authorities in your configuration. This is potentially dangerous: it can make you look different from all other Tor users, and hurt your anonymity. Even if you've specified the same authorities as Tor uses by default, the defaults could change in the future. Be sure you know what you're doing.
Oct 31 19:18:12.720 [warn] TestingTorNetwork is set. This will make your node almost unusable in the public Tor network, and is therefore only advised if you are building a testing Tor network!
Oct 31 19:18:12.721 [notice] Initialized libevent version 1.3e using method kqueue. Good.
Oct 31 19:18:12.721 [notice] Opening Socks listener on 127.0.0.1:9050
Oct 31 19:18:12.723 [info] tor_lockfile_lock(): Locking "/root/.tor//lock"
Oct 31 19:18:12.723 [info] or_state_load(): Loaded state from "/root/.tor//state"
Oct 31 19:18:12.724 [info] read_file_to_str(): Could not open "/root/.tor//router-stability": No such file or directory
Oct 31 19:18:12.725 [info] geoip_load_file(): Failed to open GEOIP file /usr/local/share/tor/geoip.
Oct 31 19:18:12.725 [warn] You are running Tor as root. You don't need to, and you probably shouldn't.
Oct 31 19:18:12.744 [info] crypto_seed_rng(): Seeding RNG from "/dev/srandom"
Oct 31 19:18:12.798 [info] Bootstrapped 0%: Starting.
Oct 31 19:18:12.800 [info] trusted_dirs_load_certs_from_string(): Adding cached certificate for directory authority bridgedirauth with signing key F554586AA4C6DFB571A33EEBA89D9D48A94B618B
Oct 31 19:18:12.800 [info] read_file_to_str(): Could not open "/root/.tor//cached-consensus": No such file or directory
Oct 31 19:18:12.800 [info] read_file_to_str(): Could not open "/root/.tor//unverified-consensus": No such file or directory
Oct 31 19:18:12.800 [info] read_file_to_str(): Could not open "/usr/local/share/tor/fallback-consensus": No such file or directory
Oct 31 19:18:12.801 [info] should_delay_dir_fetches(): delaying dir fetches (no running bridges known)
Oct 31 19:18:12.801 [info] router_load_routers_from_string(): 1 elements to add
Oct 31 19:18:12.801 [info] add_an_entry_guard(): Chose 'bridgedirauth' as new entry guard.
Oct 31 19:18:12.802 [info] log_entry_guards(): bridgedirauth (down never-contacted)
Oct 31 19:18:12.802 [notice] new bridge descriptor 'bridgedirauth' (cached)
Oct 31 19:18:12.802 [info] update_consensus_networkstatus_downloads(): Launching networkstatus consensus download.
Oct 31 19:18:12.802 [info] connection_ap_make_link(): Making internal direct tunnel to [scrubbed]:443 ...
Oct 31 19:18:12.803 [info] onion_pick_cpath_exit(): Using requested exit node 'bridgedirauth'
Oct 31 19:18:12.803 [info] circuit_handle_first_hop(): Next router is [scrubbed]: Router not connected (nothing is). Connecting.
Oct 31 19:18:12.803 [notice] Bootstrapped 5%: Connecting to directory server.
Oct 31 19:18:12.803 [info] get_interface_address6(): connect() failed: Invalid argument
Oct 31 19:18:12.804 [info] get_interface_address6(): connect() failed: Invalid argument
Oct 31 19:18:12.804 [info] connection_ap_make_link(): ... application connection created and linked.
Oct 31 19:18:12.804 [info] directory_send_command(): Downloading consensus from 172.16.234.136:443 using /tor/status-vote/current/consensus.z
Oct 31 19:18:12.805 [info] router_load_routers_from_string(): 0 elements to add
Oct 31 19:18:12.805 [info] tor_mmap_file(): Could not open "/root/.tor//cached-extrainfo" for mmap(): No such file or directory
Oct 31 19:18:12.805 [notice] I learned some more directory information, but not enough to build a circuit: We have no network-status consensus.
Oct 31 19:18:12.806 [info] connection_ap_make_link(): Making internal direct tunnel to [scrubbed]:443 ...
Oct 31 19:18:12.806 [info] onion_pick_cpath_exit(): Using requested exit node '0000000000000000000000000000000000000000'
Oct 31 19:18:12.806 [info] circuit_handle_first_hop(): Next router is [scrubbed]: Not connected. Connecting.
Oct 31 19:18:12.806 [info] get_interface_address6(): connect() failed: Invalid argument
Oct 31 19:18:12.807 [info] get_interface_address6(): connect() failed: Invalid argument
Oct 31 19:18:12.807 [info] connection_ap_make_link(): ... application connection created and linked.
Oct 31 19:18:12.809 [info] or_state_save(): Saved state to "/root/.tor//state"
Oct 31 19:18:12.809 [info] connection_edge_process_inbuf(): data from edge while in 'waiting for circuit' state. Leaving it on buffer.
Oct 31 19:18:12.810 [info] connection_edge_process_inbuf(): data from edge while in 'waiting for circuit' state. Leaving it on buffer.
Oct 31 19:18:12.810 [info] connection_edge_process_inbuf(): data from edge while in 'waiting for circuit' state. Leaving it on buffer.
Oct 31 19:18:12.810 [info] connection_edge_process_inbuf(): data from edge while in 'waiting for circuit' state. Leaving it on buffer.
Oct 31 19:18:12.810 [notice] Bootstrapped 10%: Finishing handshake with directory server.
Oct 31 19:18:12.866 [info] connection_or_check_valid_tls_handshake(): Connected to router $B8F4F6B623E787C47A70111E7E5DE4A53A7A1840 at 172.16.234.136:443 without knowing its key. Hoping for the best.
Oct 31 19:18:12.867 [info] command_process_versions_cell(): Negotiated version 2 with [scrubbed]:443; sending NETINFO.
Oct 31 19:18:12.868 [notice] Bootstrapped 15%: Establishing an encrypted directory connection.
Oct 31 19:18:12.868 [info] circuit_send_next_onion_skin(): First hop: finished sending CREATE_FAST cell to 'bridgedirauth'
Oct 31 19:18:12.868 [info] circuit_send_next_onion_skin(): First hop: finished sending CREATE_FAST cell to 'bridgedirauth'
Oct 31 19:18:12.868 [info] command_process_netinfo_cell(): Got good NETINFO cell from [scrubbed]:443; OR connection is now open, using protocol version 2
Oct 31 19:18:12.869 [info] command_process_versions_cell(): Negotiated version 2 with [scrubbed]:443; sending NETINFO.
Oct 31 19:18:12.869 [info] command_process_netinfo_cell(): Got good NETINFO cell from [scrubbed]:443; OR connection is now open, using protocol version 2
Oct 31 19:18:12.910 [info] circuit_finish_handshake(): Finished building fast circuit hop:
Oct 31 19:18:12.910 [info] exit circ (length 1, exit bridgedirauth): $B8F4F6B623E787C47A70111E7E5DE4A53A7A1840(open)
Oct 31 19:18:12.910 [info] circuit_send_next_onion_skin(): circuit built!
Oct 31 19:18:12.910 [notice] Bootstrapped 20%: Asking for networkstatus consensus.
Oct 31 19:18:12.910 [info] exit circ (length 1): $B8F4F6B623E787C47A70111E7E5DE4A53A7A1840(open)
Oct 31 19:18:12.911 [info] connection_ap_handshake_send_begin(): Address/port sent, ap socket -1, n_circ_id 23920
Oct 31 19:18:12.911 [info] circuit_finish_handshake(): Finished building fast circuit hop:
Oct 31 19:18:12.911 [info] exit circ (length 1, exit 0000000000000000000000000000000000000000): $0000000000000000000000000000000000000000(open)
Oct 31 19:18:12.912 [info] circuit_send_next_onion_skin(): circuit built!
Oct 31 19:18:12.912 [info] exit circ (length 1): $0000000000000000000000000000000000000000(open)
Oct 31 19:18:12.912 [info] connection_ap_handshake_send_begin(): Address/port sent, ap socket -1, n_circ_id 23921
Oct 31 19:18:12.913 [info] connection_edge_process_relay_cell_not_open(): 'connected' received after 0 seconds.
Oct 31 19:18:12.914 [info] exit circ (length 1): $B8F4F6B623E787C47A70111E7E5DE4A53A7A1840(open)
Oct 31 19:18:12.914 [notice] Bootstrapped 25%: Loading networkstatus consensus.
Oct 31 19:18:12.915 [info] connection_edge_process_relay_cell_not_open(): 'connected' received after 0 seconds.
Oct 31 19:18:12.915 [info] exit circ (length 1): $0000000000000000000000000000000000000000(open)
Oct 31 19:18:12.915 [notice] Bootstrapped 50%: Loading relay descriptors.
Oct 31 19:18:12.916 [info] connection_edge_process_relay_cell(): -1: end cell (closed normally) for stream 44628. Removing stream.
Oct 31 19:18:12.917 [info] _connection_free(): Freeing linked Socks connection [open] with 0 bytes on inbuf, 0 on outbuf.
Oct 31 19:18:12.918 [info] connection_dir_client_reached_eof(): Received consensus directory (size 1367) from server '172.16.234.136:443'
Oct 31 19:18:12.918 [info] 0 unknown, 0 missing key, 1 good, 0 bad, 0 no signature, 1 required
Oct 31 19:18:12.919 [err] Bug: networkstatus.c:1164: update_consensus_networkstatus_fetch_time: Assertion start+dl_interval < c->valid_until failed; aborting.
networkstatus.c:1164 update_consensus_networkstatus_fetch_time: Assertion start+dl_interval < c->valid_until failed; aborting.
Here is the backtrace from this crashed process:
(gdb) backtrace
#0 0x000000020c37137a in kill () from /usr/lib/libc.so.51.0
#1 0x000000020c3bd765 in abort () at /usr/src/lib/libc/stdlib/abort.c:68
legacy/trac#2 0x000000000045cb81 in update_consensus_networkstatus_fetch_time (now=1257016692) at networkstatus.c:1183
legacy/trac#3 0x000000000045d29d in networkstatus_set_current_consensus (
consensus=0x20f769800 "network-status-version 3\nvote-status consensus\nconsensus-method 5\nvalid-after 2009-10-31 19:15:00\nfresh-until 2009-10-31 19:20:00\nvalid-until 2009-10-31 19:30:00\nvoting-delay 20 20\nclient-versions \nse"..., flags=0) at networkstatus.c:1527
legacy/trac#4 0x000000000043feac in connection_dir_client_reached_eof (conn=0x2088f0d00) at directory.c:1638
legacy/trac#5 0x000000000044061e in connection_dir_reached_eof (conn=0x2088f0d00) at directory.c:2040
legacy/trac#6 0x000000000042626f in connection_handle_read (conn=0x2088f0d00) at connection.c:2037
legacy/trac#7 0x0000000000457b91 in conn_read_callback (fd=8833, event=6, _conn=0x37b7) at main.c:456
legacy/trac#8 0x000000020377f2e2 in event_process_active (base=0x201cfdc00) at /usr/src/lib/libevent/event.c:333
legacy/trac#9 0x000000020377f501 in event_base_loop (base=0x201cfdc00, flags=1) at /usr/src/lib/libevent/event.c:450
legacy/trac#10 0x000000020377f3b5 in event_loop (flags=8833) at /usr/src/lib/libevent/event.c:383
legacy/trac#11 0x0000000000459726 in do_main_loop () at main.c:1444
legacy/trac#12 0x000000000045a88b in tor_main (argc=5, argv=0x7f7fffff1850) at main.c:2070
legacy/trac#13 0x000000000040702c in ___start ()
legacy/trac#14 0x0000000000000005 in ?? ()
legacy/trac#15 0x00007f7fffff1d00 in ?? ()
legacy/trac#16 0x00007f7fffff1d1e in ?? ()
legacy/trac#17 0x00007f7fffff1d21 in ?? ()
legacy/trac#18 0x00007f7fffff1d27 in ?? ()
legacy/trac#19 0x00007f7fffff1d2b in ?? ()
legacy/trac#20 0x0000000000000000 in ?? ()
The configs used for the servers in this network can be found here: http://pastebin.com/m65b5da00
I'd also be keen to hear if the configs I have for such a network actually make sense, and that I haven't forgotten something crucial when testing Tor.
Thanks
mikeb
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: mikeb
Tor: 0.2.2.x-final
https://gitlab.torproject.org/tpo/core/tor/-/issues/1143
Tor can't start if DNS Port enabled in torrc
2020-06-27T14:09:45Z
Trac
Tor can't start if DNS Port enabled in torrc
Hello,
Today i updated my tor origin/master 0.2.2.5 alpha commit 69c0147ea6725a63f254333867c0504528c62daf and i was unable to start tor.
I run kubuntu karmic 9.10 on x86 64, kernel: 2.6.31-15-generic and libevent 2.0.2 alpha Path: .
U...
Hello,
Today i updated my tor origin/master 0.2.2.5 alpha commit 69c0147ea6725a63f254333867c0504528c62daf and i was unable to start tor.
I run kubuntu karmic 9.10 on x86 64, kernel: 2.6.31-15-generic and libevent 2.0.2 alpha Path: .
URL: https://levent.svn.sourceforge.net/svnroot/levent/trunk/libevent
Repository Root: https://levent.svn.sourceforge.net/svnroot/levent
Repository UUID: ce677c24-8c1a-0410-9497-a30ef3a96221
Revision: 1516
Node Kind: directory
Schedule: normal
Last Changed Author: nickm
Last Changed Rev: 1516
Last Changed Date: 2009-11-06 22:46:57 +0100 (ven, 06 nov 2009)
After a few hours , i have found that was the "DNSPort xx DNS , ListenAddress 127.0.0.1:xxxx " when enabled who crash tor at start.
If i disable it, it start normally .
i have already report in libevent bug tracker the 2 kernel errors found in my log but give info here while i dunno what cause it.
2009-11-08 21:40:22 moon kernel [ 6907.854009] tor[11345]: segfault at 0 ip 00007f39cf943b18 sp 00007fff6dd87860 error 4 in libevent.so.2.0.0[7f39cf929000+40000]
2009-11-08 21:41:10 moon kernel [ 6955.458940] tor[11355]: segfault at 0 ip 00007f8ae258bb18 sp 00007fff58df22a0 error 4 in libevent.so.2.0.0[7f8ae2571000+40000]
best regards
SwissTorExit
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: stars
https://gitlab.torproject.org/tpo/core/tor/-/issues/1144
tor bridge can not work with openssl 0.9.8l
2020-06-27T14:09:45Z
Trac
tor bridge can not work with openssl 0.9.8l
Description:
After upgrade to openssl-0.9.8l which fixed the MTM attack (for reference see https://bugzilla.redhat.com/show_bug.cgi?id=533125) by disabling renegotiating, tor(using bridge) stops working.
Tor should find another way with...
Description:
After upgrade to openssl-0.9.8l which fixed the MTM attack (for reference see https://bugzilla.redhat.com/show_bug.cgi?id=533125) by disabling renegotiating, tor(using bridge) stops working.
Tor should find another way without renegotiating. For linux distributions, enabling a known insecure feature is not an option.
Tor log:
Nov 10 14:31:15 cruiser Tor[9287]: Bootstrapped 5%: Connecting to directory server.
Nov 10 14:31:15 cruiser Tor[9287]: Bootstrapped 10%: Finishing handshake with directory server.
Nov 10 14:31:16 cruiser Tor[9287]: TLS error: unexpected close while renegotiating
Nov 10 14:31:16 cruiser Tor[9287]: TLS error: unexpected close while renegotiating
Nov 10 14:31:16 cruiser Tor[9287]: TLS error: unexpected close while renegotiating
Nov 10 14:31:16 cruiser Tor[9287]: TLS error: unexpected close while renegotiating
Nov 10 14:31:16 cruiser Tor[9287]: TLS error: unexpected close while renegotiating
Nov 10 14:31:16 cruiser Tor[9287]: TLS error: unexpected close while renegotiating
Nov 10 14:31:16 cruiser Tor[9287]: TLS error: unexpected close while renegotiating
Nov 10 14:31:16 cruiser Tor[9287]: Problem bootstrapping. Stuck at 10%: Finishing handshake with directory server. (DONE; DONE; count 7; recommendation warn)
reference:
http://bugs.archlinux.org/task/17088
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: lyman
https://gitlab.torproject.org/tpo/core/tor/-/issues/1145
Tor fails to load auth-certs
2020-06-27T14:09:45Z
Trac
Tor fails to load auth-certs
Used the Tor Browser Bundle 1.2.9 under Windows 7 x64 German.
Worked smoothly, but today it was unable to build a circuit. Log and the Tor-Data is attached.
[Automatically added by flyspray2trac: Operating System: Windows Vista]
**Tra...
Used the Tor Browser Bundle 1.2.9 under Windows 7 x64 German.
Worked smoothly, but today it was unable to build a circuit. Log and the Tor-Data is attached.
[Automatically added by flyspray2trac: Operating System: Windows Vista]
**Trac**:
**Username**: knappo
Tor: 0.2.2.x-final
https://gitlab.torproject.org/tpo/core/tor/-/issues/1147
mlockall prevents compile for Android
2020-06-27T14:09:45Z
Jacob Appelbaum
mlockall prevents compile for Android
bionic doesn't have an actual implementation of mlockall();
mlockall() is merely in the headers but not actually in the library.
This prevents Tor compilation with the bionic libc for Android handsets.
[Automatically added by flyspray2t...
bionic doesn't have an actual implementation of mlockall();
mlockall() is merely in the headers but not actually in the library.
This prevents Tor compilation with the bionic libc for Android handsets.
[Automatically added by flyspray2trac: Operating System: All]
Jacob Appelbaum
Jacob Appelbaum
https://gitlab.torproject.org/tpo/core/tor/-/issues/1148
mlockall prevents compile for Android
2020-06-27T14:09:45Z
Jacob Appelbaum
mlockall prevents compile for Android
bionic doesn't have an actual implementation of mlockall(); mlockall() is merely in the headers but not actually in the library. This prevents Tor compilation with the bionic libc for Android handsets.
[Automatically added by flyspray2t...
bionic doesn't have an actual implementation of mlockall(); mlockall() is merely in the headers but not actually in the library. This prevents Tor compilation with the bionic libc for Android handsets.
[Automatically added by flyspray2trac: Operating System: All]
Jacob Appelbaum
Jacob Appelbaum