Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-06-27T14:11:12Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/121if two unverified servers exist at the same address, we list both as running2020-06-27T14:11:12ZRoger Dingledineif two unverified servers exist at the same address, we list both as runningrouter jet 194.152.184.163 9001 9050 9030
published 2005-04-05 20:16:10
router node01 194.152.184.163 9001 9050 9030
published 2005-04-05 13:55:51
Presumably node01 was published first, and then the operator changed the nickname
to jet...router jet 194.152.184.163 9001 9050 9030
published 2005-04-05 20:16:10
router node01 194.152.184.163 9001 9050 9030
published 2005-04-05 13:55:51
Presumably node01 was published first, and then the operator changed the nickname
to jet and left the same identity key in place. Now the dirservers list both as up.
Maybe this will get fixed in 24 hours when node01's descriptor becomes obsolete.
But this is a bad precedent. :)
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/1220.1.0.2_RC_CVS - Unstable Builds Under NetBSD 2.02020-06-27T14:11:11ZTrac0.1.0.2_RC_CVS - Unstable Builds Under NetBSD 2.0This is a Flyspray task for the NetBSD wierdness we have been discussing on the or-talk list.
To this point in time:
- Beginning about March 30, my daily CVS builds were being unstable - for a few days they crashed upon launch
- Then on...This is a Flyspray task for the NetBSD wierdness we have been discussing on the or-talk list.
To this point in time:
- Beginning about March 30, my daily CVS builds were being unstable - for a few days they crashed upon launch
- Then on April 3 or 4, the daily CVS builds started working again...
web browsing through tor dramatically increased in speed relative to builds prior to March 30
- About the same time there were many log messages. Initiated or-talk discussion...
- On the evening of April 5 (I'm in Indiana - EST for ref.) Nick Mathewson informed me he fixed part
of the problem in CVS but only for the no-pthreads version of tor.
- Morning of April 6, tor was running fine and no new log messages.
- Noticed new CVS changes so updated no-pthreads - restarted tor at 0600
- Just Checked log @ April 6, 3:30PM:
Apr 06 06:06:49.935 [err] Catching signal TERM, exiting cleanly.
Apr 06 06:06:52.404 [notice] Tor 0.1.0.2-rc-cvs opening log file.
Apr 06 11:13:53.401 [warn] circuit_receive_relay_cell(): Didn't recognize cell, but circ stops here! Closing circ.
Apr 06 11:13:53.450 [warn] command_process_relay_cell(): circuit_receive_relay_cell (forward) failed. Closing.
Apr 06 11:15:01.928 [err] Catching signal TERM, exiting cleanly.
Apr 06 11:15:04.890 [notice] Tor 0.1.0.2-rc-cvs opening log file.
Note: I do not recall restarting tor at 11:15, no new core file was generated???
- Just noticed more CVS changes, recompiled no-pthreads but have not installed and restarted
...should I?
- If I don't hear back, I probably will update and restart prior to going to sleep tonight.
[Automatically added by flyspray2trac: Operating System: BSD]
**Trac**:
**Username**: yancmNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/123TOR Installation not honouring Shortcuts setting2020-06-27T14:11:11ZTracTOR Installation not honouring Shortcuts settingVersion: tor-0.1.0.3-rc-win32.exe
Windows 2000 Service Pack 6
The installation program installed shortcuts into the Start Menu even
though the main Shortcut checkbox was unchecked. This could be because
the individual checkboxes (Start ...Version: tor-0.1.0.3-rc-win32.exe
Windows 2000 Service Pack 6
The installation program installed shortcuts into the Start Menu even
though the main Shortcut checkbox was unchecked. This could be because
the individual checkboxes (Start Menu and Desktop) weren't unchecked
first??
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: sentient0.1.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/125Try to assert(0) less vigorously2020-06-27T14:11:11ZNick MathewsonTry to assert(0) less vigorouslyThe recent assert_no_tls_errors() -> check_no_tls_errors() patch makes me worry that
there could be other places where we bail out of our code too aggressively. We should
go through our asserts and see if there are any places where we a...The recent assert_no_tls_errors() -> check_no_tls_errors() patch makes me worry that
there could be other places where we bail out of our code too aggressively. We should
go through our asserts and see if there are any places where we assert(0) that we could
recover from instead.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/126MacOS X 10.4 incompatibility Tor v0.1.0.4-rc2020-06-27T14:11:11ZTracMacOS X 10.4 incompatibility Tor v0.1.0.4-rcTried v0.1.0.3-rc and then v0.1.0.4-rc when it was released.
Apr 25 10:11:11.711 [notice] tor_init(): Tor v0.1.0.4-rc. This is experimental software. Do not rely on it for strong anonymity.
Apr 25 10:11:11.719 [notice] options_act(): In...Tried v0.1.0.3-rc and then v0.1.0.4-rc when it was released.
Apr 25 10:11:11.711 [notice] tor_init(): Tor v0.1.0.4-rc. This is experimental software. Do not rely on it for strong anonymity.
Apr 25 10:11:11.719 [notice] options_act(): Initialized libevent version 1.0d using method kqueue
Apr 25 10:11:33.988 [warn] Warning from libevent: kevent: Bad file descriptor
Apr 25 10:11:33.991 [err] do_main_loop(): libevent poll with kqueue failed: Bad file descriptor [9]
Sometimes it looks like it starts to work and then breaks when I try to visit a page like http://www.yahoo.com/.
Apr 25 10:17:13.519 [notice] tor_init(): Tor v0.1.0.4-rc. This is experimental software. Do not rely on it for strong anonymity.
Apr 25 10:17:13.528 [notice] options_act(): Initialized libevent version 1.0d using method kqueue
Apr 25 10:17:27.481 [notice] circuit_send_next_onion_skin(): Tor has successfully opened a circuit. Looks like it's working.
Apr 25 10:18:44.327 [warn] Warning from libevent: kevent: Bad file descriptor
Apr 25 10:18:44.329 [err] do_main_loop(): libevent poll with kqueue failed: Bad file descriptor [9]
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]
**Trac**:
**Username**: jamesparkhttps://gitlab.torproject.org/tpo/core/tor/-/issues/127Starting tor at boot, creates /.tor Directory2020-06-27T14:11:11ZTracStarting tor at boot, creates /.tor DirectoryVersion is 0.0.9.8 (that doesn't appear on the Reported Version drop-down).
Linux fubar 2.4.29 legacy/trac#21 Thu Jan 20 17:11:39 PST 2005 i686 unknown unknown GNU/Linux
I've established a user tor and group tor (and user privoxy and g...Version is 0.0.9.8 (that doesn't appear on the Reported Version drop-down).
Linux fubar 2.4.29 legacy/trac#21 Thu Jan 20 17:11:39 PST 2005 i686 unknown unknown GNU/Linux
I've established a user tor and group tor (and user privoxy and group privoxy) and am starting both in /etc/rc.d. tor is starting as a daemon, with "tor" specified in /usr/local/etc/tor/torrc for both user and group as is RunAsDaemon.
The problem is that starting like this wants /.tor -- I've created it, owned by tor, mode 700, but I wonder at the wisdom of doing so, and I can't find any setting that will prevent this. Is this a (potential) problem or am I just being too picky?
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: tronayne0.1.0.6-rcNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/129policy_includes_addr_mask_implicitly is broken?2020-06-27T14:11:11ZRoger Dingledinepolicy_includes_addr_mask_implicitly is broken?The default exit policy rejects internal IP spaces, yet
the server warns about them on startup when you leave your
exitpolicy undefined.
Apr 28 16:07:18.083 [warn] exit_policy_implicitly_allows_local_networks(): Exit
policy (default) i...The default exit policy rejects internal IP spaces, yet
the server warns about them on startup when you leave your
exitpolicy undefined.
Apr 28 16:07:18.083 [warn] exit_policy_implicitly_allows_local_networks(): Exit
policy (default) implicitly accepts localhost (127.x)
The "(default)" seems to imply that the if's in
policy_includes_addr_mask_implicitly are never triggered.
[Automatically added by flyspray2trac: Operating System: All]0.1.0.6-rcNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/130Quota exhausted in ... 1905?2020-06-27T14:11:11ZNick MathewsonQuota exhausted in ... 1905?From email:
<pre>
BTW, I just started up 0.0.9.9 and saw this in the log:
May 04 01:02:41.995 [notice] Tor 0.0.9.9 opening new log file.
May 04 01:02:42.414 [notice] accounting-set-wakeup-time(): Configured
hibernation. This interval...From email:
<pre>
BTW, I just started up 0.0.9.9 and saw this in the log:
May 04 01:02:41.995 [notice] Tor 0.0.9.9 opening new log file.
May 04 01:02:42.414 [notice] accounting-set-wakeup-time(): Configured
hibernation. This interval began at 2005-05-01 01:00:00; the
scheduled wake-up time was 2005-05-01 01:00:00; we expected to
exhaust our quota for this interval around 1905-01-15 19:13:12; the
next interval begins at 2005-06-01 01:00:00 (all times local)
May 04 01:02:51.075 [notice] circuit-send-next-onion-skin(): Tor has
successfully opened a circuit. Looks like it's working.
It is cool that I won't exhaust my quota until 1905, but that seems
like it may be a small bug. These are the lines from my torrc:
AccountingMax 500 GB
AccountingStart month 1 01:00
so that at least looks better.
[Automatically added by flyspray2trac: Operating System: All]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/131Tor dies unnecessarily if its IP address is private2020-06-27T14:11:10ZgoodellTor dies unnecessarily if its IP address is privateAfter reading the config, Tor commits suicide if its IP address is considered private, even if NoPublish == 1.
[Automatically added by flyspray2trac: Operating System: All]After reading the config, Tor commits suicide if its IP address is considered private, even if NoPublish == 1.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/133descriptors have address 0.0.0.0 until directory fetch2020-06-27T14:11:10Zgoodelldescriptors have address 0.0.0.0 until directory fetchDescriptors received from the controller via the POSTDESCRIPTOR directive are interpreted to have address 0.0.0.0. This is corrected at the time of the next periodic directory fetch, at which point the addr field of the routerinfo_t is ...Descriptors received from the controller via the POSTDESCRIPTOR directive are interpreted to have address 0.0.0.0. This is corrected at the time of the next periodic directory fetch, at which point the addr field of the routerinfo_t is populated with the correct address from the descriptor. Note that even if no descriptors with the same nickname or identity as the one received from the controller are received from the periodic directory fetch, the address of the descriptor received from the controller will apparently be changed to be the right one.
Indeed, this means that sending the HUP signal to the Tor process will always fix the problem, but ideally we should figure out why directory fetches are necessary to fix descriptors passed in from the controller.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/134Tor client install on OS X 10.4 (tiger)2020-06-27T14:11:10ZTracTor client install on OS X 10.4 (tiger)I have been unable to get tor, version tor 0.1.0.5-rc, or 0.0.9.9, running on tiger. The start script, when invoked manually, responds with: ./tor: line 59: $1: unbound variable
Chris
[Automatically added by flyspray2trac: Operating Sy...I have been unable to get tor, version tor 0.1.0.5-rc, or 0.0.9.9, running on tiger. The start script, when invoked manually, responds with: ./tor: line 59: $1: unbound variable
Chris
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]
**Trac**:
**Username**: istoneNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/138tor's dynamically linked against openssl version not in OSX 10.22020-06-27T14:11:10ZTractor's dynamically linked against openssl version not in OSX 10.2Hey guys - After installing Tor/Privoxy on my OS X 10.2 box and configuring everything according to the docs, I kept on getting Privoxy's 503 error that a few people have mentioned on the net(I haven't seen this solution yet).
Turns out...Hey guys - After installing Tor/Privoxy on my OS X 10.2 box and configuring everything according to the docs, I kept on getting Privoxy's 503 error that a few people have mentioned on the net(I haven't seen this solution yet).
Turns out after doing a bit of digging, when tor starts up, it pretty much instantly dies since the dynamic linker cannot find the openssl version 0.9.7:
dyld: ./tor can't open library: /usr/lib/libssl.0.9.7.dylib (No such file or directory, errno = 2)
This post has two purposes:
* Document the reason people are probably seeing the 503 error
* Ask the Tor group if it's possible to release a version of tor that's statically linked against OpenSSL 0.9.7 for those do not have it installed.
Personally, this hopefully won't be an issue to me after I upgrade to 10.4 tonight (I had somebody verify that 10.3.9 has openssl-0.9.7) but I'm sure others would appreciate it.
John
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]
**Trac**:
**Username**: jlkinselhttps://gitlab.torproject.org/tpo/core/tor/-/issues/140controller receives truncated INFOVALUE responses2020-06-27T14:11:10Zgoodellcontroller receives truncated INFOVALUE responsesThe controller sometimes receives truncated INFOVALUE responses, as observed by requesting descriptors (i.e. desc/name/router). This happens because s.recv(length) apparently is not guaranteed to read the entire length. The result is w...The controller sometimes receives truncated INFOVALUE responses, as observed by requesting descriptors (i.e. desc/name/router). This happens because s.recv(length) apparently is not guaranteed to read the entire length. The result is what appears to the controller to be multiple messages, not in fragment form, such that the first one looks like an ordinary INFOVALUE message of incorrect length and the rest look like improperly formed messages with weird types.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/141Tor 0.1.0.6-rc install fails on Mac OS X 10.42020-06-27T14:11:10ZTracTor 0.1.0.6-rc install fails on Mac OS X 10.4Installer log gives the following, but doesn't seem to say anything else helpful:
May 15 08:43:33 egel : run postflight script for Tor
May 15 08:43:33 egel : Install failed: The following install step failed: run postflight script for ...Installer log gives the following, but doesn't seem to say anything else helpful:
May 15 08:43:33 egel : run postflight script for Tor
May 15 08:43:33 egel : Install failed: The following install step failed: run postflight script for Tor
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: jtambolihttps://gitlab.torproject.org/tpo/core/tor/-/issues/142Tor 0-1.1.0.6-rc will not work on Tiger2020-06-27T14:11:10ZTracTor 0-1.1.0.6-rc will not work on TigerThe Tor versio )-1,0,6-rc would not install. Falling the advice given I installed 0-1.1.0.6-rc This installed OK but when I use it it will not go past the privoxy page.
[Automatically added by flyspray2trac: Operating System: All]
**Tr...The Tor versio )-1,0,6-rc would not install. Falling the advice given I installed 0-1.1.0.6-rc This installed OK but when I use it it will not go past the privoxy page.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: timbrophyhttps://gitlab.torproject.org/tpo/core/tor/-/issues/143libevent init log entries don't go to log files2020-06-27T14:11:10ZRoger Dingledinelibevent init log entries don't go to log filesWhen you start Tor logging to a file, the libevent entries
telling you what libevent version, what polling method, etc
don't ever appear. This is because they're logged before
we've configured the logs in options_act.
We should rejiggle...When you start Tor logging to a file, the libevent entries
telling you what libevent version, what polling method, etc
don't ever appear. This is because they're logged before
we've configured the logs in options_act.
We should rejiggle the order of all the options_act things I
guess.
[Automatically added by flyspray2trac: Operating System: All]0.1.0.9Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/144freebsd has su in /usr/bin2020-06-27T14:11:09ZRoger Dingledinefreebsd has su in /usr/binSo the contrib/torctl.in script points to the wrong place.
We should have autoconf check for where su is and then just
put that in.
[Automatically added by flyspray2trac: Operating System: BSD]So the contrib/torctl.in script points to the wrong place.
We should have autoconf check for where su is and then just
put that in.
[Automatically added by flyspray2trac: Operating System: BSD]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/145rpmbuild on SuSE 9.2 fails, missing rpm-build2020-06-27T14:11:09ZTracrpmbuild on SuSE 9.2 fails, missing rpm-buildRunning rpmbuild on SuSE 9.2 for 0.1.0.7-rc fails because the spec file requires package "rpm-build". In SuSE the rpmbuild program is included in the "rpm" package. Also the password utilities are in package pwdutils rather than shadow...Running rpmbuild on SuSE 9.2 for 0.1.0.7-rc fails because the spec file requires package "rpm-build". In SuSE the rpmbuild program is included in the "rpm" package. Also the password utilities are in package pwdutils rather than shadow-util. I changed it to test %{is_suse} and require the correct packages. It now builds, but won't install, claiming libevent is missing, which is isn't. I will figure that out.
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: merriamAndrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/tpo/core/tor/-/issues/146Tor Spontaneously Closing on Windows XP SP2 (libevent-related?)2020-06-27T14:11:09ZTracTor Spontaneously Closing on Windows XP SP2 (libevent-related?)Greetings. I am running Windows XP Professional, SP2, with all of
the latest patches and whatnot. I am unsure what--if any--other
information would be relevant to this problem.
I have been having this problem for the last few release ca...Greetings. I am running Windows XP Professional, SP2, with all of
the latest patches and whatnot. I am unsure what--if any--other
information would be relevant to this problem.
I have been having this problem for the last few release candidate
versions (probably since 0.1.0.3). While running
Tor/Tor-in-Server-Mode the program will, at times, just spontaneously
close. Sometimes I will be browsing the Internet through Tor;
sometimes it'll just be running in the background; sometimes I won't
even be at the computer. It gives no indication that there is a
problem; it just shuts down. It can do this anywhere from a few
minutes to a few hours after starting the program. I've tried studying
the debug logs to see some kind of 'common pattern' among the
shutdowns, but have been unable to find one. The only common
occurrence is the line:
[err] do_main_loop(): libevent poll with win32 failed: No such file or directory [2]
Searching the Internet/forums for this problem was not able to yield
any results/fixes. Considering that it hasn't been reported by anyone
else, I would assume this might be a problem with my local setup. But,
I thought I would submit it and see if there is any possible reason
for this or if I had a genuine bug in the program.
I'd be glad to provide any information that anyone may need. Feel free
to ask. And, thanks for any guidance you can provide in attempting to
solve the problem.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: JutralAndrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/tpo/core/tor/-/issues/147os x installer still references 0.0.9.1?2020-06-27T14:11:09ZRoger Dingledineos x installer still references 0.0.9.1?http://tor.eff.org/cvs/tor/contrib/osx/TorStartupDesc.plist
still lists 0.0.9.1. Perhaps it should get autoconfed like
the others to keep pace with the version?
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]http://tor.eff.org/cvs/tor/contrib/osx/TorStartupDesc.plist
still lists 0.0.9.1. Perhaps it should get autoconfed like
the others to keep pace with the version?
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]Nick MathewsonNick Mathewson