Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:03:43Zhttps://gitlab.torproject.org/legacy/trac/-/issues/1241routerlists read from torrc not concatenated2020-06-13T14:03:43ZTracrouterlists read from torrc not concatenated[ If a list of nodes is specified in the torrc like this:
ExcludeNodes $7360815c9f8471ba6a9335d00c1c1ef4e9c1162d
ExcludeNodes $73ecf797130872f13ccd2cc051bd98ba68a8c781
ExcludeNodes $2b560cda2b2faf392bec929aae7215f4e8c08af8
...[ If a list of nodes is specified in the torrc like this:
ExcludeNodes $7360815c9f8471ba6a9335d00c1c1ef4e9c1162d
ExcludeNodes $73ecf797130872f13ccd2cc051bd98ba68a8c781
ExcludeNodes $2b560cda2b2faf392bec929aae7215f4e8c08af8
ExcludeNodes $437492a449c407425b58ef530f4461d9ed9b28fa
only the last entry ends up in the final rotuerlist. It would be desirable
if subsequent lines were concatenated into the final list. ]
[ I've never been one for treating comments as 'authoritative', but... the
comment preceeding src\or\config.c:config_assign indicates several
behaviors, in particular this one occurs when ((use_defaults == 0) &&
(clear_first == 0)). ]
* Here are the use cases:
* 1. A non-empty AllowInvalid line in your torrc. Appends to current
* if linelist, replaces current if csv.
* 2. An empty AllowInvalid line in your torrc. Should clear it.
* 3. "RESETCONF AllowInvalid" sets it to default.
* 4. "SETCONF AllowInvalid" makes it NULL.
* 5. "SETCONF AllowInvalid=foo" clears it and sets it to "foo".
*
* Use_defaults Clear_first
* 0 0 "append"
* 1 0 undefined, don't use
* 0 1 "set to null first"
* 1 1 "set to defaults first"
* Return 0 on success, -1 on bad key, -2 on bad value.
src\or\config.c:config_assign_value:
case CONFIG_TYPE_ROUTERSET:
[ If there is already a routerset, delete it, and create a new, empty one to
fill in: ]
if (*(routerset_t**)lvalue) {
routerset_free(*(routerset_t**)lvalue);
}
*(routerset_t**)lvalue = routerset_new();
if (routerset_parse(*(routerset_t**)lvalue, c->value, c->key)<0) {
tor_snprintf(buf, sizeof(buf), "Invalid exit list '%s' for option '%s'",
c->value, c->key);
*msg = tor_strdup(buf);
return -1;
}
break;
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: aakovaTor: 0.2.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/1240stop calling getsockname if accept returns a bad address2020-06-13T14:03:43ZSebastian Hahnstop calling getsockname if accept returns a bad addressr1eo| can anyone explain: 1) why connection_handle_listener_read() goes far
if getsockname() failed and do not return after such. 2) why
getsockname() called at all, what purpose for retrieve local addr and
put...r1eo| can anyone explain: 1) why connection_handle_listener_read() goes far
if getsockname() failed and do not return after such. 2) why
getsockname() called at all, what purpose for retrieve local addr and
put it as remote? at least fail of check_sockaddr() can be triggered
remotely in theory.
r1eo| http://archives.seul.org/or/cvs/Apr-2005/msg00100.html it's
introduced getsockname(). but I have the same questions still. And one:
if accept() failed to return correct peer-address, then getpeername()
failing too? http://archives.neohapsis.com/archives/bind/2001/0025.html
http://www.mail-archive.com/freebsd-net@freebsd.org/msg00901.html
funny, but such accepted conn with zero addr is broken anyway. so if tor
filled it with self addr bug him. wonder if it exploitable for spoofing log
at least.
r1eo| someone nmap'ed moria in 2005.
r1eo| just for clear: nothing stops sending created cell and other for today even
if addr faked.
r1eo| http://archives.seul.org/or/cvs/Apr-2005/msg00100.html "This just
happened on moria2"
r1eo| http://paste.debian.net/58458/plain/58458 prevent fooling themself.
socket returned by accept() with zero addr, as result of scan and timing
issues in some kernels. such conn is broken.
[Automatically added by flyspray2trac: Operating System: All]Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/1232Bridge crash2020-06-13T14:03:39ZWendy SeltzerBridge crashBridge crashed after a few days, running Tor 0.2.2.7-alpha (git-c939509051f90d72)
from the log:
Jan 22 12:25:02.350 [err] routerlist_assert_ok(): Bug: routerlist.c:4699: router
list_assert_ok: Assertion r == r2 failed; aborting.
(gdb) ...Bridge crashed after a few days, running Tor 0.2.2.7-alpha (git-c939509051f90d72)
from the log:
Jan 22 12:25:02.350 [err] routerlist_assert_ok(): Bug: routerlist.c:4699: router
list_assert_ok: Assertion r == r2 failed; aborting.
(gdb) bt
#0 0x006af422 in __kernel_vsyscall ()
#1 0x0090a4d1 in raise () from /lib/tls/i686/cmov/libc.so.6
#2 0x0090d932 in abort () from /lib/tls/i686/cmov/libc.so.6
#3 0x0807d48e in routerlist_assert_ok (rl=<value optimized out>)
at routerlist.c:4727
#4 0x08083cc0 in router_load_routers_from_string (s=0x9bae98d "", eos=0x0,
saved_location=SAVED_NOWHERE, requested_fingerprints=0x8f32590,
descriptor_digests=1,
prepend_annotations=0xbfa9aeec "@downloaded-at 2010-01-22 19:25:02\n@source \"80.251.122.132\"\n") at routerlist.c:3460
#5 0x080dd7f9 in connection_dir_client_reached_eof (
conn=<value optimized out>) at directory.c:1623
#6 0x080de50e in connection_dir_client_reached_eof (conn=0x8d19360)
at directory.c:1894
#7 0x080c048d in fprintf (conn=0x8d19360) at /usr/include/bits/stdio2.h:98
#8 TO_OR_CONN (conn=0x8d19360) at or.h:1248
#9 connection_read_to_buf (conn=0x8d19360) at connection.c:2446
#10 connection_handle_read_impl (conn=0x8d19360) at connection.c:2339
#11 connection_handle_read (conn=0x8d19360) at connection.c:2407
#12 0x08051134 in conn_write_callback (fd=63, events=2, _conn=0x8d19360)
at main.c:523
#13 0x00776248 in event_base_loop () from /usr/lib/libevent-1.4.so.2
#14 0x080527c1 in do_main_loop () at main.c:1506
#15 0x08052a3d in tor_main (argc=1, argv=0xbfa9b2e4) at main.c:2130
#16 0x0804db7b in frame_dummy () from /usr/local/bin/tor
#17 0x008f6b56 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#18 0x0804dac1 in geteuid@plt () from /usr/local/bin/tor
[Automatically added by flyspray2trac: Operating System: All]Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/1222Tor falsely believing to be offline2020-06-13T14:03:27ZTracTor falsely believing to be offlineActually, don't know if it's a bug in the server or client, or both. Running Tor server on Win 2k,
low bandwidth & severely port limited but still technically an exit; not using the client much, I still
will let the server run unattende...Actually, don't know if it's a bug in the server or client, or both. Running Tor server on Win 2k,
low bandwidth & severely port limited but still technically an exit; not using the client much, I still
will let the server run unattended for days at times. The problem is, after Tor and computer have
run unattended for say a dozen hours, when I come back and make a client request myself thru Tor,
I will get this notice : "Application request when we're believed to be offline."
After which Tor (successfully)fetches directory information again.
I told of this problem on the IRC chat in the past, but apparently it hasn't made its way to the bug repository :(
Questions : - why did Tor believe it was "offline" ? Or is the warning bogus ? Was the /server/ still relaying and exiting
in the meantime ? I wonder why I would leave the puter running if Tor *really* falls asleep :=)
- Workaround, any ? Maybe send some sort of (TCP-)ping thru Tor at regular intervals ?
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: noino667Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/1206Fluxe3 is not a guard2020-06-13T14:03:23ZSebastian HahnFluxe3 is not a guardFluxe3 isn't considered a guard (only one of the authorities votes for it).
It has been up for 13 days, before that it had a downtime for ~30 minutes,
and before that it was running for a week. Before that it was offline.
There are a fe...Fluxe3 isn't considered a guard (only one of the authorities votes for it).
It has been up for 13 days, before that it had a downtime for ~30 minutes,
and before that it was running for a week. Before that it was offline.
There are a few things that seem to be strange. When arma looked at
what moria thinks about fluxe3 three days ago, moria thought that fluxe3's
uptime was 18 days. It somehow missed the fact that the descriptor changed
to reflect the new uptime.
The other question is, does this influence why Fluxe3 is not a guard? Or are
there other issues?
[Automatically added by flyspray2trac: Operating System: All]Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/1201mapaddress broken2020-06-13T14:03:22ZTracmapaddress brokenSince an update to 0.2.1.21 from 0.2.1.20 in both Linux and Windows, the mapaddress feature in the torrc file broke.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: johndoe32102002Since an update to 0.2.1.21 from 0.2.1.20 in both Linux and Windows, the mapaddress feature in the torrc file broke.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: johndoe32102002Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/1195manpage doesn't talk about mbytes and friends2020-06-13T14:03:20ZSebastian Hahnmanpage doesn't talk about mbytes and friendsMaking this bug report so I don't forget
waltman| In setting a value like AccountingMax in torrc, is there a difference
between "500 MB" and "500 MBytes"?
waltman| It's a bit confusing because the manpage says "KB", "MB", etc., but
...Making this bug report so I don't forget
waltman| In setting a value like AccountingMax in torrc, is there a difference
between "500 MB" and "500 MBytes"?
waltman| It's a bit confusing because the manpage says "KB", "MB", etc., but
the examples values all are "KBytes", e.g. "RelayBandwidthRate 100 KBytes"
Sebastian| you can use either one
waltman| cool, thanks
Sebastian| we should fix that in the manpage.
Sebastian| we're thinking about how we can make the manpage easier to
understand for the average use. Hopefully we'll find something.
In our efforts to make the manpage less confusing and more usable for people
with less *nix experience, we might want to explore explaining what we mean
when we allow the user to specify some amount of bandwidth in one section,
and the refer to that section from all the options.
[Automatically added by flyspray2trac: Operating System: All]Tor: 0.2.2.x-finalAndrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/legacy/trac/-/issues/1190Renegotiation bug still present on OpenBSD 4.6 stable2020-06-13T14:03:18ZTracRenegotiation bug still present on OpenBSD 4.6 stableRenegotiation bug still present on OpenBSD 4.6 with
ftp://ftp.openbsd.org/pub/OpenBSD/patches/4.6/common/004_openssl.patch applied.
Results in the supposedly fixed TLS renegotiation errors in .21, and prevents it from working. Works wit...Renegotiation bug still present on OpenBSD 4.6 with
ftp://ftp.openbsd.org/pub/OpenBSD/patches/4.6/common/004_openssl.patch applied.
Results in the supposedly fixed TLS renegotiation errors in .21, and prevents it from working. Works without the patch, but that
leaves the whole system vulnerable.
[warn] TLS error: unexpected close while renegotiating
same exact problem with 0.2.2.6-alpha
OpenBSD 4.6 ships with OpenSSL 0.9.8k
What is the work-around?
[Automatically added by flyspray2trac: Operating System: Other]
**Trac**:
**Username**: nixmlistsTor: 0.2.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/1184Sending useless relay cells after the destroy cell2020-06-13T14:05:36ZRoger DingledineSending useless relay cells after the destroy cellr9913 took out the "clear cell queue after sending destroy cell" logic.
Bug 1150 (comment 3519) points out that the cells are just going to get
dropped by the other side anyway.
I think it's right.
There are three places that call con...r9913 took out the "clear cell queue after sending destroy cell" logic.
Bug 1150 (comment 3519) points out that the cells are just going to get
dropped by the other side anyway.
I think it's right.
There are three places that call connection_or_send_destroy().
The first is in relay.c, where we unlink the circ from the n_conn
immediately after.
The second is in command.c, where we refuse new circuits for various
reasons. No cells queued yet.
The third is in circuitlist.c, during circuit-mark-for-close. So the
question is, if the circuit is marked, do we really want to still be
trying to send its cells? Either it got marked from the other side,
in which case the other side has already decided it doesn't want to hear
from us. Or it got marked from our side, in which case either that was
an error (circuit needs to die) or it has no streams on it, in which
case there's no harm in clearing its queue.
Did I miss anything?
Perhaps we should check, in main.c when we're considering whether to mark
it because it's idle, whether there are any cells still in its queue.
Or maybe we should just pass an argument into connection_or_send_destroy()
from the truncate case in relay.c saying "clear the queue please". Then we
can remain ambiguous in the cases above where I said "no harm because surely
the queue has nothing in it". That's certainly the safest approach, but
wouldn't it be nice to simplify rather than complexify? :)
[Automatically added by flyspray2trac: Operating System: All]Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/1177Segfault in unit tests on Mac OS X Panther2020-06-13T14:03:15ZedmanmSegfault in unit tests on Mac OS X Pantherhttps://buildbot.vidalia-project.net/builders/phobos.osx-panther.tor-master/builds/2101/steps/test/logs/stdio
Last few lines of output:
Dec 15 15:46:33.895 [info] circuit_build_times_add_timeout_worker(): Generated synthetic circuit bu...https://buildbot.vidalia-project.net/builders/phobos.osx-panther.tor-master/builds/2101/steps/test/logs/stdio
Last few lines of output:
Dec 15 15:46:33.895 [info] circuit_build_times_add_timeout_worker(): Generated synthetic circuit build time 102948 for timeout
Dec 15 15:46:33.895 [info] circuit_build_times_add_time(): Adding circuit build time 102948
Dec 15 15:46:33.895 [info] circuit_build_times_add_timeout_worker(): Generated synthetic circuit build time 65671 for timeout
Dec 15 15:46:33.895 [info] circuit_build_times_add_time(): Adding circuit build time 65671
Dec 15 15:46:33.895 [notice] Network connection speed appears to have changed. Resetting timeout to 120s after 16 timeouts and 55 buildtimes.
Dec 15 15:46:33.895 [notice] Network connection speed appears to have changed. Resetting timeout to 120s after 16 timeouts and 57 buildtimes.
process killed by signal 11
program finished with exit code -1
[Automatically added by flyspray2trac: Operating System: OSX 10.3 Panther]Tor: 0.2.2.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/1145Tor fails to load auth-certs2020-06-13T14:03:07ZTracTor fails to load auth-certsUsed 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**: knappoTor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/1141bug in networkstatus.c using 0.2.1.202020-06-13T14:09:03ZTracbug in networkstatus.c using 0.2.1.20Here 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
#2 0x000000000045cb81 in update_consensus_networkstatus_fetch_time (now=1257016692) at networkstatus.c:1183
#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
#4 0x000000000043feac in connection_dir_client_reached_eof (conn=0x2088f0d00) at directory.c:1638
#5 0x000000000044061e in connection_dir_reached_eof (conn=0x2088f0d00) at directory.c:2040
#6 0x000000000042626f in connection_handle_read (conn=0x2088f0d00) at connection.c:2037
#7 0x0000000000457b91 in conn_read_callback (fd=8833, event=6, _conn=0x37b7) at main.c:456
#8 0x000000020377f2e2 in event_process_active (base=0x201cfdc00) at /usr/src/lib/libevent/event.c:333
#9 0x000000020377f501 in event_base_loop (base=0x201cfdc00, flags=1) at /usr/src/lib/libevent/event.c:450
#10 0x000000020377f3b5 in event_loop (flags=8833) at /usr/src/lib/libevent/event.c:383
#11 0x0000000000459726 in do_main_loop () at main.c:1444
#12 0x000000000045a88b in tor_main (argc=5, argv=0x7f7fffff1850) at main.c:2070
#13 0x000000000040702c in ___start ()
#14 0x0000000000000005 in ?? ()
#15 0x00007f7fffff1d00 in ?? ()
#16 0x00007f7fffff1d1e in ?? ()
#17 0x00007f7fffff1d21 in ?? ()
#18 0x00007f7fffff1d27 in ?? ()
#19 0x00007f7fffff1d2b in ?? ()
#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**: mikebTor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/1138If bridge authority is unreachable, client doesn't fallback to bridge2020-06-13T14:06:35ZRoger DingledineIf bridge authority is unreachable, client doesn't fallback to bridgeWhen 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-finalRobert HoganRobert Hoganhttps://gitlab.torproject.org/legacy/trac/-/issues/1125(*chp)->next assertion fail?2020-06-13T14:02:52ZRoger 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-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/1107PublishServerDescriptor allows options 0 and 1 simultaneously2020-06-13T14:02:43ZSebastian HahnPublishServerDescriptor allows options 0 and 1 simultaneouslyThat 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-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/1094No way to specify a GeoIP country code miss in ExcludeNodes etc.2020-06-13T14:02:39ZTracNo way to specify a GeoIP country code miss in ExcludeNodes etc.Tor 0.2.1.19 currently lacks a way to specify a country that doesn't match
a GeoIP, even though the src/or/geoip.c module provides a country code
'??' that could be used to match a GeoIP miss. This GeoIP miss code
would let Tor administ...Tor 0.2.1.19 currently lacks a way to specify a country that doesn't match
a GeoIP, even though the src/or/geoip.c module provides a country code
'??' that could be used to match a GeoIP miss. This GeoIP miss code
would let Tor administrators block traffic to exit nodes that lack proper
GeoIP matches if in doubt about the true exit country. This seems more
like an implementation oversight than a feature, so I'm filing this as
a bug report.
I was able to produce a test case for this with:
-- The latest ip-to-country table from ip-to-country.webhosting.info
converted to Tor GeoIP format
-- Running Tor from the US
-- ExcludeNodes set to "{US},{??}"
-- An ExcludeNodes GeoIP miss on 66.230.230.230 (node AmericanProgress)
which shows up as in the US on MaxMind but is a total miss on the table
-- WebHosting.info: "IP Address 66.230.230.230 belongs to Some Place We Dont Know About."
(just to confirm that the table conversion worked OK)
After looking through the source code it looks like there's not enough
logging going on, even at the log_debug level, to see what is happening
exactly to the '??' match that pops out of the function
geoip_get_country_name().
The routerset_refresh_countries() function appears to kick the '??' country
out of the list if there's no match. I dummied up a GeoIP entry set like
this based on the last current entry of the GeoIP file:
4278190080,4294967294,US
4294967295,4294967295,??
That appears to be enough to satisfy the routerset functions in
src/or/routerlist.c so there's no complaint there, but this kludge
is useless for trying to get a match on a GeoIP miss. I suppose I
could write a script to patch gaps in the GeoIP file to kludge around
it yet another way and I could use one of the XX psuedo-countries
to work through this (which is what I'll probably do for now), but
it seems like there should be a well-known way to get this to work
without having to do that.
Any ideas?
[Automatically added by flyspray2trac: Operating System: Fedora Core Linux]
**Trac**:
**Username**: flypostedTor: 0.2.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/1090Warning about using an excluded node for exit2022-03-22T13:03:41ZSebastian HahnWarning about using an excluded node for exitQuite 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-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/1042rate-limit MaxOnionsPending warns2020-06-13T14:02:24ZRoger Dingledinerate-limit MaxOnionsPending warnsIf 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-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/997Hidden services fail to load if you have a stale descriptor2020-06-13T14:02:02ZRoger DingledineHidden services fail to load if you have a stale descriptorUsing 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-finalKarsten LoesingKarsten Loesinghttps://gitlab.torproject.org/legacy/trac/-/issues/988Different TLS certs for incoming vs outgoing2020-06-13T14:01:58ZRoger DingledineDifferent TLS certs for incoming vs outgoingWe should learn to present different TLS certs for incoming connections
vs outgoing connections.
The motivating example is bridges. They want to show the same identity
to people who connect, yet behave like clients when they connect to ...We should learn to present different TLS certs for incoming connections
vs outgoing connections.
The motivating example is bridges. They want to show the same identity
to people who connect, yet behave like clients when they connect to other
relays (e.g. change keys when they change IP addresses).
(Of course, this change would provide a new way to test for bridges: if a
Tor connects to you, connect back and see if the cert is different. But at
least that's an active test that requires the bridge to connect to you
first. But then, the attack I describe above only kicks in when the bridge
connects to you. Hm.)
[Automatically added by flyspray2trac: Operating System: All]Tor: 0.2.2.x-final