The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T14:10:59Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/257saveconf gives me a 250 OK even if it failed2020-06-27T14:10:59Zedmanmsaveconf gives me a 250 OK even if it failedIf I send a SAVECONF to Tor, Tor sends me a 250 OK even if Tor's logs tell me it had a problem
and my changes weren't actually saved.
[edmanm@adrastea:~]$ telnet localhost 9051
Trying 127.0.0.1...
Connected to localhost.
Escape characte...If I send a SAVECONF to Tor, Tor sends me a 250 OK even if Tor's logs tell me it had a problem
and my changes weren't actually saved.
[edmanm@adrastea:~]$ telnet localhost 9051
Trying 127.0.0.1...
Connected to localhost.
Escape character is '!^]'.
authenticate
250 OK
setconf nickname=testnickname
250 OK
saveconf
250 OK
quit
250 closing connection
Connection closed by foreign host.
[edmanm@adrastea:~]$ tor -ControlPort 9051
Feb 19 16:54:39.290 [notice] Tor v0.1.1.13-alpha. This is experimental software. Do not rely on it for strong anonymity.
Feb 19 16:54:39.293 [notice] Initialized libevent version 1.1a using method poll. Good.
Feb 19 16:54:39.294 [notice] connection_create_listener(): Opening Socks listener on 127.0.0.1:9050
Feb 19 16:54:39.295 [notice] connection_create_listener(): Opening Control listener on 127.0.0.1:9051
Feb 19 16:54:40.701 [notice] We now have enough directory information to build circuits.
Feb 19 16:54:43.262 [notice] Tor has successfully opened a circuit. Looks like it's working.
Feb 19 16:55:13.503 [notice] write_configuration_file(): Renaming old configuration file to "/Library/tor/torrc.orig.1"
Feb 19 16:55:13.503 [warn] Couldn't open "/Library/tor/torrc.tmp" for writing: Permission denied
[Automatically added by flyspray2trac: Operating System: All]Roger DingledineRoger Dingledinehttps://gitlab.torproject.org/tpo/core/tor/-/issues/259FreeBSD 6 compiling against incorrect version of OpenSSL2020-06-27T14:10:59ZTracFreeBSD 6 compiling against incorrect version of OpenSSLI'm not sure what versions of tor this affects, but so far it's been a problem with any version that didn't exist in BSD ports. Apparently BSD ports already
makes the necessary changes to the Makefile, so any version installed via ports...I'm not sure what versions of tor this affects, but so far it's been a problem with any version that didn't exist in BSD ports. Apparently BSD ports already
makes the necessary changes to the Makefile, so any version installed via ports will work properly.
As I understand it, FreeBSD has a version of OpenSSL included with the base system that is older than the version included in ports. Other programs in the
base system link against the version of OpenSSL included in the base system, and programs installed from ports will link with the one included from ports.
The version of OpenSSL in the base system is installed in /lib, while the ports version is in /usr/local/lib.
When compiling tor from source, whether a stable release, unstable release, or from CVS, the compile will proceed without any warnings or errors. However,
upon running tor, the node is unable to establish connections to any other tor nodes. I couldn't figure out why at first, just lots of TLS errors about broken
connections, until I found out the tor binary linked to the wrong version of OpenSSL. I guess the older version (I'm not sure what version it is) doesn't support
the necessary things.
Anyway, I tried using the configure script to force tor to build using OpenSSL from /usr/local/lib, but it never seemed to work. I'm assuming that the GNU
automake/autoconf/whatever tools simply link with the first version of a needed library it finds. I'm not a programmer nor a developer, so I don't know how
this whole process really works. I did find out, though, that if I add "-rpath=/usr/local/lib" to the LDFLAGS in src/or/Makefile, tor will compile and link
against the proper version of OpenSSL. This is how the BSD port does it, and it took me a little while to figure it out. Upon changing the Makefile and
rebuilding tor, it works like a charm.
I don't know how to permanently fix it, but, in case anyone else is having problems and looks here, at least they'll see this documented. ;)
[Automatically added by flyspray2trac: Operating System: BSD]
**Trac**:
**Username**: mysticone0.1.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/261getinfo orconn-status sometimes crashes2020-06-27T14:10:59Zgoodellgetinfo orconn-status sometimes crashesRequesting 'getinfo orconn-status' from the Controller sometimes causes Tor to crash.
On most of my servers, this request consistently works normally, but on serifos, this
request seems to consistently cause the crash condition. I have ...Requesting 'getinfo orconn-status' from the Controller sometimes causes Tor to crash.
On most of my servers, this request consistently works normally, but on serifos, this
request seems to consistently cause the crash condition. I have no explanation, though
I suspect that perhaps some combination of high-volume client activity and high-volume
server activity is to blame. This is my test:
$ telnet localhost 9051
authenticate
250 OK
getinfo orconn-status
Connection closed by foreign host.
The crash is violent, and there are no interesting error messages in the log.
The backtrace is as follows:
(gdb) bt
#0 0xb7ce8c73 in strlen () from /lib/tls/i686/cmov/libc.so.6
#1 0x080733f5 in handle_control_getinfo (conn=0xb4289cf0, len=<value optimized out>, body=0x8abe078 "orconn-status\r\n") at control.c:1415
legacy/trac#2 0x08075dde in connection_control_process_inbuf_v1 (conn=0xb4289cf0) at control.c:2185
legacy/trac#3 0x08075f59 in connection_control_process_inbuf (conn=0xb4289cf0) at control.c:2374
legacy/trac#4 0x08065efa in connection_process_inbuf (conn=0x0, package_partial=1) at connection.c:1918
legacy/trac#5 0x08068439 in connection_handle_read (conn=0xb4289cf0) at connection.c:1225
legacy/trac#6 0x08086769 in conn_read_callback (fd=186, event=2, _conn=0xb4289cf0) at main.c:383
legacy/trac#7 0xb7db5c79 in event_base_priority_init () from /usr/lib/libevent-1.1a.so.1
legacy/trac#8 0xb7db5f65 in event_base_loop () from /usr/lib/libevent-1.1a.so.1
legacy/trac#9 0xb7db5dcb in event_loop () from /usr/lib/libevent-1.1a.so.1
legacy/trac#10 0xb7db5cb0 in event_dispatch () from /usr/lib/libevent-1.1a.so.1
legacy/trac#11 0x080887d7 in tor_main (argc=0, argv=0x0) at main.c:1155
legacy/trac#12 0xb7c8feb0 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
legacy/trac#13 0x0804c5c1 in _start () at ../sysdeps/i386/elf/start.S:119
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/263access directory contents via the controller2020-06-27T14:10:59Zgoodellaccess directory contents via the controllerI would like to access directory contents via the controller. Ideally, everything
available via HTTP requests to the ControlPort for /tor/* should also be available
via GETINFO requests for tor/* via the controller.
Specifically, this ...I would like to access directory contents via the controller. Ideally, everything
available via HTTP requests to the ControlPort for /tor/* should also be available
via GETINFO requests for tor/* via the controller.
Specifically, this means that all of the HTTP URLs listed under section 4.4 of
dir-spec.txt MUST be made available via the controller, even if DirPort is not set,
with the proviso that unlike the HTTP service, which MUST provide compressed versions
and SHOULD provide uncompressed versions, the controller service MUST provide
uncompressed versions and SHOULD provide compressed versions.
Finally, any descriptors not marked as suitable for public consumption (see Bug legacy/trac#250)
MUST not be included in any reports issued by either the controller service or the
HTTP service.
[Automatically added by flyspray2trac: Operating System: All]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/264controller denied access to streams in SENTCONNECT state2020-06-27T14:10:59Zgoodellcontroller denied access to streams in SENTCONNECT stateIf a stream is in the SENTCONNECT state but has not succeeded yet, then the
controller has no means of reattaching this stream to another circuit. For
example,
attachstream 266 62
555 Connection is not managed by controller.
Clearly, ...If a stream is in the SENTCONNECT state but has not succeeded yet, then the
controller has no means of reattaching this stream to another circuit. For
example,
attachstream 266 62
555 Connection is not managed by controller.
Clearly, the controller ought to be able to tell Tor to terminate the
SENTCONNECT state early. We can do this in two ways:
1. Presume that the only reason to terminate SENTCONNECT early is to attach
a stream to a different circuit. This means that we are really interested in
extending the capability of the ATTACHSTREAM directive to support reattaching
even streams in the SENTCONNECT state.
2. Create a DETACHSTREAM controller command that can explicitly detach a
stream from a circuit (perhaps this should only work if the stream is in
the SENTCONNECT state), causing the stream to enter the DETACHED state,
thus becoming suitable for reconnection via the controller.
[Automatically added by flyspray2trac: Operating System: All]Roger DingledineRoger Dingledinehttps://gitlab.torproject.org/tpo/core/tor/-/issues/265Tor fails to bootstrap if 24 hours pass without running it2020-06-27T14:10:59ZRoger DingledineTor fails to bootstrap if 24 hours pass without running itIf I run my Tor client, then close it and wait 24 hours, it will fail
to realize that it has enough directory info to try to build circuits.
Restarting the Tor client a bunch of times doesn't seem to fix anything.
I need to rm -rf my ....If I run my Tor client, then close it and wait 24 hours, it will fail
to realize that it has enough directory info to try to build circuits.
Restarting the Tor client a bunch of times doesn't seem to fix anything.
I need to rm -rf my .tor directory before it will start working again.
More investigation needed, but I presume the bug is that in one part of
the code it believes something is new enough that it doesn't need to fetch
another one, but in another part of the code it believes it's not new
enough to use.
[Automatically added by flyspray2trac: Operating System: All]0.1.1.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/267undefined symbol __FUNCTION__ if not using GCC2020-06-27T14:10:58ZTracundefined symbol __FUNCTION__ if not using GCCTrying to compile both 0.1.0.x and 0.1.1.x tree with Sun C instead of GCC, I get the following error:
undefined symbol: __FUNCTION__
in the following files:
container.c
log.c
util.c
compat.c
I think it's needed something like:
#ifndef ...Trying to compile both 0.1.0.x and 0.1.1.x tree with Sun C instead of GCC, I get the following error:
undefined symbol: __FUNCTION__
in the following files:
container.c
log.c
util.c
compat.c
I think it's needed something like:
#ifndef __FUNCTION__
#define __FUNCTION__ /something.../
#endif
[Automatically added by flyspray2trac: Operating System: Solaris]
**Trac**:
**Username**: calessiohttps://gitlab.torproject.org/tpo/core/tor/-/issues/268allow controller to manage circuit extensions2020-06-27T14:10:58Zgoodellallow controller to manage circuit extensionsTor controllers should have a means of learning more about circuits built through
Tor routers. Specifically, if a Tor controller is connected to a Tor router, it
should be able to subscribe to a new class of events, perhaps "onion" or "...Tor controllers should have a means of learning more about circuits built through
Tor routers. Specifically, if a Tor controller is connected to a Tor router, it
should be able to subscribe to a new class of events, perhaps "onion" or "router"
events. A Tor router SHOULD then ensure that the controller is informed:
(a) (NEW) when it receives a connection from some other location, in which case
it SHOULD indicate (1) a unique identifier for the circuit, and (2) a ServerID
in the event of an OR connection from another Tor router, and Hostname otherwise.
(b) (REQUEST) when it receives a request to extend an existing circuit to
a successive Tor router, in which case it SHOULD provide (1) the unique identifier
for the circuit, (2) a Hostname (or, if possible, ServerID) of the previous Tor
router in the circuit, and (3) a ServerID for the requested successive Tor router
in the circuit;
(c) (EXTEND) Tor will attempt to extend the circuit to some other router,
in which case it SHOULD provide the same fields as provided for REQUEST.
(d) (SUCCEEDED) The circuit has been successfully extended to some ther router,
in which case it SHOULD provide the same fields as provided for REQUEST.
We also need a new configuration option analogous to _leavestreamsunattached,
specifying whether the controller is to manage circuit extensions or not. Perhaps
we can call it "_leavecircuitsunextended". When set to 0, Tor manages everything
as usual. When set to 1, a circuit received by the Tor router cannot transition
from "REQUEST" to "EXTEND" state without being directed by a new controller
command. The controller command probably does not need any arguments, since
circuits are extended per client source routing, and all that the controller does
is accept or reject the extension.
This feature can be used as a basis for enforcing routing policy.
[Automatically added by flyspray2trac: Operating System: All]post 0.2.0.xRoger DingledineRoger Dingledinehttps://gitlab.torproject.org/tpo/core/tor/-/issues/269compile process ignores rpm mtune parameter2020-06-27T14:10:58ZAndrew Lewmancompile process ignores rpm mtune parameterDuring the build process of configure && make dist-rpm, the --host and --build paramters passed to configure
at any stage are auto-determined by a subsequent configure command. These subsequent configure scripts will
change the desired ...During the build process of configure && make dist-rpm, the --host and --build paramters passed to configure
at any stage are auto-determined by a subsequent configure command. These subsequent configure scripts will
change the desired --host and --build options to the current system, regardless of what the user instructed
the topmost level configure to pass along.
[Automatically added by flyspray2trac: Operating System: Other Linux]0.1.1.x-finalAndrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/tpo/core/tor/-/issues/270__inline is not defined in Sun C2020-06-27T14:10:58ZTrac__inline is not defined in Sun CTrying to compile Tor 0.1.1.15 RC on Solaris using Sun C instead of GCC, i get syntax errors due to the unknown token "__inline".
On Sun C it should be replaced with "inline".
This check is missing at least on ht.c
[Automatically added ...Trying to compile Tor 0.1.1.15 RC on Solaris using Sun C instead of GCC, i get syntax errors due to the unknown token "__inline".
On Sun C it should be replaced with "inline".
This check is missing at least on ht.c
[Automatically added by flyspray2trac: Operating System: Solaris]
**Trac**:
**Username**: calessiohttps://gitlab.torproject.org/tpo/core/tor/-/issues/271Assertion global_state failed on --list-fingerprint2020-06-27T14:10:58ZSteven MurdochAssertion global_state failed on --list-fingerprintWhen running "tor --list-fingerprint" using a config file generated by make-private-tor-network.py,
Tor exits with an assertion error:
$ tor -f ./nodeD0/torrc --list-fingerprint
Mar 14 20:16:10.618 [notice] Tor v0.1.1.15-rc. This is exp...When running "tor --list-fingerprint" using a config file generated by make-private-tor-network.py,
Tor exits with an assertion error:
$ tor -f ./nodeD0/torrc --list-fingerprint
Mar 14 20:16:10.618 [notice] Tor v0.1.1.15-rc. This is experimental software. Do not rely on it for strong anonymity.
Mar 14 20:16:10.619 [warn] You have used DirServer to specify 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.
nodeD0 36A9 8FA9 FB7B 16EC 0098 664F E3AA CD18 13CE 8A14
Mar 14 20:16:10.747 [err] config.c:4049: or_state_save: Assertion global_state failed; aborting.
config.c:4049 or_state_save: Assertion global_state failed; aborting.
Aborted
[Automatically added by flyspray2trac: Operating System: Other Linux]https://gitlab.torproject.org/tpo/core/tor/-/issues/272servers complain that they're unnamed too soon2020-06-27T14:10:58ZRoger Dingledineservers complain that they're unnamed too soonMar 13 23:16:05.852 [warn] routers_update_all_from_networkstatus(): 0/2
recent directory servers recognize this server. Please consider sending
your identity fingerprint to the tor-ops.
This occurs when it has network statuses from mori...Mar 13 23:16:05.852 [warn] routers_update_all_from_networkstatus(): 0/2
recent directory servers recognize this server. Please consider sending
your identity fingerprint to the tor-ops.
This occurs when it has network statuses from moria1 and moria2 but not
tor26 yet. One fix is to only complain once we have all the network statuses,
but this will be bad if one dir server vanishes down the road.
Weasel suggests that we don't complain until we've *tried to get* all the
network statuses, and then only complain if some threshold consider us
unnamed.
[Automatically added by flyspray2trac: Operating System: All]0.1.1.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/273...but need_to_mirror=1.2020-06-27T14:10:58ZRoger Dingledine...but need_to_mirror=1.Mar 17 18:56:19.162 [warn] update_router_descriptor_cache_downloads(): We have a
router descriptor, but need_to_mirror=1.
I get many of these consistently when I start a new AuthDirServer with nothing
cached. Can we add some more log e...Mar 17 18:56:19.162 [warn] update_router_descriptor_cache_downloads(): We have a
router descriptor, but need_to_mirror=1.
I get many of these consistently when I start a new AuthDirServer with nothing
cached. Can we add some more log entries around them? Even at log-level debug,
it's just a string of 30 or 40 of these warn lines in a row.
[Automatically added by flyspray2trac: Operating System: All]0.1.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/274wrong check for CFLAGS when using Sun C2020-06-27T14:10:58ZTracwrong check for CFLAGS when using Sun Cusing sun C, configure reports "-Wall -O2 -g" as valid CFLAGS, but only "-g" is a valid flag in Sun C.
(this is wrong in .16-rc too)
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: calessiousing sun C, configure reports "-Wall -O2 -g" as valid CFLAGS, but only "-g" is a valid flag in Sun C.
(this is wrong in .16-rc too)
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: calessioNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/275setconf should be more helpful when things go wrong2020-06-27T14:10:58Zedmanmsetconf should be more helpful when things go wrong[edmanm@adrastea:~]$ telnet localhost 9051
Trying 127.0.0.1...
Connected to localhost.
Escape character is '!^]'.
authenticate
250 OK
setconf nickname=foofoo exitpolicy=foobar orport=9030
513 Unacceptable option value
I already know tha...[edmanm@adrastea:~]$ telnet localhost 9051
Trying 127.0.0.1...
Connected to localhost.
Escape character is '!^]'.
authenticate
250 OK
setconf nickname=foofoo exitpolicy=foobar orport=9030
513 Unacceptable option value
I already know that one of the arguments is unacceptable, since the response code
is 513 and the control protocol spec tells me what that means. But the accompanying
error message doesn't tell me which one is bogus.
This makes it hard to write useful error messages in a controller, since they all
amount to saying, "Something went wrong, but I don't know what. Go look at your log,
then come back and try again."
[Automatically added by flyspray2trac: Operating System: All]Roger DingledineRoger Dingledinehttps://gitlab.torproject.org/tpo/core/tor/-/issues/276assertion crash on OpenBSD2020-06-27T14:10:57ZTracassertion crash on OpenBSDrunning tor 0.1.0.17 as an exit node on OpenBSD 3.8 (i386). has crashed
quite a few times, can't seem to stay running for more than a day or so.
can't easily reproduce crash other than to let it run for a while.
(running in gdb)
Progr...running tor 0.1.0.17 as an exit node on OpenBSD 3.8 (i386). has crashed
quite a few times, can't seem to stay running for more than a day or so.
can't easily reproduce crash other than to let it run for a while.
(running in gdb)
Program received signal SIGPIPE, Broken pipe.
Program received signal SIGPIPE, Broken pipe.
Program received signal SIGPIPE, Broken pipe.
buffers.c:1054 assert_buf_ok: Assertion u32 == START_MAGIC failed; aborting.
buffers.c:1054 assert_buf_ok: Assertion u32 == START_MAGIC failed; aborting.
buffers.c:1054 assert_buf_ok: Assertion u32 == START_MAGIC failed; aborting.
tor: (0xd0caf465)tor in free(): error: free_pages: pointer to wrong page
tor in free(): error: ifree: junk pointer, too high to make sense
Program received signal SIGABRT, Aborted.
0x06c0a559 in kill () from /usr/lib/libc.so.38.2
(gdb) bt
#0 0x06c0a559 in kill () from /usr/lib/libc.so.38.2
#1 0x06c46463 in abort () from /usr/lib/libc.so.38.2
legacy/trac#2 0x1c0061a0 in assert_buf_ok (buf=0x7d02b020) at buffers.c:1054
legacy/trac#3 0x1c01b79b in assert_connection_ok (conn=0x7c39c800, now=1143187904)
at connection.c:1721
legacy/trac#4 0x1c033ea5 in conn_read_callback (fd=74, event=2, _conn=0x7c39c800)
at main.c:351
legacy/trac#5 0x1c05d070 in event_base_priority_init ()
legacy/trac#6 0x1c05d26a in event_base_loop ()
legacy/trac#7 0x1c05d108 in event_loop ()
legacy/trac#8 0x1c05d091 in event_dispatch ()
legacy/trac#9 0x1c035264 in do_main_loop () at main.c:953
legacy/trac#10 0x1c035f52 in tor_main (argc=3, argv=0xcfbca3dc) at main.c:1620
legacy/trac#11 0x1c04c3fa in main (argc=3, argv=0xcfbca3dc) at tor_main.c:19
[Automatically added by flyspray2trac: Operating System: BSD]
**Trac**:
**Username**: jcshttps://gitlab.torproject.org/tpo/core/tor/-/issues/277Fetch networkstatuses scalably2020-06-27T14:10:57ZRoger DingledineFetch networkstatuses scalablyRight now we try to fetch the minimum number of networkstatus pages that
would make us happy. If one fails, we wait a minute before trying just
enough again. We should do something smarter, for example, fetching
more originally, and retr...Right now we try to fetch the minimum number of networkstatus pages that
would make us happy. If one fails, we wait a minute before trying just
enough again. We should do something smarter, for example, fetching
more originally, and retrying immediately to fetch another pile if too
many fail from the first attempt.
Along with this, we need to audit all the places in the code where we
require a threshold of networkstatuses to claim something. I believe we
have fencepost errors all over. And in some places we still use constants
that assume there are always 3 networkstatuses in the network. Lastly, we
should make sure that an independent Tor network can still function if it
has only one authdirserver.
[Automatically added by flyspray2trac: Operating System: All]0.1.1.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/278Register multiple hidden services using Tor Controller2020-06-27T14:10:57ZRoger DingledineRegister multiple hidden services using Tor ControllerReported by Karsten Loesing <karsten.loesing@wiai.uni-bamberg.de>
How can I configure multiple hidden services using Tor Controller?
My first approach was to set the hidden service options one after the
other using TorControlConnection...Reported by Karsten Loesing <karsten.loesing@wiai.uni-bamberg.de>
How can I configure multiple hidden services using Tor Controller?
My first approach was to set the hidden service options one after the
other using TorControlConnection.setConf(List). The result is that after
I registered two hidden services, only the second is running. It appears
to overwrite the settings of the first service.
The second approach was to set both hidden services using one option
list. Then the controller complains when the second part of the options
is parsed, that the directory of the first hidden service cannot be written.
Configuring multiple hidden service using a config file works. But I
need to dynamically add hidden services during runtime.
[Automatically added by flyspray2trac: Operating System: All]0.1.1.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/279Specific ExitNode Entry Causing Client To Crash2020-06-27T14:10:57ZTracSpecific ExitNode Entry Causing Client To CrashI have found that when I specify a list of ExitNodes in conjunction with the StrictExitNodes option (in my Torrc configuration),
AND my ExitNodes list contains the node named "augrime", that the TOR process will terminate. If true, it i...I have found that when I specify a list of ExitNodes in conjunction with the StrictExitNodes option (in my Torrc configuration),
AND my ExitNodes list contains the node named "augrime", that the TOR process will terminate. If true, it is disturbing to
think that one particular Exit Node can cause vaporization of the TOR process.
Additional comments:
a) I am using TOR 0.1.1.17-RC configured for ClientOnly mode.
b) I am using LibEvent 1.1a
c) I am using Linux (and have had no problems with TOR to-date)
d) I found no similar bugs reported to this one
e) I can repeat this crash each and every time I run TOR
f) The crash causes the TOR process to not complete in its launching. Thus, the process terminates
with a "Segmentation fault", but no details are left behind. I've looked for a "core" file ... none. I've
run in non-daemon mode and with debug level logging, yet the log only produces this (and never makes it past listing
details about nodes past the "augrime" node:
...
Apr 03 16:43:31.084 [notice] We now have enough directory information to build circuits.
Apr 03 16:43:31.087 [info] or_state_save(): Saved state to "/root/.tor/state"
Apr 03 16:43:31.088 [debug] circuit_remove_handled_ports(): Port 80 is not handled.
Apr 03 16:43:31.088 [info] circuit_predict_and_launch_new(): Have 0 clean circs (0 internal), need another exit circ.
Apr 03 16:43:31.088 [debug] new_route_len(): Chosen route length 3 (660 routers available).
Apr 03 16:43:31.090 [info] choose_good_exit_server_general(): Found 205 servers that might support 0/0 pending connections.
[1]+ Segmentation fault /usr/local/bin/tor
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: jegearhttps://gitlab.torproject.org/tpo/core/tor/-/issues/280getaddrinfo does not set hints2020-06-27T14:10:57ZTracgetaddrinfo does not set hintsgetaddrinfo in src/common/compat.c gives NULL as hints parameter, so tor servers usually end up doing useless AAAA queries.
also, I believe it's better if it gave random IP address, instead of the first one returned from DNS proxy.
there...getaddrinfo in src/common/compat.c gives NULL as hints parameter, so tor servers usually end up doing useless AAAA queries.
also, I believe it's better if it gave random IP address, instead of the first one returned from DNS proxy.
there are many DNS proxies which do not randomize the returned resource record set.
in addition to this patch, makefiles need fixing to get crypto_pseudo_rand_int linked into tor-resolve.
I get undefined reference to smartlist_get, but it's supposed to be in libor.a. somebody else might want to sort this out.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Safari0.1.2.x-finalNick MathewsonNick Mathewson