The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T14:11:20Zhttps://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/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/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/56Tor is not aggressive enough about improving latency2020-06-27T14:11:19ZTracTor is not aggressive enough about improving latencySummary: Please make Tor more aggressive in detecting when it is using a slow OR path and hence causing it to test out alternate paths.
I've noticed that some Tor ORs are faster than others. The end result is that sometimes I get 'bum' ...Summary: Please make Tor more aggressive in detecting when it is using a slow OR path and hence causing it to test out alternate paths.
I've noticed that some Tor ORs are faster than others. The end result is that sometimes I get 'bum' ORs who slow my system down to a crawl. Tor does not seem to be nearly aggressive enough about detecting this situation and trying alternate routing paths.
I recognize that if Tor was more aggressive about finding better paths a really smart attacker could use DOS attacks against specific ORs to shape traffic into specific proxies but ya gotta admit that's a pretty esoteric attack. For the moment I think performance is more important.
I also recognize that if Tor is too aggressive in optimizing the routing path then better performing ORs will get slammed but that is a self correcting problem.
Please considering adding features to make Tor more aggressive in finding better ORs. The biggest thing keeping me from recommending Tor to all of my friends is the latency it introduces.
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]
**Trac**:
**Username**: nU8hJ1zQ9https://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/59Include OSX and Win32 installation docs in package2020-06-27T14:11:18ZTracInclude OSX and Win32 installation docs in packageShip the OSX and Win32 installation instructions in package, including the screenshots (fetched from tor.eff.org at the moment).
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: thomassShip the OSX and Win32 installation instructions in package, including the screenshots (fetched from tor.eff.org at the moment).
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: thomassAndrew LewmanAndrew Lewmanhttps://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 Mathewson