Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:02:11Zhttps://gitlab.torproject.org/legacy/trac/-/issues/62connect attempt just hangs2020-06-13T14:02:11Zweasel (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/legacy/trac/-/issues/63Tor0.0.9.2bug (with firewall ZoneAlarm)2020-06-13T14:02:11ZTracTor0.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/legacy/trac/-/issues/64if the network is started after tor, tor cannot/does not connect2020-06-13T14:02:11ZTracif 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/legacy/trac/-/issues/65Mirroring dir via apache introduces unrecognized x-compress header2020-06-13T14:02:11ZRoger 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/legacy/trac/-/issues/66Website barely mentions that Tor is TCP-only2020-06-13T17:18:07ZRoger DingledineWebsite barely mentions that Tor is TCP-onlyThere's a statement subtly buried in overview.html, but other than that
we never explain that it won't work with dig or other udp apps. Where
should we say it that's more obvious?
[Automatically added by flyspray2trac: Operating System:...There's a statement subtly buried in overview.html, but other than that
we never explain that it won't work with dig or other udp apps. Where
should we say it that's more obvious?
[Automatically added by flyspray2trac: Operating System: All]Andrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/legacy/trac/-/issues/67We need to pass a string back along with the http status codes2020-06-13T14:02:11ZRoger 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/legacy/trac/-/issues/68Tor complains about missing epoll2020-06-13T14:02:11ZRoger 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/legacy/trac/-/issues/69Add flag to tor to verify config2020-06-13T14:02:11ZTracAdd flag to tor to verify configRight now if you edit the torrc incorrectly and HUP tor, it dies (and only says so in the log file so you
may not even notice for awhile. Anyways, it would be nice if tor had something equivalent to Apache's -t
flag which says "verify m...Right now if you edit the torrc incorrectly and HUP tor, it dies (and only says so in the log file so you
may not even notice for awhile. Anyways, it would be nice if tor had something equivalent to Apache's -t
flag which says "verify my config and tell me what if anything is broken". That way we could have a
torctl script which has a 'reload' option which would first verify the config and if OK, would HUP tor.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: synfinatic0.1.0.1-rcNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/70Don't force BandwidthBurst to be 2x + 1 BandwithRate2020-06-13T14:02:11ZTracDon't force BandwidthBurst to be 2x + 1 BandwithRateForcing BandwidthBurst to be 2x + 1 (or even 2x) the BandwidthRate is silly for people who
would like Tor to be able to burst to their full link speed, but average above 50% of the link speed.
Ie: I have a 768K link and want tor to aver...Forcing BandwidthBurst to be 2x + 1 (or even 2x) the BandwidthRate is silly for people who
would like Tor to be able to burst to their full link speed, but average above 50% of the link speed.
Ie: I have a 768K link and want tor to average 512K and burst up to 768K. Current limitation would require
me to set BandwidthRate to 384K not 512K.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: synfinatichttps://gitlab.torproject.org/legacy/trac/-/issues/71Warn when exit policy allows private:*2020-06-13T14:02:11ZNick MathewsonWarn when exit policy allows private:*Too many people are telling us that the sky is falling because that Tor allows connections to private networks. This is, of course, because people aren't setting their exit policies to block them. Nevertheless, we should probably have ...Too many people are telling us that the sky is falling because that Tor allows connections to private networks. This is, of course, because people aren't setting their exit policies to block them. Nevertheless, we should probably have Tor give a warning when you start a server and the exit policy allows x:* connections to a non-public address.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/72Open LDAP and LDAPS ports in the default policy2020-06-13T14:02:11ZshamrockOpen 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/legacy/trac/-/issues/73Issues with Tor server and XP SP22020-06-13T14:02:11ZTracIssues 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/legacy/trac/-/issues/74Servers bloat memory from spawned children2020-06-13T14:02:11ZRoger 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/legacy/trac/-/issues/75please check age of directory that is downloaded2020-06-13T14:02:11Zweasel (Peter Palfrader)please check age of directory that is downloadedFor some reasons there are servers out there that serve a directory that is weeks old
published 2005-01-13 20:56:38 (68.17.146.26:143)
published 2005-01-20 06:57:34 (67.168.253.106:9030)
When clients fetch a directory with an out ...For some reasons there are servers out there that serve a directory that is weeks old
published 2005-01-13 20:56:38 (68.17.146.26:143)
published 2005-01-20 06:57:34 (67.168.253.106:9030)
When clients fetch a directory with an out of date recommended-versions field they will shutdown.
Jan 25 04:47:56.760 [err] You are running Tor version 0.0.9.3, which will not work with this network. Please use one of....
Please make the tor client not accept directories older than a day or so.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/76don't ask unverified nodes for a directory2020-06-13T14:02:11ZRoger 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/legacy/trac/-/issues/77clients are believing really old recommended-versions2020-06-13T14:02:11ZRoger 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/legacy/trac/-/issues/78please add 'opt hibernating yes' in the descriptor2020-06-13T14:02:11Zweasel (Peter Palfrader)please add 'opt hibernating yes' in the descriptorIt would be nice if the server descriptor of hibernating nodes just said
conclusively that this node is in fact hibernating right now.
Probably something like "opt hibernating yes" would work. If you want
to make it fancy you could eve...It would be nice if the server descriptor of hibernating nodes just said
conclusively that this node is in fact hibernating right now.
Probably something like "opt hibernating yes" would work. If you want
to make it fancy you could even well when it expects to wake up again.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/79clients pick you as an exit node if there's even a chance you can exit there2020-06-13T13:57:14ZRoger 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/legacy/trac/-/issues/80Max dir size is 500 kilobytes2020-06-13T13:57:14ZRoger 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/legacy/trac/-/issues/81streams end badly when server runs out of fd's2020-06-13T13:57:14ZRoger 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 Dingledine