Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2021-07-09T17:22:31Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/41nickname length enforcement has fencepost errors2021-07-09T17:22:31ZRoger Dingledinenickname length enforcement has fencepost errorsDec 23 19:08:53.410 [warn] connection_tls_finish_handshake(): Other side (80.127.47.237:9001) is 'thetimesareachangi', but we tried to connect to 'thetimesareachangin'
It should either not have a problem here, or it should have prevente...Dec 23 19:08:53.410 [warn] connection_tls_finish_handshake(): Other side (80.127.47.237:9001) is 'thetimesareachangi', but we tried to connect to 'thetimesareachangin'
It should either not have a problem here, or it should have prevented this guy from starting his server.
Once we track down which it is, we should audit the rest of the uses of options->nickname to make sure it isn't happening elsewhere.
[Automatically added by flyspray2trac: Operating System: All]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/42Overzealous clock skew checking keeps clients from working2020-06-27T14:11:20ZNick MathewsonOverzealous clock skew checking keeps clients from workingThe check for time skew in connection_or.c which produces the log message: "Router '%s' (%s:%d) has a skewed clock..." seems to get called even when Tor is running as a client. This is not as intended; only servers should be forced to m...The check for time skew in connection_or.c which produces the log message: "Router '%s' (%s:%d) has a skewed clock..." seems to get called even when Tor is running as a client. This is not as intended; only servers should be forced to make sure their clocks are relatively correct.
Arma questions whether we should care about clock skew at all. The attacks that we're protecting against are server impersonation attacks where the attacker manage to compromise an older private key for a server, but not a newer one. This doesn't seem very realistic now, since compromising a server's private key will almost surely reveal its identity key; but a slightly cleverer key management system might in the future make this attack meaningfully difficult.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/43Worker threads die vigorously on win32.2020-06-27T14:11:20ZNick MathewsonWorker threads die vigorously on win32.When people try to run a Tor server on windows, it seems that their CPU worker threads and DNS threads too die badly. Or maybe the tor_socketpair stuff isn't really working.
[...]
Dec 25 07:55:03.156 [warn] connection_dns_reached_eof(...When people try to run a Tor server on windows, it seems that their CPU worker threads and DNS threads too die badly. Or maybe the tor_socketpair stuff isn't really working.
[...]
Dec 25 07:55:03.156 [warn] connection_dns_reached_eof(): Read eof. Worker died unexpectedly.
Dec 25 07:55:03.156 [warn] connection_cpu_reached_eof(): Read eof. Worker died unexpectedly.
[...]
Also, these dead workers don't prevent Tor from reporting itself as working when the first circuit is built. That's probably bad.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]https://gitlab.torproject.org/tpo/core/tor/-/issues/33669"Pluggable Transport process terminated" but Tor keeps on going (and of cours...2023-05-30T18:39:08ZRoger Dingledine"Pluggable Transport process terminated" but Tor keeps on going (and of course doesn't work)In https://trac.torproject.org/projects/tor/ticket/33336#comment:20 I encountered the unfortunate situation where my snowflake client exited:
```
Feb 25 14:36:24.458 [warn] Pluggable Transport process terminated with status code 512
```
...In https://trac.torproject.org/projects/tor/ticket/33336#comment:20 I encountered the unfortunate situation where my snowflake client exited:
```
Feb 25 14:36:24.458 [warn] Pluggable Transport process terminated with status code 512
```
It still remains unclear whether snowflake had a bug that crashed it, or if Tor has a bug that made it close the socket to snowflake.
But either way, after this event Tor quietly cries to itself:
```
Feb 25 14:36:44.825 [warn] The connection to the SOCKS5 proxy server at 127.0.0.1:45527 just failed. Make sure that the proxy server is up and running.
```
and Tor Browser has no idea this is happening, or that trying to use Tor is now hopeless.
We should figure out something smarter that Tor should do in this situation. Perhaps it should exit, forcing the user to notice? Perhaps it should emit an event that Tor Browser picks up on? Maybe we have an even better idea?Tor: 0.4.8.x-freezeAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.org2023-05-31https://gitlab.torproject.org/tpo/core/tor/-/issues/40396Good bridge + bad bridge = no bootstrap2023-01-10T17:59:43ZanonymGood bridge + bad bridge = no bootstrap### Summary
If I configure `tor` with one known-good bridge and one known-bad bridge (e.g. the host is simply not a bridge) then `tor` refuses to bootstrap.
(By the way, in Tor Browser the UX is pretty bad in this situation, because To...### Summary
If I configure `tor` with one known-good bridge and one known-bad bridge (e.g. the host is simply not a bridge) then `tor` refuses to bootstrap.
(By the way, in Tor Browser the UX is pretty bad in this situation, because Tor Launcher just stays at 70% progress and never reports an error to the user.)
### What is the current bug behavior?
We get stuck with:
> May 17 11:10:35.000 [info] I learned some more directory information, but not enough to build a circuit: We're missing descriptors for 1/2 of our primary entry guards (total microdescriptors: 6540/6540). That's ok. We will try to fetch missing descriptors soon.
### What is the expected behavior?
I expected `tor` to ignore the bad bridge and successfully bootstrap using only the good bridge.
### Environment
This is the case both in Tails, Debian Sid and Tor Browser 10.0.16.
### Possible fixes and discussion
I wonder, if this is not a bug, is this because even when using bridges, `tor` tries to respect `guard-n-primary-guards-to-use`/`NumEntryGuards`? If so there seems to be an exception when only one (know-good) bridge is provided, because then bootstrapping works. Is all this expected/intended? Or am I confused?
Taking a step back, to me it seems harsh on users to enforce something like `NumEntryGuards` for user-configured bridges since it puts a lot of responsibility on them to ensure at least two are working, with no clear way for them check that (basically, they have to read and understand the logs). Otherwise the software used to configure `tor` (e.g. Tor Launcher, or its replacements) has to get better at detecting individual bridge failures and give the user some way to drop bad ones.Alexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/44resolve_my_address() failures can lead to crash.2020-06-27T14:11:20ZNick Mathewsonresolve_my_address() failures can lead to crash.If resolve_my_address() fails at a HUP, then rather than continuing with the old address (desirable if the address hasn't changed) or exiting gracefully (maybe desirable if the address has changed), Tor simply crashes at places like
ma...If resolve_my_address() fails at a HUP, then rather than continuing with the old address (desirable if the address hasn't changed) or exiting gracefully (maybe desirable if the address has changed), Tor simply crashes at places like
main.c: if (write_str_to_file(keydir,
router_get_my_descriptor(), 0)) {
This should get fixed.
Reported by Ben L.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/45win32 torrc contains automake macros2020-06-27T14:11:19ZRoger Dingledinewin32 torrc contains automake macrosThe entries in the torrc that ships with win32 still contain
macros like @LOCALSTATEDIR@, which win32 users don't know
what to do with. This makes it really hard for them to, e.g.,
configure logs. Can we convert them to a reasonable set ...The entries in the torrc that ships with win32 still contain
macros like @LOCALSTATEDIR@, which win32 users don't know
what to do with. This makes it really hard for them to, e.g.,
configure logs. Can we convert them to a reasonable set of
defaults on win32 before shipping?
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]0.0.9.5Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/47Why does the win32 installer have a click-through license?2020-06-27T14:11:19ZRoger DingledineWhy does the win32 installer have a click-through license?Our license is permissive, that is, it only grants rights,
it does not grant rights in exchange for giving up other
rights. So why do we require users to acknowledge that
they "agree" to it?
[Automatically added by flyspray2trac: Operat...Our license is permissive, that is, it only grants rights,
it does not grant rights in exchange for giving up other
rights. So why do we require users to acknowledge that
they "agree" to it?
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/48assertion failure: resolve->pending_connection2020-06-27T14:11:19ZNick Mathewsonassertion failure: resolve->pending_connectionReported by Giorgos P.
Dec 31 07:50:01.038 [err] dns.c:399: dns_cancel_pending_resolve:
Assertion resolve->pending_connections failed; aborting.
_probably_ unrelated to other warning:
Dec 30 15:46:29.338 [warn] connection_dns_reached_...Reported by Giorgos P.
Dec 31 07:50:01.038 [err] dns.c:399: dns_cancel_pending_resolve:
Assertion resolve->pending_connections failed; aborting.
_probably_ unrelated to other warning:
Dec 30 15:46:29.338 [warn] connection_dns_reached_eof(): Read eof.
Worker died unexpectedly.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/49AllowUnverifiedNodes string keeps growing2020-06-27T14:11:19ZTracAllowUnverifiedNodes string keeps growingWhen saving the AllowUnverifiedNodes in response to a SAVECONF control message, the old values are written out as well.
"AllowUnverifiedNodes middle,rendezvous"
becomes
"AllowUnverifiedNodes middle,rendezvous,middle,rendezvous"
and s...When saving the AllowUnverifiedNodes in response to a SAVECONF control message, the old values are written out as well.
"AllowUnverifiedNodes middle,rendezvous"
becomes
"AllowUnverifiedNodes middle,rendezvous,middle,rendezvous"
and so on...
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Aphex0.0.9.3https://gitlab.torproject.org/tpo/core/tor/-/issues/50HiddenServiceDir not being parsed correctly2020-06-27T14:11:19ZTracHiddenServiceDir not being parsed correctlyWhen sending SETCONF messages with a hidden service configured, it complains about missing HiddenServiceDir. (NOTE: Probably not reading the config in the correct order?)
rend_config_services(): HiddenServicePort with no preceding Hidde...When sending SETCONF messages with a hidden service configured, it complains about missing HiddenServiceDir. (NOTE: Probably not reading the config in the correct order?)
rend_config_services(): HiddenServicePort with no preceding HiddenServiceDir directive
handle_control_setconf(): Controller gave us config lines that didn't validate.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Aphex0.0.9.3Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/52win32 uname doesn't exist2020-06-27T14:11:19ZRoger Dingledinewin32 uname doesn't existDoes uname exist on win32? If so, we should use it. If not,
we should print something vaguely useful in the platform
string.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]Does uname exist on win32? If so, we should use it. If not,
we should print something vaguely useful in the platform
string.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]https://gitlab.torproject.org/tpo/core/tor/-/issues/17197Use CRLF for all text files written on Windows, accept either CRLF or LF on a...2020-07-09T16:34:11ZteorUse CRLF for all text files written on Windows, accept either CRLF or LF on all platformsIn legacy/trac#17501, stem becomes confused because some text files written on Windows use CRLF, and others use LF.
We could use CRLF for all text files written on Windows, and accept either CRLF or LF on all platforms.
Here is a list ...In legacy/trac#17501, stem becomes confused because some text files written on Windows use CRLF, and others use LF.
We could use CRLF for all text files written on Windows, and accept either CRLF or LF on all platforms.
Here is a list of files from DataDirectory with their line endings on Windows:
```
CRLF cached-certs
CRLF cached-consensus
LF cached-descriptors
LF cached-descriptors.new
CRLF cached-microdesc-consensus
LF cached-microdescs
LF cached-microdescs.new
CRLF state
```
We might want to review all files written by tor, including those only written by hidden services and any other components.Tor: unspecifiedAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/53please do not even publish descriptors with ip 0.0.0.02020-06-27T14:11:19Zweasel (Peter Palfrader)please do not even publish descriptors with ip 0.0.0.0Jan 05 18:53:13.386 [warn] router_resolve(): Could not resolve address for router 'ohmymyohhellyes' at 0.0.0.0
Jan 05 18:53:13.386 [warn] router_resolve_routerlist(): Couldn't resolve router 'ohmymyohhellyes' at '0.0.0.0'; not using
Whi...Jan 05 18:53:13.386 [warn] router_resolve(): Could not resolve address for router 'ohmymyohhellyes' at 0.0.0.0
Jan 05 18:53:13.386 [warn] router_resolve_routerlist(): Couldn't resolve router 'ohmymyohhellyes' at '0.0.0.0'; not using
While the directory does not accept the descriptor, I think tor shouldn't even publish it. Same goes for 127.0.0.1, which the 'foobar' router had the other day.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/40628Compilation fails on macOS Ventura2022-11-01T20:08:44ZDimitris ApostolouCompilation fails on macOS VenturaLatest main.
```
CCLD src/app/tor
ld: in libtor.a(__.SYMDEF SORTED), archive member '__.SYMDEF SORTED' with length 496 is not mach-o or llvm bitcode file 'libtor.a' for architecture x86_64
clang: error: linker command failed with ...Latest main.
```
CCLD src/app/tor
ld: in libtor.a(__.SYMDEF SORTED), archive member '__.SYMDEF SORTED' with length 496 is not mach-o or llvm bitcode file 'libtor.a' for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [src/app/tor] Error 1
make: *** [all] Error 2
```https://gitlab.torproject.org/tpo/core/tor/-/issues/57Only getting "Launched" circuit events2020-06-27T14:11:18ZTracOnly getting "Launched" circuit eventsI only receive "Launched" event messages (Event: 0x01, Status: 0x00). I have watched over 150 circuits launch but not a single other event is sent.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**:...I only receive "Launched" event messages (Event: 0x01, Status: 0x00). I have watched over 150 circuits launch but not a single other event is sent.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Aphexhttps://gitlab.torproject.org/tpo/core/tor/-/issues/58Only getting "Sent Connnect" stream events2020-06-27T14:11:18ZTracOnly getting "Sent Connnect" stream eventsThis seems related to the circuit event bug, since both these values are 0. I am betting the value isn't getting set properly. I would have merged these into one report but I just noticed it.
[Automatically added by flyspray2trac: Opera...This seems related to the circuit event bug, since both these values are 0. I am betting the value isn't getting set properly. I would have merged these into one report but I just noticed it.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Aphexhttps://gitlab.torproject.org/tpo/core/tor/-/issues/61thinks dirservers are down2020-06-27T14:11:18Zweasel (Peter Palfrader)thinks dirservers are downOn Linux amd64 with cvs as of 2005-01-13-02:45 UTC, my log reads:
Jan 13 04:17:40.925 [notice] Tor 0.1.0.0-alpha-cvs opening log file.
Jan 13 04:17:45.433 [notice] circuit_send_next_onion_skin(): Tor has successfully opened a circuit. L...On Linux amd64 with cvs as of 2005-01-13-02:45 UTC, my log reads:
Jan 13 04:17:40.925 [notice] Tor 0.1.0.0-alpha-cvs opening log file.
Jan 13 04:17:45.433 [notice] circuit_send_next_onion_skin(): Tor has successfully opened a circuit. Looks like it's working.
Jan 13 04:17:47.577 [warn] fetch_from_buf_socks(): Your application (using socks4 on port 80) is giving Tor only an IP address. Applications that do DNS resolves themselves may leak information. Consider using Socks4A (e.g. via privoxy or socat) instead.
Jan 13 04:17:49.836 [warn] fetch_from_buf_socks(): Your application (using socks4 on port 80) is giving Tor only an IP address. Applications that do DNS resolves themselves may leak information. Consider using Socks4A (e.g. via privoxy or socat) instead.
[ I think this connection just hang and never made a connect - another bug that I talked to nickm about - only happened on amd64 ]
Jan 13 06:11:03.113 [notice] conn_close_if_marked(): Conn (addr 69.211.82.25, fd 13, type Dir, state 1) is being closed, but there are still 81 bytes we can't write. (Marked at main.c:575)
Jan 13 06:11:07.115 [notice] conn_close_if_marked(): Conn (addr 68.146.56.155, fd 9, type Dir, state 1) is being closed, but there are still 82 bytes we can't write. (Marked at main.c:575)
Jan 13 06:29:10.194 [notice] conn_close_if_marked(): Conn (addr 24.27.90.61, fd 10, type Dir, state 1) is being closed, but there are still 70 bytes we can't write. (Marked at main.c:575)
Jan 13 06:30:57.173 [notice] do_hup(): Received sighup. Reloading config.
[logrotate]
Jan 13 06:30:57.178 [notice] Tor 0.1.0.0-alpha-cvs opening new log file.
Jan 13 06:51:01.488 [notice] conn_close_if_marked(): Conn (addr 207.234.129.95, fd 12, type Dir, state 1) is being closed, but there are still 73 bytes we can't write. (Marked at main.c:575)
Jan 13 07:19:40.820 [notice] circuit_send_next_onion_skin(): Tor has successfully opened a circuit. Looks like it's working.
Jan 13 07:21:01.940 [notice] conn_close_if_marked(): Conn (addr 207.234.129.95, fd 12, type Dir, state 1) is being closed, but there are still 73 bytes we can't write. (Marked at main.c:575)
Jan 13 07:46:13.137 [notice] conn_close_if_marked(): Conn (addr 203.29.157.32, fd 15, type Dir, state 1) is being closed, but there are still 82 bytes we can't write. (Marked at main.c:575)
Jan 13 07:46:26.149 [notice] conn_close_if_marked(): Conn (addr 84.245.0.22, fd 8, type Dir, state 1) is being closed, but there are still 80 bytes we can't write. (Marked at main.c:575)
Jan 13 07:59:28.775 [notice] conn_close_if_marked(): Conn (addr 24.164.242.124, fd 9, type Dir, state 1) is being closed, but there are still 73 bytes we can't write. (Marked at main.c:575)
Jan 13 08:01:18.860 [notice] conn_close_if_marked(): Conn (addr 66.148.239.42, fd 12, type Dir, state 1) is being closed, but there are still 83 bytes we can't write. (Marked at main.c:575)
Jan 13 08:11:20.343 [notice] conn_close_if_marked(): Conn (addr 207.234.129.95, fd 16, type Dir, state 1) is being closed, but there are still 83 bytes we can't write. (Marked at main.c:575)
Jan 13 08:16:08.575 [notice] conn_close_if_marked(): Conn (addr 207.234.129.95, fd 15, type Dir, state 1) is being closed, but there are still 83 bytes we can't write. (Marked at main.c:575)
Jan 13 08:26:10.111 [notice] conn_close_if_marked(): Conn (addr 195.64.88.140, fd 13, type Dir, state 1) is being closed, but there are still 82 bytes we can't write. (Marked at main.c:575)
Jan 13 08:26:34.130 [notice] conn_close_if_marked(): Conn (addr 69.211.82.25, fd 9, type Dir, state 1) is being closed, but there are still 81 bytes we can't write. (Marked at main.c:575)
Jan 13 08:36:03.572 [notice] conn_close_if_marked(): Conn (addr 24.164.242.124, fd 8, type Dir, state 1) is being closed, but there are still 83 bytes we can't write. (Marked at main.c:575)
Jan 13 08:41:11.816 [notice] conn_close_if_marked(): Conn (addr 84.245.0.22, fd 8, type Dir, state 1) is being closed, but there are still 80 bytes we can't write. (Marked at main.c:575)
Jan 13 08:51:13.299 [notice] conn_close_if_marked(): Conn (addr 24.27.90.61, fd 18, type Dir, state 1) is being closed, but there are still 80 bytes we can't write. (Marked at main.c:575)
Jan 13 08:51:15.300 [notice] conn_close_if_marked(): Conn (addr 24.27.90.61, fd 9, type Dir, state 1) is being closed, but there are still 80 bytes we can't write. (Marked at main.c:575)
Jan 13 08:51:28.311 [notice] conn_close_if_marked(): Conn (addr 24.27.90.61, fd 14, type Dir, state 1) is being closed, but there are still 80 bytes we can't write. (Marked at main.c:575)
Jan 13 09:01:08.770 [notice] conn_close_if_marked(): Conn (addr 66.245.248.94, fd 13, type Dir, state 1) is being closed, but there are still 82 bytes we can't write. (Marked at main.c:575)
Jan 13 09:01:17.777 [notice] conn_close_if_marked(): Conn (addr 207.234.129.95, fd 15, type Dir, state 1) is being closed, but there are still 83 bytes we can't write. (Marked at main.c:575)
Jan 13 09:11:43.288 [notice] conn_close_if_marked(): Conn (addr 203.29.157.32, fd 18, type Dir, state 1) is being closed, but there are still 82 bytes we can't write. (Marked at main.c:575)
Jan 13 09:16:11.500 [notice] conn_close_if_marked(): Conn (addr 66.245.248.94, fd 16, type Dir, state 1) is being closed, but there are still 82 bytes we can't write. (Marked at main.c:575)
Jan 13 09:21:34.820 [notice] conn_close_if_marked(): Conn (addr 69.211.82.25, fd 13, type Dir, state 1) is being closed, but there are still 81 bytes we can't write. (Marked at main.c:575)
Jan 13 09:26:11.042 [notice] conn_close_if_marked(): Conn (addr 66.245.248.94, fd 9, type Dir, state 1) is being closed, but there are still 82 bytes we can't write. (Marked at main.c:575)
Jan 13 09:26:35.068 [notice] conn_close_if_marked(): Conn (addr 24.164.242.124, fd 19, type Dir, state 1) is being closed, but there are still 83 bytes we can't write. (Marked at main.c:575)
Jan 13 09:31:47.315 [notice] conn_close_if_marked(): Conn (addr 85.76.91.228, fd 16, type Dir, state 1) is being closed, but there are still 81 bytes we can't write. (Marked at main.c:575)
Jan 13 09:41:49.792 [notice] conn_close_if_marked(): Conn (addr 82.161.141.173, fd 14, type Dir, state 1) is being closed, but there are still 83 bytes we can't write. (Marked at main.c:575)
Jan 13 09:46:18.000 [notice] conn_close_if_marked(): Conn (addr 24.27.90.61, fd 13, type Dir, state 1) is being closed, but there are still 80 bytes we can't write. (Marked at main.c:575)
Jan 13 09:51:25.251 [notice] conn_close_if_marked(): Conn (addr 195.64.88.140, fd 13, type Dir, state 1) is being closed, but there are still 82 bytes we can't write. (Marked at main.c:575)
Jan 13 09:56:19.487 [notice] conn_close_if_marked(): Conn (addr 207.234.129.95, fd 18, type Dir, state 1) is being closed, but there are still 83 bytes we can't write. (Marked at main.c:575)
Jan 13 10:16:12.451 [notice] conn_close_if_marked(): Conn (addr 69.211.82.25, fd 17, type Dir, state 1) is being closed, but there are still 81 bytes we can't write. (Marked at main.c:575)
Jan 13 10:16:23.461 [notice] conn_close_if_marked(): Conn (addr 84.245.0.22, fd 19, type Dir, state 1) is being closed, but there are still 80 bytes we can't write. (Marked at main.c:575)
Jan 13 10:16:30.471 [notice] conn_close_if_marked(): Conn (addr 69.211.82.25, fd 8, type Dir, state 1) is being closed, but there are still 81 bytes we can't write. (Marked at main.c:575)
Jan 13 10:21:33.892 [notice] conn_close_if_marked(): Conn (addr 193.247.38.248, fd 8, type Dir, state 1) is being closed, but there are still 78 bytes we can't write. (Marked at main.c:575)
Jan 13 10:21:46.906 [notice] conn_close_if_marked(): Conn (addr 193.247.38.248, fd 14, type Dir, state 1) is being closed, but there are still 78 bytes we can't write. (Marked at main.c:575)
Jan 13 10:26:12.124 [notice] conn_close_if_marked(): Conn (addr 193.247.38.248, fd 13, type Dir, state 1) is being closed, but there are still 78 bytes we can't write. (Marked at main.c:575)
Jan 13 10:26:14.126 [notice] conn_close_if_marked(): Conn (addr 203.29.157.32, fd 20, type Dir, state 1) is being closed, but there are still 82 bytes we can't write. (Marked at main.c:575)
Jan 13 10:26:23.133 [notice] conn_close_if_marked(): Conn (addr 203.29.157.32, fd 15, type Dir, state 1) is being closed, but there are still 82 bytes we can't write. (Marked at main.c:575)
Jan 13 10:26:25.136 [notice] conn_close_if_marked(): Conn (addr 193.247.38.248, fd 17, type Dir, state 1) is being closed, but there are still 78 bytes we can't write. (Marked at main.c:575)
Jan 13 10:26:58.161 [notice] conn_close_if_marked(): Conn (addr 203.29.157.32, fd 14, type Dir, state 1) is being closed, but there are still 82 bytes we can't write. (Marked at main.c:575)
Jan 13 10:31:04.350 [notice] conn_close_if_marked(): Conn (addr 203.29.157.32, fd 12, type Dir, state 1) is being closed, but there are still 82 bytes we can't write. (Marked at main.c:575)
Jan 13 10:31:06.352 [notice] directory_get_from_dirserver(): No running dirservers known. Not trying. (purpose 1)
Jan 13 10:31:11.356 [notice] conn_close_if_marked(): Conn (addr 203.29.157.32, fd 18, type Dir, state 1) is being closed, but there are still 82 bytes we can't write. (Marked at main.c:575)
Jan 13 10:31:11.356 [notice] directory_get_from_dirserver(): No running dirservers known. Not trying. (purpose 2)
Jan 13 10:31:13.357 [notice] conn_close_if_marked(): Conn (addr 203.29.157.32, fd 16, type Dir, state 1) is being closed, but there are still 82 bytes we can't write. (Marked at main.c:575)
Jan 13 10:31:13.357 [notice] directory_get_from_dirserver(): No running dirservers known. Not trying. (purpose 2)
Jan 13 10:31:15.359 [notice] directory_get_from_dirserver(): No running dirservers known. Not trying. (purpose 2)
Jan 13 10:31:24.366 [notice] directory_get_from_dirserver(): No running dirservers known. Not trying. (purpose 2)
Jan 13 10:31:26.367 [notice] directory_get_from_dirserver(): No running dirservers known. Not trying. (purpose 2)
Jan 13 10:31:33.373 [notice] directory_get_from_dirserver(): No running dirservers known. Not trying. (purpose 2)
Jan 13 10:31:35.374 [notice] directory_get_from_dirserver(): No running dirservers known. Not trying. (purpose 2)
Jan 13 10:31:48.384 [notice] directory_get_from_dirserver(): No running dirservers known. Not trying. (purpose 2)
Jan 13 10:31:59.393 [notice] directory_get_from_dirserver(): No running dirservers known. Not trying. (purpose 2)
Jan 13 10:36:05.586 [notice] directory_get_from_dirserver(): No running dirservers known. Not trying. (purpose 2)
Jan 13 10:56:07.538 [notice] directory_get_from_dirserver(): No running dirservers known. Not trying. (purpose 2)
Jan 13 11:01:06.774 [notice] directory_get_from_dirserver(): No running dirservers known. Not trying. (purpose 2)
Jan 13 11:26:06.965 [notice] directory_get_from_dirserver(): No running dirservers known. Not trying. (purpose 1)
Jan 13 11:31:05.198 [notice] directory_get_from_dirserver(): No running dirservers known. Not trying. (purpose 2)
Jan 13 11:56:08.397 [notice] directory_get_from_dirserver(): No running dirservers known. Not trying. (purpose 2)
Jan 13 12:01:07.638 [notice] directory_get_from_dirserver(): No running dirservers known. Not trying. (purpose 2)
Jan 13 12:26:07.045 [notice] directory_get_from_dirserver(): No running dirservers known. Not trying. (purpose 1)
Jan 13 12:29:30.430 [err] Catching signal TERM, exiting cleanly.
[Automatically added by flyspray2trac: Operating System: Other Linux]https://gitlab.torproject.org/tpo/core/tor/-/issues/62connect attempt just hangs2020-06-27T14:11:18Zweasel (Peter Palfrader)connect attempt just hangscvs as of 2005-01-13-11:25 utc, on amd64 I notice the following: (I couldn't reproduce that on i386)
torify telnet seppia.noreply.org 80 works the first, and sometimes
the second time, but it never works the 3rd time.
debug log will ...cvs as of 2005-01-13-11:25 utc, on amd64 I notice the following: (I couldn't reproduce that on i386)
torify telnet seppia.noreply.org 80 works the first, and sometimes
the second time, but it never works the 3rd time.
debug log will be attached
[Automatically added by flyspray2trac: Operating System: Other Linux]https://gitlab.torproject.org/tpo/core/tor/-/issues/63Tor0.0.9.2bug (with firewall ZoneAlarm)2020-06-27T14:11:18ZTracTor0.0.9.2bug (with firewall ZoneAlarm)My computer runs windows 2000 sp4 and firewall ZoneAlarm. I installed Tor 0.0.9.2 and Privoxy. The installation is well
done. But run Tor is bad. Firewall always shutdown and My computer also need boot again.
I uninstalled Tor 0.0.9.2 an...My computer runs windows 2000 sp4 and firewall ZoneAlarm. I installed Tor 0.0.9.2 and Privoxy. The installation is well
done. But run Tor is bad. Firewall always shutdown and My computer also need boot again.
I uninstalled Tor 0.0.9.2 and reinstalled Tor 0.0.9.1 and things go well. So I run Tor 0.0.9.1 version.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: mtorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/64if the network is started after tor, tor cannot/does not connect2020-06-27T14:11:18ZTracif the network is started after tor, tor cannot/does not connectOn my laptop or desktop machine tor is started by the init.d scripts at booting. Sometimes those machines do not have network at this time (for example my laptop).
When I connect the computer to the internet, i have to restart TOR, or i...On my laptop or desktop machine tor is started by the init.d scripts at booting. Sometimes those machines do not have network at this time (for example my laptop).
When I connect the computer to the internet, i have to restart TOR, or its not working.
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: squathttps://gitlab.torproject.org/tpo/core/tor/-/issues/65Mirroring dir via apache introduces unrecognized x-compress header2020-06-27T14:11:18ZRoger DingledineMirroring dir via apache introduces unrecognized x-compress headerJan 15 16:18:42.480 [warn] parse_http_response(): Unrecognized content encoding: 'x-compress'
Jan 15 16:18:42.480 [warn] router_get_hash_impl(): couldn't find "signed-directory"
Jan 15 16:18:42.480 [warn] router_parse_routerlist_from_dir...Jan 15 16:18:42.480 [warn] parse_http_response(): Unrecognized content encoding: 'x-compress'
Jan 15 16:18:42.480 [warn] router_get_hash_impl(): couldn't find "signed-directory"
Jan 15 16:18:42.480 [warn] router_parse_routerlist_from_directory(): Unable to compute digest of directory
Jan 15 16:18:42.480 [warn] router_load_routerlist_from_directory(): Couldn't parse directory.
Jan 15 16:18:42.480 [warn] connection_dir_client_reached_eof(): I failed to parse the directory I fetched from 62.116.124.106:80. Ignoring.
Is this as simple as teaching Tor about x-compress?
Is there a workaround whereby we can get people to rig their apaches
to use x-deflate or x-gzip (that is, let the headers through from the
proxied connection) despite apache's default?
[Automatically added by flyspray2trac: Operating System: All]0.0.9.3https://gitlab.torproject.org/tpo/core/tor/-/issues/67We need to pass a string back along with the http status codes2020-06-27T14:11:17ZRoger DingledineWe need to pass a string back along with the http status codesThe dirserver gives back a status code (e.g. 403) plus a string. We need to make that string
configurable based on what the error/status actually is, and have the client parse out the
string.
Currently, there's no distinction between "y...The dirserver gives back a status code (e.g. 403) plus a string. We need to make that string
configurable based on what the error/status actually is, and have the client parse out the
string.
Currently, there's no distinction between "you're an unverified server" and "your clock is
extremely wrong". So people don't know there's anything to fix.
In addition, since we *do* accept unverified servers now, we should be giving back a "200 unverified server accepted" rather than a 403.
[Automatically added by flyspray2trac: Operating System: All]0.1.0.1-rcNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/68Tor complains about missing epoll2020-06-27T14:11:17ZRoger DingledineTor complains about missing epollIt prints out
"tor: epoll_create: Function not implemented"
every time I start
on Red Hat FC1
Would it make sense to auto-detect better and/or disable epoll?
This will generate an unending stream of bug reports, as is.
[Automatically a...It prints out
"tor: epoll_create: Function not implemented"
every time I start
on Red Hat FC1
Would it make sense to auto-detect better and/or disable epoll?
This will generate an unending stream of bug reports, as is.
[Automatically added by flyspray2trac: Operating System: Other Linux]0.1.0.1-rcNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40596Bug: Non-fatal assertion failed in process_win32_read_from_handle2022-11-01T13:16:09ZcypherpunksBug: Non-fatal assertion failed in process_win32_read_from_handleOn win32, latest Tor 0.4.6.10
when starting with torrc consisting of:
<code>ClientTransportPlugin trebuchet exec /path/to/snowflake-client.exe
Bridge trebuchet 127.0.0.1:123</code>
Logs the following:
```
Jan 1 00:00:00.000 [notice] B...On win32, latest Tor 0.4.6.10
when starting with torrc consisting of:
<code>ClientTransportPlugin trebuchet exec /path/to/snowflake-client.exe
Bridge trebuchet 127.0.0.1:123</code>
Logs the following:
```
Jan 1 00:00:00.000 [notice] Bootstrapped 0% (starting): Starting
Jan 1 00:00:00.000 [notice] Starting with guard context "default"
Jan 1 00:00:00.000 [warn] Client managed proxy encountered a method error. (trebuchet no such method)
Jan 1 00:00:00.000 [warn] Managed proxy at '/path/to/snowflake-client.exe' failed the configuration protocol and will be destroyed.
Jan 1 00:00:00.000 [warn] tor_bug_occurred_(): Bug: process_win32.c:891: process_win32_read_from_handle: Non-fatal assertion !(handle->reached_eof) failed. (on Tor 0.4.6.10 22fd351cf582aa2b)
Jan 1 00:00:00.000 [warn] Bug: Tor 0.4.6.10 (git-22fd351cf582aa2b): Non-fatal assertion !(handle->reached_eof) failed in process_win32_read_from_handle at process_win32.c:891. (Stack trace not available) (on Tor 0.4.6.10 22fd351cf582aa2b)
Jan 1 00:00:00.000 [warn] Pluggable Transport process terminated with status code 0
Jan 1 00:00:00.000 [notice] Bootstrapped 5% (conn): Connecting to a relay
```
Interestingly, bug doesn't happen if I put obfs4proxy instead of snowflake-client, so something additional triggers it in Snowflake (version from latest TBB). But I think tor mustn't log Bug's no matter how broken PT is.Alexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/72Open LDAP and LDAPS ports in the default policy2020-06-27T14:11:17ZshamrockOpen LDAP and LDAPS ports in the default policyTor currently does not proxy the LDAP (389/tcp) and LDAPS (636/tcp) ports.
Feature Request: proxy the LDAP and LDAPS ports.
Background:
LDAP(S) is the standard protocol to obtain recipients' cryptographic keys on the Internet. Any enti...Tor currently does not proxy the LDAP (389/tcp) and LDAPS (636/tcp) ports.
Feature Request: proxy the LDAP and LDAPS ports.
Background:
LDAP(S) is the standard protocol to obtain recipients' cryptographic keys on the Internet. Any entity making an LDAP server available to the public does so to permit public dissemination of their users' directory information. The abuse potential of permitting these ports to be proxied is negligible, no higher than the abuse potential of permitting the proxying of http and inarguably lower than permitting the proxying of other ports already available via tor, such as ssh or IRC.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/73Issues with Tor server and XP SP22020-06-27T14:11:17ZTracIssues with Tor server and XP SP2Operating System(s)
Windows System : Microsoft Windows XP/2002 Professional (Win32 x86)
5.01.2600 (Service Pack 2)
Model : AMD Athlon(tm) XP 2400+
Speed : 2.00GHz
Model Number : 2400 (estimated)
Performance Rating : PR2904 (estimated)
Ty...Operating System(s)
Windows System : Microsoft Windows XP/2002 Professional (Win32 x86)
5.01.2600 (Service Pack 2)
Model : AMD Athlon(tm) XP 2400+
Speed : 2.00GHz
Model Number : 2400 (estimated)
Performance Rating : PR2904 (estimated)
Type : Standard
L2 On-board Cache : 256kB ECC Synchronous Write-Back (16-way, 64 byte line size)
Mainboard
Bus(es) : AGP PCI USB FireWire/1394 i2c/SMBus
MP Support : No
MP APIC : No
System BIOS : Phoenix Technologies, LTD ASUS A7N8X2.0 Deluxe ACPI
BIOS Rev 1008
Mainboard : ASUSTeK Computer INC. A7N8X2.0
Total Memory : 1023MB
Chipset 1
Model : ASUSTeK Computer Inc nForce2 AGP Controller
Front Side Bus Speed : 2x 134MHz (268MHz data rate)
Problem:
Everything is going fine.
All of a sudden upload and download go to 0.
Cannot open any programs.
Any browser windows that are open and connecting will
never connect.
Programs that are already running will
minimize/restore/exit and work to some degree.
Sometimes everything will start working after 2 to 10
minutes.
Longer than that i reset the computer.
Seems to get stuck at one certain spot and very little
else can happen until it gets past that point.
Even the task manager will not open with ctrl alt delete.
It seems to occur when it is trying to establish a connection of some type and can't establish it.
My intuition tells me it is conflicting with one of the XP services but I cannot verify that.
Logs available upon request.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: ZincoAndrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40520module thinko in src/lib/crypt_ops/crypto_rand.c2022-07-07T00:47:11Ztoralfmodule thinko in src/lib/crypt_ops/crypto_rand.c### Summary
I do wonder if
- "modulo 5" should be "modulo 8"
- the bits -> bytes calculation have to made afterwards
- the goal is to calculate the amount of bytes needed for N base32 characters then even the "+7" is wrong
```patch
ind...### Summary
I do wonder if
- "modulo 5" should be "modulo 8"
- the bits -> bytes calculation have to made afterwards
- the goal is to calculate the amount of bytes needed for N base32 characters then even the "+7" is wrong
```patch
index 5bf3a65b3b..90a755537c 100644
--- a/src/lib/crypt_ops/crypto_rand.c
+++ b/src/lib/crypt_ops/crypto_rand.c
@@ -568,9 +568,10 @@ crypto_random_hostname(int min_rand_len, int max_rand_len, const char *prefix,
prefixlen = strlen(prefix);
resultlen = prefixlen + strlen(suffix) + randlen + 16;
- rand_bytes_len = ((randlen*5)+7)/8;
- if (rand_bytes_len % 5)
- rand_bytes_len += 5 - (rand_bytes_len%5);
+ rand_bytes_len = randlen*5;
+ if (rand_bytes_len % 8)
+ rand_bytes_len += 8 - (rand_bytes_len%8);
+ rand_bytes_len /= 8;
rand_bytes = tor_malloc(rand_bytes_len);
crypto_rand(rand_bytes, rand_bytes_len);
```
Or?Tor: 0.4.7.x-stablehttps://gitlab.torproject.org/tpo/core/tor/-/issues/74Servers bloat memory from spawned children2020-06-27T14:11:17ZRoger DingledineServers bloat memory from spawned childrenWhen we fork, our children inherit the memory from the main Tor
process, which can be 50MB or more. Since it's copy-on-write, no
problem so far. But when the main Tor process changes the memory,
or frees it, then it gets copied so the ch...When we fork, our children inherit the memory from the main Tor
process, which can be 50MB or more. Since it's copy-on-write, no
problem so far. But when the main Tor process changes the memory,
or frees it, then it gets copied so the child has a clean copy.
So we end up using 50+MB per child. When we spawn a lot of dnsworkers,
this becomes really bad.
[Automatically added by flyspray2trac: Operating System: All]0.1.0.1-rchttps://gitlab.torproject.org/tpo/core/tor/-/issues/76don't ask unverified nodes for a directory2020-06-27T14:11:17ZRoger Dingledinedon't ask unverified nodes for a directoryUnverified nodes sometimes have really weird bandwidth shaping, and they also sometimes have
really wrong clocks. So asking them for a directory is just asking for trouble, and there are
enough other mirrors that we should be ok.
[Autom...Unverified nodes sometimes have really weird bandwidth shaping, and they also sometimes have
really wrong clocks. So asking them for a directory is just asking for trouble, and there are
enough other mirrors that we should be ok.
[Automatically added by flyspray2trac: Operating System: All]0.1.0.1-rchttps://gitlab.torproject.org/tpo/core/tor/-/issues/77clients are believing really old recommended-versions2020-06-27T14:11:16ZRoger Dingledineclients are believing really old recommended-versionsClients believe recommended-versions no matter how old the directory is.
Option one: don't check recommended-versions if massive clock skew is detected on the dir.
Option two: remember the timestamp of the last recommended-versions you...Clients believe recommended-versions no matter how old the directory is.
Option one: don't check recommended-versions if massive clock skew is detected on the dir.
Option two: remember the timestamp of the last recommended-versions you saw, and discard
newly received ones that are older than it.
Option three: both.
[Automatically added by flyspray2trac: Operating System: All]0.1.0.1-rchttps://gitlab.torproject.org/tpo/core/tor/-/issues/79clients pick you as an exit node if there's even a chance you can exit there2020-06-27T14:11:16ZRoger Dingledineclients pick you as an exit node if there's even a chance you can exit thereWhen clients don't know the IP of foobarbaz.com:80, they pick a random exit node that
will allow *any* exits to port 80. But if they pick a node that allows w.x.y.z:80
and then rejects *:80, they are almost certain to be told "here's the...When clients don't know the IP of foobarbaz.com:80, they pick a random exit node that
will allow *any* exits to port 80. But if they pick a node that allows w.x.y.z:80
and then rejects *:80, they are almost certain to be told "here's the IP, now go somewhere
else." We should short-circuit this process and only pick exit nodes that accept "most"
IPs for the port in question.
[Automatically added by flyspray2trac: Operating System: All]0.0.9.5Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/80Max dir size is 500 kilobytes2020-06-27T14:11:16ZRoger DingledineMax dir size is 500 kilobytesCurrently the max dir size, both receiving the http request from the client and providing
the http answer to the client, is 500kB. If something we try to send exceeds this, the http
attempt will fail.
Should we just keep raising this li...Currently the max dir size, both receiving the http request from the client and providing
the http answer to the client, is 500kB. If something we try to send exceeds this, the http
attempt will fail.
Should we just keep raising this limit as the directory size grows, or is there some better
solution?
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/81streams end badly when server runs out of fd's2020-06-27T14:11:16ZRoger Dingledinestreams end badly when server runs out of fd'sWe need to put better reasons on stream end cells, so when a server is unwilling to make any
more exits streams, the client doesn't end up with a failed stream -- he should treat it like
a dns resolve failure and try somewhere else.
[Au...We need to put better reasons on stream end cells, so when a server is unwilling to make any
more exits streams, the client doesn't end up with a failed stream -- he should treat it like
a dns resolve failure and try somewhere else.
[Automatically added by flyspray2trac: Operating System: All]Roger DingledineRoger Dingledinehttps://gitlab.torproject.org/tpo/core/tor/-/issues/82tor opens too many file descriptors2020-06-27T14:11:16Zgoodelltor opens too many file descriptorsFor those of us with systems with high-bandwidth connections, running a
Tor router causes the Tor process to open many file descriptors. So
many, in fact, that Tor routinely runs into the ceiling specified by
ulimit -n. Thus, either (a...For those of us with systems with high-bandwidth connections, running a
Tor router causes the Tor process to open many file descriptors. So
many, in fact, that Tor routinely runs into the ceiling specified by
ulimit -n. Thus, either (a) the init script included with the tor
package should manually set a large value for ulimit -n, or (b) Tor
itself should somehow set its own ulimit to be large, perhaps based upon
a configuration parameter.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/83show which dirserver said we have a skewed clock/are unverified2020-06-27T14:11:16Zweasel (Peter Palfrader)show which dirserver said we have a skewed clock/are unverifiedIn
Jan 30 00:39:44.266 [warn] connection_dir_client_reached_eof(): http
status 403 (unapproved server) response from dirserver. Is your clock
skewed? Have you mailed us your identity fingerprint? Are you using the
right key? Are you usi...In
Jan 30 00:39:44.266 [warn] connection_dir_client_reached_eof(): http
status 403 (unapproved server) response from dirserver. Is your clock
skewed? Have you mailed us your identity fingerprint? Are you using the
right key? Are you using a private IP address? See
http://tor.eff.org/doc/tor-doc.html#server.
it would be nice if tor said which dirserver said we are unverified/have a skewed clock.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/84we should handle the case where the client has no cert2020-06-27T14:11:16ZRoger Dingledinewe should handle the case where the client has no certCurrent cvs refuses connections from clients that don't have a cert chain. We ought to handle
clients that don't have one, just to be more generally compatible, and to deal with JAP
clients that apparently don't provide them.
[Automatic...Current cvs refuses connections from clients that don't have a cert chain. We ought to handle
clients that don't have one, just to be more generally compatible, and to deal with JAP
clients that apparently don't provide them.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/85Doc/Installer mismatch on MacOS X2020-06-27T14:11:16ZTracDoc/Installer mismatch on MacOS XThe website documents that you need to click "install TOR startup script," but its pre-selected in latest builds.
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]
**Trac**:
**Username**: adam667The website documents that you need to click "install TOR startup script," but its pre-selected in latest builds.
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]
**Trac**:
**Username**: adam667https://gitlab.torproject.org/tpo/core/tor/-/issues/86No logs in default mac package2020-06-27T14:11:15ZTracNo logs in default mac packageI installed the new mac package, and it doesn't log at all.
I suppose there may be a security argument for this, but it makes it hard to figure out what's going wrong.
[Automatically added by flyspray2trac: Operating System: OSX 10.4 ...I installed the new mac package, and it doesn't log at all.
I suppose there may be a security argument for this, but it makes it hard to figure out what's going wrong.
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]
**Trac**:
**Username**: adam667Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/87Our clock skew allowances differ, leading to problems2020-06-27T14:11:15ZRoger DingledineOur clock skew allowances differ, leading to problemsdirserv_set_cached_directory(): Ignoring future directory; not caching.
This happens, causing dir mirrors to not have anything to give out, if they're more than
ROUTER_ALLOW_SKEW (30 minutes) in the past.
Yet they need to be ROUTER_MAX...dirserv_set_cached_directory(): Ignoring future directory; not caching.
This happens, causing dir mirrors to not have anything to give out, if they're more than
ROUTER_ALLOW_SKEW (30 minutes) in the past.
Yet they need to be ROUTER_MAX_AGE (24 hours) in the past before we flag any warnings
about their time skew.
[Automatically added by flyspray2trac: Operating System: All]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/88please free all memory before shutting down2020-06-27T14:11:15Zweasel (Peter Palfrader)please free all memory before shutting downI've been playing with dmalloc, a library that checks for leaks (and other stuff).
It's a lot lighter than for instance valgrind, but unfortunately Tor does not
play very nice with it.
It would be great if you could clean up all the mem...I've been playing with dmalloc, a library that checks for leaks (and other stuff).
It's a lot lighter than for instance valgrind, but unfortunately Tor does not
play very nice with it.
It would be great if you could clean up all the memory you think you are using
before shutdown, so that tools like dmalloc can tell you what you missed.
For instance now dmalloc gives me
1107411810: 73044: total-size count source
1107411810: 73044: 81920 5 buffers.c:37
1107411810: 73044: 65360 1634 routerparse.c:1066
1107411810: 73044: 36864 9 buffers.c:112
1107411810: 73044: 31234 1634 routerparse.c:1068
1107411810: 73044: 17568 122 routerparse.c:804
1107411810: 73044: 6528 24 aes.c:74
1107411810: 73044: 6454 1 dirserv.c:789
1107411810: 73044: 6452 1 torgzip.c:111
1107411810: 73044: 6144 24 container.c:45
1107411810: 73044: 4800 122 routerparse.c:908
1107411810: 73044: 3920 245 crypto.c:177
...
after I shutdown tor. This isn't very useful yet, but it could be :)
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/89patch to optionally build tor with dmalloc2020-06-27T14:11:15Zweasel (Peter Palfrader)patch to optionally build tor with dmallocThis patch against current cvs adds a --with-dmalloc configure
option to build tor against the dmalloc library.
[Automatically added by flyspray2trac: Operating System: All]This patch against current cvs adds a --with-dmalloc configure
option to build tor against the dmalloc library.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/91please shutdown immediately when we're hibernating2020-06-27T14:11:15Zweasel (Peter Palfrader)please shutdown immediately when we're hibernatingOn SIGINT tor waits for 30 seconds to shutdown. Even when it's hibernating and there
are no current connections through it.
Perhaps make it shutdown in this state immediately?
[Automatically added by flyspray2trac: Operating System: All]On SIGINT tor waits for 30 seconds to shutdown. Even when it's hibernating and there
are no current connections through it.
Perhaps make it shutdown in this state immediately?
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/93hidden services complain persistently about non-availability of nodes2020-06-27T14:11:14Zweasel (Peter Palfrader)hidden services complain persistently about non-availability of nodesTor continues to complain about not finding nodes to introduction points. It complained once ever second since it was started.
Feb 04 16:05:44.711 [warn] router_choose_random_node(): No available nodes when trying to choose node. Faili...Tor continues to complain about not finding nodes to introduction points. It complained once ever second since it was started.
Feb 04 16:05:44.711 [warn] router_choose_random_node(): No available nodes when trying to choose node. Failing.
Feb 04 16:05:44.711 [warn] rend_services_introduce(): Could only establish 0 introduction points for FOO
Feb 04 16:05:44.711 [warn] router_choose_random_node(): No available nodes when trying to choose node. Failing.
Feb 04 16:05:45.752 [warn] rend_services_introduce(): Could only establish 0 introduction points for FOO
Feb 04 16:05:45.752 [warn] router_choose_random_node(): No available nodes when trying to choose node. Failing.
Feb 04 16:05:46.776 [warn] rend_services_introduce(): Could only establish 0 introduction points for FOO
Feb 04 16:05:46.776 [warn] router_choose_random_node(): No available nodes when trying to choose node. Failing.
Feb 04 16:05:47.793 [warn] rend_services_introduce(): Could only establish 0 introduction points for FOO
Feb 04 16:05:47.793 [warn] router_choose_random_node(): No available nodes when trying to choose node. Failing.
Feb 04 16:05:48.842 [warn] rend_services_introduce(): Could only establish 0 introduction points for FOO
Feb 04 16:05:48.842 [warn] router_choose_random_node(): No available nodes when trying to choose node. Failing.
Feb 04 16:05:49.913 [warn] rend_services_introduce(): Could only establish 0 introduction points for FOO
Feb 04 16:05:49.913 [warn] router_choose_random_node(): No available nodes when trying to choose node. Failing.
...
CVS Snapshot 2005-02-04 00:13 UTC
[Automatically added by flyspray2trac: Operating System: All]Roger DingledineRoger Dingledinehttps://gitlab.torproject.org/tpo/core/tor/-/issues/96assert_cpath_layer_ok2020-06-27T14:11:14ZTracassert_cpath_layer_okanother crash. perhaps it only shows when the network is really
jammed and there are many *very* slow jap connections pending.
[log]
Feb 06 16:11:29.003 [notice] connection_ap_expire_beginning(): Stream is 15 seconds late on address
...another crash. perhaps it only shows when the network is really
jammed and there are many *very* slow jap connections pending.
[log]
Feb 06 16:11:29.003 [notice] connection_ap_expire_beginning(): Stream is 15 seconds late on address
'70.58.141.252'. Retrying.
Feb 06 16:11:29.004 [notice] circuit_log_path(): circ (length 3, exit countach): rodos(open) anorien
(open) countach(open)
Feb 06 16:11:31.002 [notice] connection_ap_expire_beginning(): Stream is 15 seconds late on address
'80.177.13.198'. Retrying.
Feb 06 16:11:31.002 [notice] circuit_log_path(): circ (length 3, exit countach): rodos(open) anorien
(open) countach(open)
Feb 06 16:11:31.004 [notice] connection_ap_expire_beginning(): Stream is 15 seconds late on address
'80.177.13.198'. Retrying.
Feb 06 16:11:31.004 [notice] circuit_log_path(): circ (length 3, exit countach): rodos(open) anorien
(open) countach(open)
Feb 06 16:11:36.581 [err] circuitlist.c:419: assert_cpath_layer_ok: Assertion !cp->handshake_state failed; aborting.
(a few days ago it crashed close to that place with the following log:)
Feb 04 15:56:41.397 [err] assert_cpath_layer_ok(): Unexpected state 191
Feb 04 15:56:41.397 [err] circuitlist.c:426: assert_cpath_layer_ok: Assertion 0 failed; aborting.
[backtrace]
#0 0x40148741 in kill () from /lib/libc.so.6
#1 0x401484c5 in raise () from /lib/libc.so.6
legacy/trac#2 0x40149a08 in abort () from /lib/libc.so.6
legacy/trac#3 0x08051efa in assert_cpath_layer_ok (cp=0x86a4150) at circuitlist.c:419
legacy/trac#4 0x0805ca01 in assert_connection_ok (conn=0x8582ac0, now=1107702696) at connection.c:1484
legacy/trac#5 0x0806cd74 in conn_close_if_marked (i=45) at main.c:332
legacy/trac#6 0x0806dc8c in do_main_loop () at main.c:926
legacy/trac#7 0x0806e535 in tor_main (argc=1, argv=0xbffffe34) at main.c:1426
legacy/trac#8 0x0807e4f4 in main (argc=1, argv=0xbffffe34) at tor_main.c:18
[system description]
i am using the 0.0.9.4 debian package, i am running a pretty old x86
pc and have a jap mix running on the same box which connects to
apache/mod_proxy, which in turn connects to tor.
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: fisNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/97connection_dns_remove: Assertion failed2020-06-27T14:11:14Zgoodellconnection_dns_remove: Assertion failedon serifos, 0.0.9.4 (i386_linux24)
[log]
Feb 06 17:32:31.448 [warn] connection_edge_end(): Bug: Calling connection_edge_end on an already ended stream?
Feb 06 17:35:21.528 [warn] connection_edge_end(): Bug: Calling connection_edge_end o...on serifos, 0.0.9.4 (i386_linux24)
[log]
Feb 06 17:32:31.448 [warn] connection_edge_end(): Bug: Calling connection_edge_end on an already ended stream?
Feb 06 17:35:21.528 [warn] connection_edge_end(): Bug: Calling connection_edge_end on an already ended stream?
Feb 06 17:38:50.007 [notice] connection_expire_held_open(): Giving up on marked_for_close conn that's been flushing for 15s (fd 110, type Exit, state 3).
Feb 06 17:38:50.008 [notice] conn_close_if_marked(): Conn (addr 217.175.190.49, fd 110, type Exit, state 3) is being closed, but there are still 5486 bytes we can't write. (Marked at connection_edge.c:112)
Feb 06 17:39:27.677 [err] dns.c:319: connection_dns_remove: Assertion conn->state == EXIT_CONN_STATE_RESOLVING failed; aborting.
[backtrace]
#0 0x4014a741 in kill () from /lib/libc.so.6
#1 0x4014a4c5 in raise () from /lib/libc.so.6
legacy/trac#2 0x4014ba08 in abort () from /lib/libc.so.6
legacy/trac#3 0x08068f13 in connection_dns_remove (conn=0x8213bb0) at dns.c:319
legacy/trac#4 0x08051c97 in _circuit_mark_for_close (circ=0x81dc0b0) at circuitlist.c:386
legacy/trac#5 0x080554cc in command_process_destroy_cell (cell=0xbffff428, conn=0x89ab760) at command.c:309
legacy/trac#6 0x08054eb4 in command_process_cell (cell=0xbffff428, conn=0x89ab760) at command.c:137
legacy/trac#7 0x08061712 in connection_or_process_cells_from_inbuf (conn=0x89ab760) at connection_or.c:502
legacy/trac#8 0x080606f0 in connection_or_process_inbuf (conn=0x89ab760) at connection_or.c:62
legacy/trac#9 0x0805bcac in connection_process_inbuf (conn=0x89ab760, package_partial=1) at connection.c:1313
legacy/trac#10 0x0805aec5 in connection_handle_read (conn=0x89ab760) at connection.c:876
legacy/trac#11 0x0806cb04 in conn_read (i=193) at main.c:265
legacy/trac#12 0x0806dc19 in do_main_loop () at main.c:918
legacy/trac#13 0x0806e505 in tor_main (argc=1, argv=0xbffff984) at main.c:1426
legacy/trac#14 0x0807e4c4 in main (argc=1, argv=0xbffff984) at tor_main.c:18
(gdb) up 3
(gdb) print *conn
$1 = {magic = 2084319310, type = 5 '\005', state = 4 '\004', purpose = 2 '\002',
wants_to_read = 0 '\0', wants_to_write = 0 '\0', s = -1, poll_index = -1, marked_for_close = 0,
marked_for_close_file = 0x0, hold_open_until_flushed = 0, inbuf = 0x824ea08, inbuf_reached_eof = 0,
timestamp_lastread = 1107729523, outbuf = 0x82a7a10, outbuf_flushlen = 0,
timestamp_lastwritten = 1107729523, timestamp_created = 1107729523, addr = 2362680835, port = 0,
address = 0x84544f8 "irc.freenode.net", identity_pkey = 0x0,
identity_digest = '\0' <repeats 19 times>, nickname = 0x0, chosen_exit_name = 0x0, tls = 0x0,
next_circ_id = 13487, bandwidth = 0, receiver_bucket = 0, circ_id_type = CIRC_ID_TYPE_LOWER,
rend_query = '\0' <repeats 16 times>, stream_size = 0, stream_id = 17615, next_stream = 0x0,
cpath_layer = 0x0, package_window = 0, deliver_window = 0, done_sending = 0, done_receiving = 0,
has_sent_end = 0 '\0', socks_request = 0x0, event_mask = 0}
[Automatically added by flyspray2trac: Operating System: All]0.0.9.5Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/98WSAENOBUFS: Running out of buffer space on Windows2020-06-27T14:11:14ZTracWSAENOBUFS: Running out of buffer space on Windows```
Feb 06 02:47:39.469 [err] do_main_loop(): poll failed: No buffer space available [WSAENOBUFS ] [10055]
Feb 06 12:51:31.380 [err] do_main_loop(): poll failed: No buffer space available [WSAENOBUFS ] [10055]
Feb 06 14:25:25.031 [err]...```
Feb 06 02:47:39.469 [err] do_main_loop(): poll failed: No buffer space available [WSAENOBUFS ] [10055]
Feb 06 12:51:31.380 [err] do_main_loop(): poll failed: No buffer space available [WSAENOBUFS ] [10055]
Feb 06 14:25:25.031 [err] do_main_loop(): poll failed: No buffer space available [WSAENOBUFS ] [10055]
Feb 07 02:15:17.138 [err] do_main_loop(): poll failed: No buffer space available [WSAENOBUFS ] [10055]
```
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: spy1Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/100installation problem2020-06-27T14:11:14ZTracinstallation problemHi,
I can´t get tor to install on an intel box running SuSE 9.1.
I am using tor-0.0.9.4.tar.gz. I do tar xzf tor-0.0.9.4.tar.gz,
then cd into the new directory, then do ./configure, which runs fine.
When I try to make, I get lots of ...Hi,
I can´t get tor to install on an intel box running SuSE 9.1.
I am using tor-0.0.9.4.tar.gz. I do tar xzf tor-0.0.9.4.tar.gz,
then cd into the new directory, then do ./configure, which runs fine.
When I try to make, I get lots of errors complaining about torgzip.c,
The output looks like this:
cc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/ssl/include -g -O2 -Wall -g -O2 -c log.c
gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/ssl/include -g -O2 -Wall -g -O2 -c fakepoll.c
gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/ssl/include -g -O2 -Wall -g -O2 -c util.c
gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/ssl/include -g -O2 -Wall -g -O2 -c compat.c
gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/ssl/include -g -O2 -Wall -g -O2 -c container.c
rm -f libor.a
ar cru libor.a log.o fakepoll.o util.o compat.o container.o
ranlib libor.a
gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/ssl/include -g -O2 -Wall -g -O2 -c crypto.c
gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/ssl/include -g -O2 -Wall -g -O2 -c aes.c
gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/ssl/include -g -O2 -Wall -g -O2 -c tortls.c
gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/local/ssl/include -g -O2 -Wall -g -O2 -c torgzip.c
torgzip.c:20:18: zlib.h: Datei oder Verzeichnis nicht gefunden
torgzip.c: In Funktion »is_gzip_supported«:
torgzip.c:35: error: `ZLIB_VERSION' undeclared (first use in this function)
torgzip.c:35: error: (Each undeclared identifier is reported only once
torgzip.c:35: error: for each function it appears in.)
(much more to follow)
zlib is installed:
# rpm -qa|grep zlib
zlib-1.2.1-70.6
I was able to install an old version of tor (tor-0.0.8.1.tar.gz), but when I
run it, it complains like this;
Feb 12 18:52:13.988 [err] You are running Tor version 0.0.8.1, which will not work with this network.
Is there a way to run and install tor for me?
Thanks for any help
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: thunderhttps://gitlab.torproject.org/tpo/core/tor/-/issues/101default tor installation does not work over wifi2020-06-27T14:11:14ZTracdefault tor installation does not work over wifii'm running mac os 10.3. and have my powerbook connected over an apple airport extreme basestation.
the default tor installation only gives me privoxy 503 errors - this might be a privoxy issue, i will report the issue there as well.
the...i'm running mac os 10.3. and have my powerbook connected over an apple airport extreme basestation.
the default tor installation only gives me privoxy 503 errors - this might be a privoxy issue, i will report the issue there as well.
the same tor installation however, works perfectly when i connect the powerbook over ehternet - it's when using wifi that i only 503's.
thanks
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]
**Trac**:
**Username**: renehttps://gitlab.torproject.org/tpo/core/tor/-/issues/102CVS current crashes immediately on launch2020-06-27T14:11:14ZTracCVS current crashes immediately on launchStarting 2/23/2005, about 8PM EST, my CVS current builds are crashing upon launch. I have been anxiously awaiting CVS updates and have seen new code updates, but each new build crashes with the same message:
Feb 23 20:07:06.299 [notice...Starting 2/23/2005, about 8PM EST, my CVS current builds are crashing upon launch. I have been anxiously awaiting CVS updates and have seen new code updates, but each new build crashes with the same message:
Feb 23 20:07:06.299 [notice] Tor 0.1.0.0-alpha-cvs opening log file.
Feb 23 20:07:23.037 [err] connection.c:1580: assert_connection_ok: Assertion !conn->stream_id failed; aborting.
Feb 23 20:10:22.315 [notice] Tor 0.1.0.0-alpha-cvs opening log file.
Feb 23 20:10:38.381 [err] connection.c:1580: assert_connection_ok: Assertion !conn->stream_id failed; aborting.
Feb 23 20:41:42.167 [notice] Tor 0.1.0.0-alpha-cvs opening log file.
Feb 23 20:42:02.705 [err] connection.c:1580: assert_connection_ok: Assertion !conn->stream_id failed; aborting.
Feb 24 05:28:28.573 [notice] Tor 0.1.0.0-alpha-cvs opening log file.
Feb 24 05:28:42.900 [err] connection.c:1580: assert_connection_ok: Assertion !conn->stream_id failed; aborting.
Feb 24 06:25:16.627 [notice] Tor 0.1.0.0-alpha-cvs opening log file.
Feb 24 06:25:31.073 [err] connection.c:1580: assert_connection_ok: Assertion !conn->stream_id failed; aborting.
Feb 24 11:31:29.223 [notice] Tor 0.1.0.0-alpha-cvs opening log file.
Feb 24 11:31:43.262 [err] connection.c:1580: assert_connection_ok: Assertion !conn->stream_id failed; aborting.
gdb backtrace gives:
#0 0x48217feb in kill () from /usr/lib/libc.so.12
#1 0x4828ca3f in abort () from /usr/lib/libc.so.12
legacy/trac#2 0x0805be68 in assert_connection_ok (conn=0x8122700, now=1109262703)
at connection.c:1649
legacy/trac#3 0x0806ba05 in conn_read_callback (fd=23, event=2, _conn=0x8122700)
at main.c:339
legacy/trac#4 0x481e8a8c in event_process_active () from /usr/lib/libevent.so.0
legacy/trac#5 0x481e8c35 in event_loop () from /usr/lib/libevent.so.0
legacy/trac#6 0x481e8ab6 in event_dispatch () from /usr/lib/libevent.so.0
legacy/trac#7 0x0806c915 in do_main_loop () at main.c:1027
legacy/trac#8 0x0806d2c5 in tor_main (argc=1, argv=0xbfbffb80) at main.c:1656
legacy/trac#9 0x0807d04f in main (argc=1, argv=0xbfbffb80) at tor_main.c:18
legacy/trac#10 0x0804baf2 in ___start ()
I'm running on netbsd 2.0_stable, P2-300 with 256M ram.
[Automatically added by flyspray2trac: Operating System: Other]
**Trac**:
**Username**: yancmhttps://gitlab.torproject.org/tpo/core/tor/-/issues/103Some Tor certs pick www.Nickname.com as their nickname2020-06-27T14:11:14ZTracSome Tor certs pick www.Nickname.com as their nicknameFeb 24 19:32:55.590 [warn] tor_tls_get_peer_cert_nickname(): Peer certificate nickname has illegal characters.
Feb 24 19:32:55.899 [warn] connection_tls_finish_handshake(): Other side (194.95.224.201:443) has a cert without a valid nickn...Feb 24 19:32:55.590 [warn] tor_tls_get_peer_cert_nickname(): Peer certificate nickname has illegal characters.
Feb 24 19:32:55.899 [warn] connection_tls_finish_handshake(): Other side (194.95.224.201:443) has a cert without a valid nickname. Closing.
Feb 24 19:51:52.199 [warn] tor_tls_get_peer_cert_nickname(): Peer certificate nickname has illegal characters.
Feb 24 19:51:52.199 [warn] connection_tls_finish_handshake(): Other side (194.95.224.201:443) has a cert without a valid nickname. Closing.
Feb 24 19:57:14.456 [warn] tor_tls_get_peer_cert_nickname(): Peer certificate nickname has illegal characters.
Feb 24 19:57:14.456 [warn] connection_tls_finish_handshake(): Other side (194.95.224.201:443) has a cert without a valid nickname. Closing.
Feb 24 21:48:52.162 [warn] tor_tls_get_peer_cert_nickname(): Peer certificate nickname has illegal characters.
Feb 24 21:48:52.162 [warn] connection_tls_finish_handshake(): Other side (194.95.224.201:443) has a cert without a valid nickname. Closing.
router NetWorkXXIII 194.95.224.201
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: thomass0.0.9.5Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/104Signals, threads, and libevent may not necessarily play nice2020-06-27T14:11:13ZNick MathewsonSignals, threads, and libevent may not necessarily play niceSometimes when you control-c a server, multiple threads all get a sigint, and handle it oddly.
<arma2> Feb 27 03:29:09.348 [notice] foo
<arma2> Feb 27 03:29:09.349 [notice] Interrupt: will shut down in 30 seconds. In
terrupt again to ex...Sometimes when you control-c a server, multiple threads all get a sigint, and handle it oddly.
<arma2> Feb 27 03:29:09.348 [notice] foo
<arma2> Feb 27 03:29:09.349 [notice] Interrupt: will shut down in 30 seconds. In
terrupt again to exit now.
<arma2> Feb 27 03:29:09.350 [notice] foo
<arma2> Feb 27 03:29:09.351 [notice] Sigint received a second time; exiting now.
<arma2> Feb 27 03:30:35.950 [notice] 1024
<arma2> Feb 27 03:30:35.966 [notice] Interrupt: will shut down in 30 seconds. In
terrupt again to exit now.
<arma2> Feb 27 03:30:35.967 [notice] 1024
<arma2> Feb 27 03:30:35.968 [notice] Sigint received a second time; exiting now.
<arma2> hm.
<arma2> ok, so, not a thread thing.
<arma2> looks like it's getting called twice.
<arma2> does lib event let you double-register?
<arma2> is your tor_get_thread_id() known to work?
> Haven't verified it, no, but it is Really Simple.
> And if it's broken, so is pthreads.
<arma2> ooook :)
<arma2> ah. how's this:
<arma2> i'm not sending a sigint,
<arma2> i'm typing !^c.
<arma2> do you suppose that matters?
<arma2> it does.
> ackpth!
<arma2> whee.
<arma2> is that threads or libevent?
* nickm has no idea what *that* means.
<arma2> are we not allowed to sig_ign a !^c?
> No, I think we are.
<arma2> does !^c sent a sigint to all threads?
<arma2> s/sent/send/
*** You have new email.
> Unspecified afaicr.
<arma2> 'woo'
> Threads and signals is one of the canonically fudgy areas of pthreads iirc.
<arma2> ok i did a kill -INT of a child, and it called hibernate-begin-exit
<arma2> they are not ignoring signals like we'd like them to.
> hmmmmm.
[Automatically added by flyspray2trac: Operating System: All]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/105Todays Build - Possible memory leak?2020-06-27T14:11:13ZTracTodays Build - Possible memory leak?I sync'd and built against CVS this AM - Launched at 6:45 EST. Memory usage is at 25M and climbing.
I suspect a memory leak, but am unsure how to help you find it.
Will it crash at some point and generate a useful core?
I'm on NetBS...I sync'd and built against CVS this AM - Launched at 6:45 EST. Memory usage is at 25M and climbing.
I suspect a memory leak, but am unsure how to help you find it.
Will it crash at some point and generate a useful core?
I'm on NetBSD 2.0_Stable w/P2-300 256M Ram.
Process limits:
clarity 13 -> limit
cputime unlimited
filesize unlimited
datasize 131072 kbytes
stacksize 2048 kbytes
coredumpsize unlimited
memoryuse 251972 kbytes
memorylocked 83990 kbytes
maxproc 160
openfiles 1648
I'm also getting 6-10 of the following messages per hour:
Feb 28 13:55:08.261 [warn] circuit_receive_relay_cell(): connection_edge_process_relay_cell (away from origin) failed.
Feb 28 13:55:08.261 [warn] command_process_relay_cell(): circuit_receive_relay_cell (forward) failed. Closing.
[Automatically added by flyspray2trac: Operating System: BSD]
**Trac**:
**Username**: yancmhttps://gitlab.torproject.org/tpo/core/tor/-/issues/106INSTALL TOR WINDOWS XP2020-06-27T14:11:13ZTracINSTALL TOR WINDOWS XPAfter just install Tor 0.0.9.4.1, on msdos windows, this is the message I have :
Mar 03… (warn) Conn_read() :bug : unhandled error on read for Dir connection (fd 236) ; removing
Mar 03… (notice) conn_close_if_marked(): Conn (addr 18…. F...After just install Tor 0.0.9.4.1, on msdos windows, this is the message I have :
Mar 03… (warn) Conn_read() :bug : unhandled error on read for Dir connection (fd 236) ; removing
Mar 03… (notice) conn_close_if_marked(): Conn (addr 18…. Fd 236, type Dir, State 1) still wants to flush. Losing 66 bytes ! (Marked at c:\documents and settings_nick mathewson\my documents\src\tor\src\or\main.c:275)
I need some help ! Why doesn't it works. My PC is under WINDOWS XP SP2 with a firm firewall and proxy.
Sorry for my poor english, I'm from Paris (France).
thanks
Alyssa
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: alyssaNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/107Bandwidth reporting/bootstrapping2020-06-27T14:11:13ZTracBandwidth reporting/bootstrappingI've been running a Tor server (barf 0.0.9.5 Linux) for 3 weeks with very little usage. My reported bandwidth in the directory is pretty low, even if I have good connectivity (100 K/s). I have at most 1 or 2 connect attempt at the serve...I've been running a Tor server (barf 0.0.9.5 Linux) for 3 weeks with very little usage. My reported bandwidth in the directory is pretty low, even if I have good connectivity (100 K/s). I have at most 1 or 2 connect attempt at the server port (9001) per day. DirPort is set to 0, since I do not want to mirror the directory. Knowing that Tor client picks node that display sufficient bandwidth, it looks like the server need to be 'bootstrapped' initially by forcing some traffic through it, with another Tor client with a EntryNodes and StrictEntryNodes set. There are several 0.0.9.5 servers in the directory with such low bandwidth.
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: qbarfhttps://gitlab.torproject.org/tpo/core/tor/-/issues/108No Tor server exists that allows exit2020-06-27T14:11:13ZTracNo Tor server exists that allows exitFeb 28 21:21:37.813 [notice] circuit_get_open_circ_or_launch(): No Tor
server exists that allows exit to 168.95.5.12:25. Rejecting.
Feb 28 21:21:38.208 [err] circuitlist.c:429: assert_cpath_layer_ok:
Assertion cp->deliver_window >= 0 fai...Feb 28 21:21:37.813 [notice] circuit_get_open_circ_or_launch(): No Tor
server exists that allows exit to 168.95.5.12:25. Rejecting.
Feb 28 21:21:38.208 [err] circuitlist.c:429: assert_cpath_layer_ok:
Assertion cp->deliver_window >= 0 failed; aborting.circuitlist.c:429 assert_cpath_layer_ok: Assertion cp->deliver_window
= 0 failed; aborting.
We are using Tor version 0.0.9.5. , compiled out of a source-tarball with no special compile-options
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: thomassNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/109assert_cpath_layer_ok(): Unexpected state 1712020-06-27T14:11:13ZTracassert_cpath_layer_ok(): Unexpected state 171Mar 02 01:37:03.412 [err] assert_cpath_layer_ok(): Unexpected state 171
Mar 02 01:37:03.412 [err] circuitlist.c:426: assert_cpath_layer_ok:
Assertion 0 failed; aborting.
circuitlist.c:426 assert_cpath_layer_ok: Assertion 0 failed; abort...Mar 02 01:37:03.412 [err] assert_cpath_layer_ok(): Unexpected state 171
Mar 02 01:37:03.412 [err] circuitlist.c:426: assert_cpath_layer_ok:
Assertion 0 failed; aborting.
circuitlist.c:426 assert_cpath_layer_ok: Assertion 0 failed; aborting.
Abort
We are using Tor version 0.0.9.5. , compiled out of a source-tarball with no special compile-options
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: thomasshttps://gitlab.torproject.org/tpo/core/tor/-/issues/111sigpipes in 0.0.9.62020-06-27T14:11:13ZRoger Dingledinesigpipes in 0.0.9.6Mar 25 10:03:05.689 [info] connection_close_immediate(): fd 300, type Exit, state 3, 74 bytes on outbuf.
Mar 25 10:03:05.690 [info] conn_close_if_marked(): Cleaning up connection (fd -1).
Mar 25 10:03:05.690 [info] connection_remove(): r...Mar 25 10:03:05.689 [info] connection_close_immediate(): fd 300, type Exit, state 3, 74 bytes on outbuf.
Mar 25 10:03:05.690 [info] conn_close_if_marked(): Cleaning up connection (fd -1).
Mar 25 10:03:05.690 [info] connection_remove(): removing socket -1 (type Exit), nfds now 338
Mar 25 10:03:05.690 [notice] Caught sigpipe. Ignoring.
Mar 25 10:04:29.026 [info] connection_close_immediate(): fd 36, type Exit, state 3, 73 bytes on outbuf.
Mar 25 10:04:29.026 [info] conn_close_if_marked(): Cleaning up connection (fd -1).
Mar 25 10:04:29.026 [info] connection_remove(): removing socket -1 (type Exit), nfds now 312
Mar 25 10:04:29.027 [notice] Caught sigpipe. Ignoring.
[Automatically added by flyspray2trac: Operating System: All]0.0.9.7https://gitlab.torproject.org/tpo/core/tor/-/issues/112tor-resolve gives funny error message on failure2020-06-27T14:11:13ZRoger Dingledinetor-resolve gives funny error message on failure%tor-resolve imserver.com
Mar 28 22:17:44.706 [warn] parse_socks4a_resolve_response(): Got status response '91', meaning not success.
Mar 28 22:17:44.706 [err] do_resolve(): Error parsing SOCKS response
[Automatically added by flyspra...%tor-resolve imserver.com
Mar 28 22:17:44.706 [warn] parse_socks4a_resolve_response(): Got status response '91', meaning not success.
Mar 28 22:17:44.706 [err] do_resolve(): Error parsing SOCKS response
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/114hidden service descriptors quietly rejected when clock skewed2020-06-27T14:11:12ZRoger Dingledinehidden service descriptors quietly rejected when clock skewedMar 29 06:47:33.643 [warn] rend_cache_store(): Service descriptor h7dkd7zc7aeplgy4 is too far in the future
When clients publish hidden services but their clock is wrong, the hidden service doesn't work. There might
be a log entry expla...Mar 29 06:47:33.643 [warn] rend_cache_store(): Service descriptor h7dkd7zc7aeplgy4 is too far in the future
When clients publish hidden services but their clock is wrong, the hidden service doesn't work. There might
be a log entry explaining this, but perhaps the log entry doesn't say enough? In any case, a log entry may
not be enough to let the user know, if he never looks at his logs.
Is there a better way to communicate this to the user, or is there some way we can cope anyway? (E.g. be more
forgiving about clock skew wrt hidden service descriptors (easy) or remember our skew based on dirserver
timestamps and have Tor "fix" outgoing published timestamps (foolishly hard))
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/115win32 torrc file has funny line endings2020-06-27T14:11:12ZRoger Dingledinewin32 torrc file has funny line endingswordpad works for the win32 torrc we ship in 0.1.0.1-rc, but apparently notepad gets
confused by it. notepad apparently used to work for the previous ones.
is there something wrong with the torrc we ship, or did we skip a step in making...wordpad works for the win32 torrc we ship in 0.1.0.1-rc, but apparently notepad gets
confused by it. notepad apparently used to work for the previous ones.
is there something wrong with the torrc we ship, or did we skip a step in making the exe, or what?
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]0.1.0.2-rcNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/116OS X package UID is a login user2020-06-27T14:11:12ZTracOS X package UID is a login userIn the OS X installer, a user is created with a uid of 503 (the 500 range, anyway). UIDs in this range show up in the login window/fast user switching, which isn't right for the tor user.
UID=103 seems OK here, or perhaps sub 100? I hav...In the OS X installer, a user is created with a uid of 503 (the 500 range, anyway). UIDs in this range show up in the login window/fast user switching, which isn't right for the tor user.
UID=103 seems OK here, or perhaps sub 100? I haven't been able to track down any actual documentation on the ranges, will try to find some and update this.
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]
**Trac**:
**Username**: matthttps://gitlab.torproject.org/tpo/core/tor/-/issues/117event poll failed: Invalid argument [22]2020-06-27T14:11:12Zgoodellevent poll failed: Invalid argument [22]Running 0.1.0.1-rc-cvs:
The Tor server summarily crashes within minutes of starting, with this error:
Mar 31 12:25:25.818 [err] do_main_loop(): event poll failed: Invalid argument [22]
[Automatically added by flyspray2trac: Operating...Running 0.1.0.1-rc-cvs:
The Tor server summarily crashes within minutes of starting, with this error:
Mar 31 12:25:25.818 [err] do_main_loop(): event poll failed: Invalid argument [22]
[Automatically added by flyspray2trac: Operating System: Other Linux]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/118server crash when exiting2020-06-27T14:11:12ZRoger Dingledineserver crash when exitingMar 31 12:37:21.214 [notice] Interrupt: will shut down in 30 seconds. Interrupt again to exit now.
Mar 31 12:37:21.347 [notice] Sigint received a second time; exiting now.
Segmentation fault
(gdb) where
#0 0x0808d11f in _openssl_lock...Mar 31 12:37:21.214 [notice] Interrupt: will shut down in 30 seconds. Interrupt again to exit now.
Mar 31 12:37:21.347 [notice] Sigint received a second time; exiting now.
Segmentation fault
(gdb) where
#0 0x0808d11f in _openssl_locking_cb (mode=9, n=9, file=0x40103857 "rsa_lib.c", line=217)
at crypto.c:1653
#1 0x4007b0b8 in CRYPTO_lock () from /lib/libcrypto.so.2
legacy/trac#2 0x4007b120 in CRYPTO_add_lock () from /lib/libcrypto.so.2
legacy/trac#3 0x4009e987 in RSA_free () from /lib/libcrypto.so.2
legacy/trac#4 0x08088f5d in crypto_free_pk_env (env=0x80d1cd0) at crypto.c:265
legacy/trac#5 0x08066663 in cpuworker_main (data=0x815f7f8) at cpuworker.c:272
legacy/trac#6 0x08086977 in tor_pthread_helper_fn (_data=0x8166278) at compat.c:685
legacy/trac#7 0x40122f77 in pthread_start_thread () from /lib/libpthread.so.0
legacy/trac#8 0x4020deba in thread_start () from /lib/libc.so.6
(gdb) print _openssl_mutexes[n]
Cannot access memory at address 0x24
(gdb) print n
$1 = 9
(gdb) print _openssl_mutexes
$2 = (tor_mutex_t **) 0x0
looks like we free the mutexes before we should?
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/119test bug, sorry for the noise2020-06-27T14:11:12Zweasel (Peter Palfrader)test bug, sorry for the noisehey there
</pre>
<a href="http://www.noreply.org">test</a></p>
<script language="JavaScript" type="text/javascript">
<!--
alert("WARNING: Turn off JavaScript _NOW_.");
// -->
</script>
[Automatically added by flyspray2trac: Operatin...hey there
</pre>
<a href="http://www.noreply.org">test</a></p>
<script language="JavaScript" type="text/javascript">
<!--
alert("WARNING: Turn off JavaScript _NOW_.");
// -->
</script>
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/120servers don't transform destroys to truncateds2020-06-27T14:11:12ZRoger Dingledineservers don't transform destroys to truncatedsIn command_process_destroy_cell(), we are supposed to convert client-ward destroy cells into
truncated cells, so the client can know at what hop in the path the circuit broke. But we
don't actually do this currently, because the client b...In command_process_destroy_cell(), we are supposed to convert client-ward destroy cells into
truncated cells, so the client can know at what hop in the path the circuit broke. But we
don't actually do this currently, because the client behave was always to close the circuit,
so we were wasting bandwidth with a two-round-trip circuit close.
If we're going to start trying to re-extend circuits, though, we need this functionality.
Should we re-enable the ifdef 0'ed stuff (and remove the circuit_mark_for_close())?
[Automatically added by flyspray2trac: Operating System: All]https://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 Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/148osx installer creates startup items even if you don't want them2020-06-27T14:11:09ZRoger Dingledineosx installer creates startup items even if you don't want themReported by Thomas Hardly:
Finally got around to installing the OSX Tor 0.1.0.8-rc Bundle. I
selected "Customize" for the install and chose to install Tor only and
nothing else. The installer instal...Reported by Thomas Hardly:
Finally got around to installing the OSX Tor 0.1.0.8-rc Bundle. I
selected "Customize" for the install and chose to install Tor only and
nothing else. The installer installed a Tor directory inside of
/Library/StartupItems/. Which contained a file called Tor.loc that
contained the text: "//Library/Tor"
While this is not a valid StartupItem, I didnt choose to install any
StartupItem's. It shouldnt be installing anything in that directory.
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]https://gitlab.torproject.org/tpo/core/tor/-/issues/150[tor] autoconf fails on sparc64 debian2020-06-27T14:11:09ZTrac[tor] autoconf fails on sparc64 debian<pre>
i haven't managed to get the cvs trunc compiled for some time now. let me know if you need me and my sparc to figure this one out. (meet on irc?) -matthias
Version: CVS Trunc from Sat May 28 09:17:43 CEST 2005
(but i...<pre>
i haven't managed to get the cvs trunc compiled for some time now. let me know if you need me and my sparc to figure this one out. (meet on irc?) -matthias
Version: CVS Trunc from Sat May 28 09:17:43 CEST 2005
(but i have tried this before and it stopped working a while ago)
Host: Debian Woody
Linux dali 2.4.18 #2 Thu Apr 11 14:37:17 EDT 2002 sparc64 unknown
Symptoms: When I try to run autoconf on the code, this is what happens:
configure.in:79: warning: AC_TRY_RUN called without default to allow cross compiling
configure.in:123: warning: AC_TRY_RUN called without default to allow cross compiling
configure.in:123: warning: AC_TRY_RUN called without default to allow cross compiling
configure.in:251: warning: AC_TRY_RUN called without default to allow cross compiling
configure.in:304: warning: AC_TRY_RUN called without default to allow cross compiling
configure.in:305: warning: AC_TRY_RUN called without default to allow cross compiling
configure.in:306: warning: AC_TRY_RUN called without default to allow cross compiling
configure.in:307: warning: AC_TRY_RUN called without default to allow cross compiling
configure.in:308: warning: AC_TRY_RUN called without default to allow cross compiling
configure.in:309: warning: AC_TRY_RUN called without default to allow cross compiling
configure.in:310: warning: AC_TRY_RUN called without default to allow cross compiling
configure.in:311: warning: AC_TRY_RUN called without default to allow cross compiling
configure.in:312: warning: AC_TRY_RUN called without default to allow cross compiling
configure.in:313: warning: AC_TRY_RUN called without default to allow cross compiling
configure.in:317: warning: AC_TRY_RUN called without default to allow cross compiling
configure.in:318: warning: AC_TRY_RUN called without default to allow cross compiling
configure.in:319: warning: AC_TRY_RUN called without default to allow cross compiling
configure.in:320: warning: AC_TRY_RUN called without default to allow cross compiling
configure.in:321: warning: AC_TRY_RUN called without default to allow cross compiling
configure.in:322: warning: AC_TRY_RUN called without default to allow cross compiling
configure.in:323: warning: AC_TRY_RUN called without default to allow cross compiling
configure.in:324: warning: AC_TRY_RUN called without default to allow cross compiling
configure.in:329: warning: AC_TRY_RUN called without default to allow cross compiling
configure.in:333: warning: AC_TRY_RUN called without default to allow cross compiling
autoconf: Undefined macros:
configure.in:140: AC_MSG_NOTICE([
configure.in:149: AC_MSG_NOTICE([
configure.in:159: AC_MSG_NOTICE([
configure.in:17: AC_HELP_STRING(--enable-debug, compile with debugging info),
configure.in:23: AC_HELP_STRING(--disable-threads, disable multi-threading support))
configure.in:281:AC_SYS_LARGEFILE
configure.in:296:AC_FUNC_FSEEKO
configure.in:298:AC_CHECK_MEMBERS([struct timeval.tv_sec])
configure.in:30: AC_MSG_NOTICE([You are running OpenBSD or NetBSD; I am assuming that
configure.in:343:[AC_RUN_IFELSE([AC_LANG_SOURCE(
configure.in:358:[AC_RUN_IFELSE([AC_LANG_SOURCE(
</pre>
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: fishttps://gitlab.torproject.org/tpo/core/tor/-/issues/151WinXP: Tor complains when user's not an admin2020-06-27T14:11:09ZTracWinXP: Tor complains when user's not an adminHi,
I'm using Tor 0.0.9.9 on Windows XP Home SP2.
If I'm logged in with full administrator rights, everything works fine.
If I'm logged in as a member of the group "guests", Tor complains on startup:
May 31 16:39:29.012 [err] crypto_...Hi,
I'm using Tor 0.0.9.9 on Windows XP Home SP2.
If I'm logged in with full administrator rights, everything works fine.
If I'm logged in as a member of the group "guests", Tor complains on startup:
May 31 16:39:29.012 [err] crypto_seed_rng(): Can't get CryptoAPI provider [2], error code: 5
Tor continues working, but I wonder if this is a bug or not?
Regards,
Michel
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: Michel0.1.0.9Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/152Hidden Services resolving issues2020-06-27T14:11:08ZTracHidden Services resolving issuesIt would seem that hidden services do not resolve to what you might
expect. I found this issue with an incorrectly appended www on the
front of my hidden service, i.e. www.[myhiddenhostremoved].onion which
took me to another hidden serv...It would seem that hidden services do not resolve to what you might
expect. I found this issue with an incorrectly appended www on the
front of my hidden service, i.e. www.[myhiddenhostremoved].onion which
took me to another hidden service (with a pink heart motif favicon)
which definitely wasn't mine, although it was just a blank page.
I tested a few others, and found that www.onion took me to the webpage
of airstrip.jp
Are these resolving oddities intentional, or is there a problem here?
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: Grillhttps://gitlab.torproject.org/tpo/core/tor/-/issues/153control-spec does not cover password authentication2020-06-27T14:11:08ZTraccontrol-spec does not cover password authenticationThe section in the control-spec.txt about the AUTHENTICATE message (3.8) is a bit unclear on the format in which to send the credentials. The cookie authentication is only mentioned, but no message format given, and the password authenti...The section in the control-spec.txt about the AUTHENTICATE message (3.8) is a bit unclear on the format in which to send the credentials. The cookie authentication is only mentioned, but no message format given, and the password authentication is not mentioned at all.
(The cookie auth message is quite easy to figure out by trying, though - just send the cookie file as the message body.)
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: rmhttps://gitlab.torproject.org/tpo/core/tor/-/issues/154replicable server crash by control message on win2k2020-06-27T14:11:08ZTracreplicable server crash by control message on win2kI found this while trying to implement the password authentication of the tor control protocol. On Windows 2000 Professional, tor 0.1.0.8-rc, the server can be replicably crashed by the following procedure:
- set a HashedControlPassword...I found this while trying to implement the password authentication of the tor control protocol. On Windows 2000 Professional, tor 0.1.0.8-rc, the server can be replicably crashed by the following procedure:
- set a HashedControlPassword in the torrc
- start tor
- open a local tcp connection to the ControlPort
- send a byte sequence like 00 04 00 07 49 50 51 00 (4 bytes length, message type AUTHENTICATE, any password [in this case "123"], null terminator)
On my machine, the server crashes immediately. Example log:
-------
Jun 04 21:54:35.046 [notice] Tor v0.1.0.8-rc. This is experimental software. Do not rely on it for strong anonymity.
Jun 04 21:54:35.109 [notice] Initialized libevent version 1.1 using method win32
Jun 04 21:54:48.437 [err] crypto_seed_rng(): Can't get CryptoAPI provider [2], error code: 8009000f
Jun 04 21:54:50.625 [notice] router_orport_found_reachable(): Your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Jun 04 21:54:50.765 [notice] Tor has successfully opened a circuit. Looks like it's working.
Jun 04 21:54:51.406 [notice] directory_handle_command_get(): Client asked for the mirrored directory, but we don't have a good one yet. Sending 503 Dir not available.
Jun 04 21:55:01.703 [err] _tor_malloc(): Out of memory. Dying.
-------
At the time of testing, the machine had >200 MB of physical RAM available, so it's not an actual memory shortage.
Some lines of my torrc:
-------
ControlPort 9696
ClientOnly 1
HashedControlPassword oGd9L4OZ3aBgsMS4044OjH1UDd0tYfh3E1RZZcY=
#CookieAuthentication 1
-------
The rest are just standard settings.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: rmNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/156"NoPublish 1" honored incompletely2020-06-27T14:11:08ZTrac"NoPublish 1" honored incompletelyWhen I set
ClientOnly 1
NoPublish 1
in my torrc, the server nonetheless reports
---------
Jun 09 22:33:32.750 [notice] Tor has successfully opened a circuit. Looks like it's working.
Jun 09 22:33:32.750 [notice] Now checking whether...When I set
ClientOnly 1
NoPublish 1
in my torrc, the server nonetheless reports
---------
Jun 09 22:33:32.750 [notice] Tor has successfully opened a circuit. Looks like it's working.
Jun 09 22:33:32.750 [notice] Now checking whether ORPort and DirPort are reachable... (this may take several minutes)
Jun 09 22:33:43.000 [notice] directory_handle_command_get(): Client asked for the mirrored directory, but we don't have a good one yet. Sending 503 Dir not available.
Jun 09 22:34:36.500 [notice] router_orport_found_reachable(): Your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
---------
However, the node is not listed in the directory, so this seems to be ok. The two ports are actually probed from the outside, though.
Tested on Win2000, SP4.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: rmhttps://gitlab.torproject.org/tpo/core/tor/-/issues/157OSX (10.4.1) SOCKS Proxy problem2020-06-27T14:11:08ZTracOSX (10.4.1) SOCKS Proxy problemWhen I activated the SOCKS proxy (127.0.0.1 port 9050), I could no longer send smtp email via my email client (MS Entourage 2k4). Called my isp, and aside from being impressed that I had checked my email from 18 different class A IP addr...When I activated the SOCKS proxy (127.0.0.1 port 9050), I could no longer send smtp email via my email client (MS Entourage 2k4). Called my isp, and aside from being impressed that I had checked my email from 18 different class A IP addresses, they could see no request from me to even attempt to conect and send from my account. Turned off the SOCKS proxy and everything worked fine again. I do run the OS X firewall and have set it up to be open but upon further reading, that looks like it only opens for receive not send. So, how do I "punch a hole"? Or, am I just missing the boat on something. All other tor function works fine.
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]
**Trac**:
**Username**: taichiAndrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/tpo/core/tor/-/issues/159Better failure notice on tor_resolve2020-06-27T14:11:08ZTracBetter failure notice on tor_resolveWhen trying to resolve a non-existing domain, I get this:
>tor_resolve.exe doesntexist.abc
Jun 15 11:06:26.750 [warn] parse_socks4a_resolve_response(): Got status response '91': socks request failed.
This could be improved for the end ...When trying to resolve a non-existing domain, I get this:
>tor_resolve.exe doesntexist.abc
Jun 15 11:06:26.750 [warn] parse_socks4a_resolve_response(): Got status response '91': socks request failed.
This could be improved for the end user. I seem to remember that older versions returned something like "Tried resolving ... at three locations, giving up"?
Found with 0.1.0.9-rc, win32, not running as server.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: rmhttps://gitlab.torproject.org/tpo/core/tor/-/issues/160"GETINFO network-status" seems to fail2020-06-27T14:11:07ZTrac"GETINFO network-status" seems to failWhen I send a GETINFO control message with the parameter "network-status", the server seems to close the control connection. The timing appears to be inconsistent, sometimes the reply message can be read fully, after which the socket is ...When I send a GETINFO control message with the parameter "network-status", the server seems to close the control connection. The timing appears to be inconsistent, sometimes the reply message can be read fully, after which the socket is closed, sometimes only 8636 bytes can be read. (The number may be coincidental, but was constant in my tests.) Found in 0.1.0.9-rc on win32.
agl ran the demo python script on 0.1.1.0-alpha-cvs and received the following output:
...
[12:41] <agl> {'version': '0.1.1.0-alpha-cvs'}
[12:41] <agl> Traceback (most recent call last):
[12:41] <agl> File "TorControl.py", line 457, in ?
[12:41] <agl> do_main_loop(sh,sp)
[12:41] <agl> File "TorControl.py", line 425, in do_main_loop
[12:41] <agl> print `get_info(s,"network-status")`
[12:41] <agl> File "TorControl.py", line 305, in get_info
[12:41] <agl> tp,body = receive_reply(s,[MSG_TYPE.INFOVALUE])
[12:41] <agl> File "TorControl.py", line 247, in receive_reply
[12:41] <agl> raise ErrorReply((errCode,
[12:41] <agl> __main__.ErrorReply: (1, 'Internal error', 'network-status')
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: rmhttps://gitlab.torproject.org/tpo/core/tor/-/issues/161Tor links to pthreads on OpenBSD by default2020-06-27T14:11:07ZTracTor links to pthreads on OpenBSD by defaultThe ChangeLog and configure.in state that threads are disabled on OpenBSD and NetBSD by default, but it still continues to link to them when building.
> uname -a
OpenBSD chaos.brain-box.net 3.7 FLOW#40 i386
gcc -g -O2 -Wall -g -O2 -o...The ChangeLog and configure.in state that threads are disabled on OpenBSD and NetBSD by default, but it still continues to link to them when building.
> uname -a
OpenBSD chaos.brain-box.net 3.7 FLOW#40 i386
gcc -g -O2 -Wall -g -O2 -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 dns.o hibernate.o main.o onion.o relay.o rendcommon.o rendclient.o rendmid.o rendservice.o rephist.o router.o routerlist.o routerparse.o tor_main.o ../common/libor.a ../common/libor-crypto.a -lz -lssl -lcrypto -lpthread -levent
../common/libor.a(util.o)(.text+0x3bf): In function `tor_strpartition':
/home/jon/src/tor-0.1.0.10/src/common/util.c:265: warning: strcpy() is almost always misused, please use strlcpy()
../common/libor.a(util.o)(.text+0xad9): In function `base16_encode':
/home/jon/src/tor-0.1.0.10/src/common/util.c:466: warning: sprintf() is often misused, please use snprintf()
gcc -DHAVE_CONFIG_H -I. -I. -I../.. -g -O2 -Wall -g -O2 -c test.c
gcc -g -O2 -Wall -g -O2 -o test 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 dns.o hibernate.o main.o onion.o relay.o rendcommon.o rendclient.o rendmid.o rendservice.o rephist.o router.o routerlist.o routerparse.o test.o ../common/libor.a ../common/libor-crypto.a -lz -lssl -lcrypto -lpthread -levent
test.o(.text+0x2077): In function `test_crypto':
/home/jon/src/tor-0.1.0.10/src/or/test.c:490: warning: strcpy() is almost always misused, please use strlcpy()
../common/libor.a(util.o)(.text+0xad9): In function `base16_encode':
/home/jon/src/tor-0.1.0.10/src/common/util.c:466: warning: sprintf() is often misused, please use snprintf()
test.o(.text+0x23c1): In function `test_crypto':
/home/jon/src/tor-0.1.0.10/src/or/test.c:531: warning: strcat() is almost always misused, please use strlcat()
Making all in tools
cd ../.. && CONFIG_FILES=src/tools/Makefile CONFIG_HEADERS= /bin/sh ./config.status
config.status: creating src/tools/Makefile
config.status: executing default-1 commands
gcc -DHAVE_CONFIG_H -I. -I. -I../.. -g -O2 -Wall -g -O2 -c tor-resolve.c
gcc -g -O2 -Wall -g -O2 -o tor-resolve tor-resolve.o ../common/libor.a -lpthread -levent
tor-resolve.o(.text+0x89): In function `build_socks4a_resolve_request':
***
Even specifing --disable-threads to ./configure does not fix the problem. It still links to pthreads.
'ldd' verifies this :
> ldd tor
tor:
Start End Type Ref Name
00000000 00000000 exe 1 tor
0eb93000 2eb9b000 rlib 1 /usr/lib/libz.so.4.0
09bd2000 29bdd000 rlib 1 /usr/lib/libssl.so.10.0
08447000 28475000 rlib 1 /usr/lib/libcrypto.so.12.0
0ae21000 2ae2a000 rlib 1 /usr/lib/libpthread.so.6.1
0809d000 280d6000 rlib 1 /usr/lib/libc.so.38.0
0890b000 0890b000 rtld 1 /usr/libexec/ld.so
[Automatically added by flyspray2trac: Operating System: BSD]
**Trac**:
**Username**: jonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/162"The service did not return an error." message2020-06-27T14:11:07ZTrac"The service did not return an error." messageGet "The service did not return an error." message when trying to stop service in services.msc in windows (on windows XP SP2). It does close the process, and if you try and tell it to stop again, it just hangs for a while, and eventually...Get "The service did not return an error." message when trying to stop service in services.msc in windows (on windows XP SP2). It does close the process, and if you try and tell it to stop again, it just hangs for a while, and eventually says that it stopped. After this you can hit start process, and everything works normally.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: bknobbshttps://gitlab.torproject.org/tpo/core/tor/-/issues/163tor_socketpair doesn't report errors on win322020-06-27T14:11:07ZRoger Dingledinetor_socketpair doesn't report errors on win32tor_socketpair() assumes errno is how you report errors, but that isn't
the case for Windows, which is where it's most likely to be called.
[Automatically added by flyspray2trac: Operating System: All]tor_socketpair() assumes errno is how you report errors, but that isn't
the case for Windows, which is where it's most likely to be called.
[Automatically added by flyspray2trac: Operating System: All]0.1.1.1-alphahttps://gitlab.torproject.org/tpo/core/tor/-/issues/164TOR quit working when behind a linksys router2020-06-27T14:11:07ZTracTOR quit working when behind a linksys routerTOR became ineffective with computers behind a linkssys router after version 0.0.9.9. It did redirect at this revision.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: wolfzazTOR became ineffective with computers behind a linkssys router after version 0.0.9.9. It did redirect at this revision.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: wolfzazAndrew LewmanAndrew Lewman