The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T14:10:56Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/291NEWDESC events sometimes include truncated IDs2020-06-27T14:10:56ZedmanmNEWDESC events sometimes include truncated IDs[edmanm@adrastea:~]$ telnet localhost 9051
Trying 127.0.0.1...
Connected to localhost.
Escape character is '!^]'.
authenticate
250 OK
getinfo version
250-version=0.1.1.19-rc
250 OK
setevents newdesc
250 OK
650 NEWDESC 06EC24D4E463F23D6EC...[edmanm@adrastea:~]$ telnet localhost 9051
Trying 127.0.0.1...
Connected to localhost.
Escape character is '!^]'.
authenticate
250 OK
getinfo version
250-version=0.1.1.19-rc
250 OK
setevents newdesc
250 OK
650 NEWDESC 06EC24D4E463F23D6EC646F88FDD746521D9442D 0C43A8E643548F7DE6173178FD0B7D8A3308036F 1405C41C94242B30F46E9396EC8A8D3A6C6C9240
191D0CEF97EB82CAD0EBBAE67487B1FF713DFEE4 1BE3590BA6AB203B9921DB428FF1F61052504C4F 1C2E6B96DB69E38AF3F372A3059A3525D8F5A8C5
1D27E66D08594CD5561EABCABF9C54259A67BEF8 2569E6088637529C7F4F1A9531C29043C935C47F 2572F3F0DE49357B679162CD62778BD148977E24
26FE4DF3CD72297FCFA4D976F20C594388665F56 28A021DB08FEC1B356076BCCBA9125D19509C32F 2AF395C600C9BBACEC70F7A763A293ABC3DB9253
2B4DE759C72F111D4EB5864D3F2CCF4AB38994F5 2CB091B4167183B0C579026EB0F149C292EA3912 2E9D2C58ED6B2A82CE15949E7A8AD2E20BECA3AB
337E599367550A6BF3D9785AAB1FABAFEB1B9B0B 353E27DFBF41251058D7EE58E674B95D922A83B1 37EFBEE64C465DB3A9025DDC7FF180ACBFE82D1E
3831B366B72E7F8A1927F952FFD88FDBC1DA4F2B 3871317A7416C3EE3D63F1BB0C3D1F35F9591E34 389C064C4379FCEE11181F2D85E6FB501D9A74E8
3FE5744E21A09CD7BBB17A1F2F393A3F2F8A1737 45C93541FA68D0FDD2D5405C3E991CD863098580 46F255C4D368596A1548D7A9B361C3580319D920
470F4E6B8D06942E629B4F80D
650 NEWDESC BAD47A6FB8E207F51FD01B5589181F750485D0A3 BC33B48B5E03DD7EDC61DAF7CB987FFFE5F4271E BD7E124EC3CB6B558EECDF84121B21E0373F4C26
C76815FA912A6B2954B70DA4FF033902CC4F0650 C9D329631642E01BAB39671BBD33EEEA06A2E6EC CA75FA9902A200EE5C2B41EA11055F6BD6624457
CDDD404B4A61AA21EA0E637E69DEE91AAA52DA70 CE52820C6795A5AB6528BEC853EEE71A65EF26E8 D35E1FFFB10EF66F6DFBE2EB977667BA8BD8BBB5
D5F2C65F4131A1468D5B67A8838A9B7ED8C049E2 D683E7E5E4468D67659FAE14EB3E0216786DC8E9 D754E6D7E34D0CAA8428422A022CA697C3397981
D8BE5A425E616679A0966A2CCCBE30183019352D DA42FA10174D0482A801782E4DAEAC1FB6987933 DD1C53F230DDD06726D541B23243066098629C14
E6A4BD6150D0385C60BFA96AA7E3E9CBF748B0DF E710B7B1BCC65FECE5BA345CEC8B81BEA216318F EA40EDEB4E9100FA68B020AD9600BEF9939B0CA8
EACB6330CD96AB696523C88D10A3FEBE5FFC3841 EB339BFFCABD2DE0DF7ADCD0F20FEB725827E506 EBB1D8477C731F46FFC8934E463465D4EBD4EDEC
EBE830DCE9A24038DD8A777FBB9C66792CF2B9DF ED4CEEB89E3A8E74E7D9FEF80DD8AC99C74C0C88 EF558AFB169532FC391B885FEEB5E7FA49B43850
F8C0CDB892C5A2E6CFB041018
650 NEWDESC 536C45AD3FCAFA88D70B830B9B323284CDE013AA 53D366DA48B8C2749340FE969FEF5B2DD073AF69 55BC79A4610212F56F475F4ECD667DBA9AB5A433
55F6F11ECDD5CAC793D5058ECAAAF5CDED2BD571 59CBA17C53F0BD79D6106B70A769BCA23A8C3EAC 5D02C99CCF841495A0ACBF917A0A750B9646DB8D
5F8AB19F5CB30B70A9530A426846548F2401796F 6C1854DCD38E6BD3A017C9AB1A45B7FA465E64D9 6CE2E5224D203AD9369491BCF2FD192C6D8F2E48
7419139C78D79C45419D5C83B8CCD3F461B53966 76D72D2B5E0523FCAB75A5EDD795E76B6C46B843 79AA2C6BFC01BFC9E5634793D0C3B505EB05CF3C
82BD1D9A6D41DF196DA37F9ABBCC66FFA494C39D 83731D55E300483F591C2CA3A896251E8714F96E 847B1F850344D7876491A54892F904934E4EB85D
86299223B175C4A2BF840869FEBC32C1E3AB8F24 8AB95DC79BC521B00E574F426DCB5441560D13E4 8B6F5999A60F66A07D51BA0C7B9B1456E8F77310
8CCA8F718E687F2B38CAAECF114278ADE7ACC597 8E1A4260530F304B1F816C896F3231751BA8EA6D A4D468D135F2F83D6CACDC85975B562BDEF3A936
A648B345CEB029D0763BA86B26DC97F6E44AD988 A6E8B6355A356056A9022AE7FCCB423C6FB3321D AA4019D85823518F09043F05E61EAE5E52CA78B4
AF997E0B4AD21F248A8C27D19
650 NEWDESC 24AC6F92E1B28CCA697175C2E41C0B28797D3401 38845B60D6635E35F83C41C0AFBF2134C7F00FC5 C5300BF770746D7DD7E85AB908E1F5E56F677208
CE1B93A998DE00FD958B06D5A44A19A728291A7D
In the first three NEWDESC events, the last ID in each event message appears to be truncated. The last
ID in the fourth NEWDESC event is of normal length.
I poked around at this a bit and found this relevant looking bit of code in control.c:
607 #define SEND_CONTROL1_EVENT_BUFFERSIZE 1024
608 int r;
609 char buf[SEND_CONTROL1_EVENT_BUFFERSIZE]; /* XXXX Length */
Given that the truncated NEWDESC event messages above are 1022 bytes long (and then two bytes for a \r\n),
it appears that I ran into the XXXX above. :)
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/292RunAsDaemon being uncommented when installed as service gives unhelpful error.2020-06-27T14:10:56ZTracRunAsDaemon being uncommented when installed as service gives unhelpful error.When RunAsDaemon is uncommented, the Tor service installs, but fails to start.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: HexMasterWhen RunAsDaemon is uncommented, the Tor service installs, but fails to start.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: HexMasterRoger DingledineRoger Dingledinehttps://gitlab.torproject.org/tpo/core/tor/-/issues/293RedirectExit option broken in tor-0.1.1.20 [patch included]2020-06-27T14:10:55ZTracRedirectExit option broken in tor-0.1.1.20 [patch included]Using RedirectExit in torrc causes Tor 0.1.1.20 to exit, only leaving in the log:
set_options(): Acting on config options left us in a broken state. Dying.
Root cause afaik is missing braces in src/or/config.c
[Automatically added by ...Using RedirectExit in torrc causes Tor 0.1.1.20 to exit, only leaving in the log:
set_options(): Acting on config options left us in a broken state. Dying.
Root cause afaik is missing braces in src/or/config.c
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: oldenhttps://gitlab.torproject.org/tpo/core/tor/-/issues/294Non-existant torrc isn't created when ran as service; gives misleading error ...2020-06-27T14:10:55ZTracNon-existant torrc isn't created when ran as service; gives misleading error as a result.C:\Program Files\Tor>dir
Volume in drive C is Local Disk
Volume Serial Number is 5C42-D9B0
Directory of C:\Program Files\Tor
05/23/2006 01:44a <DIR> .
05/23/2006 01:44a <DIR> ..
05/24/2006 03:58p ...C:\Program Files\Tor>dir
Volume in drive C is Local Disk
Volume Serial Number is 5C42-D9B0
Directory of C:\Program Files\Tor
05/23/2006 01:44a <DIR> .
05/23/2006 01:44a <DIR> ..
05/24/2006 03:58p <DIR> Documents
05/23/2006 01:12p 1,064,960 libeay32.dll
05/23/2006 01:12p 200,704 ssleay32.dll
05/24/2006 03:58p 45 Tor Website.url
05/23/2006 01:12p 1,224,704 tor.exe
05/23/2006 01:12p 303,104 tor_resolve.exe
05/24/2006 03:58p 50,511 Uninstall.exe
6 File(s) 2,844,028 bytes
3 Dir(s) 10,342,510,592 bytes free
C:\Program Files\Tor>tor -install
Service installed successfully
Service failed to start : The system cannot find the file specified.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: HexMaster0.1.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/295"Tor.exe -remove" appears to not be waiting for service to stop.2020-06-27T14:10:55ZTrac"Tor.exe -remove" appears to not be waiting for service to stop.C:\Program Files\Tor>tor -remove
Service failed to stop :
Service could not be removed
C:\Program Files\Tor>tor -remove
Service is already stopped
Removed service successfully
[Automatically added by flyspray2trac: Operating System: Wi...C:\Program Files\Tor>tor -remove
Service failed to stop :
Service could not be removed
C:\Program Files\Tor>tor -remove
Service is already stopped
Removed service successfully
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: HexMasterhttps://gitlab.torproject.org/tpo/core/tor/-/issues/296clients potentially overwhelm circuits with new streams2020-06-27T14:10:55Zgoodellclients potentially overwhelm circuits with new streamsWell-behaved Tor clients SHOULD not attach a stream to a circuit
if the circuit has more than N not-yet-connected streams on it.
In particular, some exit nodes cannot handle so many new TCP
connections to open, even if middleman nodes ju...Well-behaved Tor clients SHOULD not attach a stream to a circuit
if the circuit has more than N not-yet-connected streams on it.
In particular, some exit nodes cannot handle so many new TCP
connections to open, even if middleman nodes just see all of the
traffic as cells to pass along.
[Automatically added by flyspray2trac: Operating System: All]post 0.2.1.xRoger DingledineRoger Dingledinehttps://gitlab.torproject.org/tpo/core/tor/-/issues/297streams should migrate to better circuits more aggressively2020-06-27T14:10:55Zgoodellstreams should migrate to better circuits more aggressivelyAssert: most streams that fail to transition from SENTCONNECT to
SUCCEEDED on a given within five seconds never make that transition
at all. So, to improve client performance in the vast majority of
cases, we should migrate these stream...Assert: most streams that fail to transition from SENTCONNECT to
SUCCEEDED on a given within five seconds never make that transition
at all. So, to improve client performance in the vast majority of
cases, we should migrate these streams to new circuits more quickly
(retrying, for example, after five seconds).
At the same time, some Internet services are very slow, or are
attached to slow networks, and it may not be unreasonable for a
normal connection through even a fast Tor circuit to take more than
fifteen seconds (the current timeout interval).
I suggest that we add a failure count to streams. Rather than
making them all wait 15 seconds to timeout and move to a new
circuit, there should be a progressive timeout schedule that allows
streams to migrate more quickly if they take too long to enter the
SUCCEEDED state, under the assumption that circuits for which the
transition takes too long are almost always undesirable anyway.
This approach provides a reactive mode of balancing load that
complements the proactive method of selecting nodes proportionally
to advertised bandwidth.
I recommend a timeout schedule of 5 seconds for the first try
followed by 10 and 15 seconds, respectively, for the next two
tries. This provides an (expected) 2-approximation of the current
timeout schedule for streams that take longer than five seconds
to succeed, and a potential improvement by a factor of three or
better for all those streams that happen to become attached to
circuits that simply do not work.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/298tor 0.1.20_CVS - make fails on contrib/suse2020-06-27T14:10:55ZTractor 0.1.20_CVS - make fails on contrib/suseParts of the automatic build scripts seem to be looking for contrib/suse which does not exist.
This causes the make script to fail with the following:
Making all in contrib
Making all in osx
cd .. && /bin/sh ./config.status contr...Parts of the automatic build scripts seem to be looking for contrib/suse which does not exist.
This causes the make script to fail with the following:
Making all in contrib
Making all in osx
cd .. && /bin/sh ./config.status contrib/torify
config.status: creating contrib/torify
cd . && /bin/sh /home/yancm/torsrc/missing --run automake-1.9 --foreign
contrib/Makefile.am:1: required directory contrib/suse does not exist
contrib/Makefile.am:2: required directory contrib/suse does not exist
configure.in:601: required file `contrib/suse/Makefile.in' not found
configure.in:601: required file `contrib/suse/tor.sh.in' not found
*** Error code 1
Stop.
make: stopped in /home/yancm/torsrc
*** Error code 1
Stop.
make: stopped in /home/yancm/torsrc
*** Error code 1
Stop.
make: stopped in /home/yancm/torsrc
[Automatically added by flyspray2trac: Operating System: BSD]
**Trac**:
**Username**: yancmhttps://gitlab.torproject.org/tpo/core/tor/-/issues/299crypto_global_init(): Initializing OpenSSL via tor_tls_init()2020-06-27T14:10:55ZRoger Dingledinecrypto_global_init(): Initializing OpenSSL via tor_tls_init()Jun 04 03:01:31.013 [warn] crypto_global_init(): Initializing OpenSSL via tor_tls_init().
We generate this warning on startup, when we follow certain codepaths that reach
tor_tls_init before they reach crypto_global_init. For example, i...Jun 04 03:01:31.013 [warn] crypto_global_init(): Initializing OpenSSL via tor_tls_init().
We generate this warning on startup, when we follow certain codepaths that reach
tor_tls_init before they reach crypto_global_init. For example, if we enable
hibernation, then we init_keys before we crypto_global_init.
Is this a bug? If so, we should cause crypto_global_init to be called earlier.
If not, we should downgrade the log severity.
[Automatically added by flyspray2trac: Operating System: All]0.1.1.21Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/300Tor server with eventdns enabled, lots of sigaction2020-06-27T14:10:55ZAndrew LewmanTor server with eventdns enabled, lots of sigactionA tor server 1.2.0-alpha-cvs from 2006-06-05, running under ppc osx, built using standard "dist-osx" process, seems to
consume 100% of a cpu whilst running. There are a lot of sigaction sequences such as this repeating throughout:
1...A tor server 1.2.0-alpha-cvs from 2006-06-05, running under ppc osx, built using standard "dist-osx" process, seems to
consume 100% of a cpu whilst running. There are a lot of sigaction sequences such as this repeating throughout:
1.
9032 tor CALL sigprocmask(0x1,0x4010dc,0)
2.
9032 tor RET sigprocmask 0
3.
9032 tor CALL sigaction(0x2,0xbffff148,0)
4.
9032 tor RET sigaction 0
5.
9032 tor CALL sigaction(0xf,0xbffff148,0)
6.
9032 tor RET sigaction 0
7.
9032 tor CALL sigaction(0xd,0xbffff148,0)
8.
9032 tor RET sigaction 0
9.
9032 tor CALL sigaction(0x1e,0xbffff148,0)
10.
9032 tor RET sigaction 0
11.
9032 tor CALL sigaction(0x1f,0xbffff148,0)
12.
9032 tor RET sigaction 0
13.
9032 tor CALL sigaction(0x1,0xbffff148,0)
14.
9032 tor RET sigaction 0
15.
9032 tor CALL sigaction(0x19,0xbffff148,0)
16.
9032 tor RET sigaction 0
17.
9032 tor CALL sigaction(0x14,0xbffff148,0)
18.
9032 tor RET sigaction 0
19.
9032 tor CALL sigprocmask(0x2,0x4010dc,0)
20.
9032 tor RET sigprocmask 0
21.
9032 tor CALL poll(0x4013f0,0x16,0x312)
22.
9032 tor RET poll 7
23.
9032 tor CALL sigprocmask(0x1,0x4010dc,0)
24.
9032 tor RET sigprocmask 0
25.
9032 tor CALL sigaction(0x2,0xbffff0e8,0)
26.
9032 tor RET sigaction 0
27.
9032 tor CALL sigaction(0xf,0xbffff0e8,0)
28.
9032 tor RET sigaction 0
29.
9032 tor CALL sigaction(0xd,0xbffff0e8,0)
30.
9032 tor RET sigaction 0
31.
9032 tor CALL sigaction(0x1e,0xbffff0e8,0)
32.
9032 tor RET sigaction 0
33.
9032 tor CALL sigaction(0x1f,0xbffff0e8,0)
34.
9032 tor RET sigaction 0
35.
9032 tor CALL sigaction(0x1,0xbffff0e8,0)
36.
9032 tor RET sigaction 0
37.
9032 tor CALL sigaction(0x19,0xbffff0e8,0)
38.
9032 tor RET sigaction 0
39.
9032 tor CALL sigaction(0x14,0xbffff0e8,0)
40.
9032 tor RET sigaction 0
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]https://gitlab.torproject.org/tpo/core/tor/-/issues/301OSX 10.4 Tiger distribution installs on 10.3 Panther without warning2020-06-27T14:10:55ZTracOSX 10.4 Tiger distribution installs on 10.3 Panther without warningWhen downloading the Tor installation package, it is very possible to select the wrong one for your OS.
In downloading the Tor distribution with the Vidalia interface for OSX 10.4 (Tiger) (http://www.vidalia-project.net/dist/vidalia-bund...When downloading the Tor installation package, it is very possible to select the wrong one for your OS.
In downloading the Tor distribution with the Vidalia interface for OSX 10.4 (Tiger) (http://www.vidalia-project.net/dist/vidalia-bundle-0.1.1.21-0.0.5-2.dmg), then running the install, the installation program does not check to see if it is being run on a OSX 10.4 machine.
The install interface in this package looks exactly like the standard Apple install interface, which normally will check your OS version and stop you from installing if it is not correct.
Trying to run Tor for OSX 10.4 in OSX 10.3 from within Vidallia gives an error window that states Tor failed to start and to check the Message window for details.
The message window remains blank - no messages were recorded.
Running Tor (OSX 10.4) in OSX 10.3.x from the command line gives this error:
geep:~ root# tor
dyld: tor Undefined symbols:
tor undefined reference to ___stderrp expected to be defined in /usr/lib/libSystem.B.dylib
tor undefined reference to ___stdinp expected to be defined in /usr/lib/libSystem.B.dylib
Trace/BPT trap
No other messages or notices are recorded.
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]
**Trac**:
**Username**: dosboss0.1.1.21Andrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/tpo/core/tor/-/issues/303prevent single-hop proxy usage2020-06-27T14:10:54Zgoodellprevent single-hop proxy usageControllers that allow Tor clients to use Tor servers as single-hop
proxies present a danger to the Tor network. This use not only
reduces the anonymity attained by the client but also creates new
incentives for adversaries to run malic...Controllers that allow Tor clients to use Tor servers as single-hop
proxies present a danger to the Tor network. This use not only
reduces the anonymity attained by the client but also creates new
incentives for adversaries to run malicious Tor servers, compromise
existing Tor servers, or request logs from Tor servers.
Nevertheless, some users of the Tor network may have an incentive
to use Tor servers in this manner. Those users include (a) those
who are interested in anonymity from the server but not from the
network and (b) those who want to use Tor as a perspective access
network but do not care about anonymity.
Servers can defend against this particular attack by requiring
that for any given circuit extension request it receives, either
(a) the host from which the request was received OR (b) the
server to which the request will be extended is a valid Tor
server. This assures that each circuit involving this server
includes at least two Tor servers (though the first may actually
be a client).
To my knowledge, there is no way for servers to ensure that they
are only carrying circuits of length greater than two without
compromising some of the anonymity properties of the circuit.
This approach creates some new irregularities. For example, it
presumes that all servers have a (roughly) equivalent list of
all Tor servers. In particular, there will be a certain period
of time during which a new Tor server will not be accepted as
the second hop in a three-hop circuit while the other servers
learn about its existence.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/304Circuits being hijacked?2020-06-27T14:10:54ZTracCircuits being hijacked?
For all I know, this condition may be normal, but it seems odd to me and causes
me to wonder if some routers have been compromised or if circuits are being
hijacked.
First, I noticed that the Tor Detector sometimes reported that I was ...
For all I know, this condition may be normal, but it seems odd to me and causes
me to wonder if some routers have been compromised or if circuits are being
hijacked.
First, I noticed that the Tor Detector sometimes reported that I was connecting
from aala.MyLittleCorner.org (not sure if I remember the caps right), ip
149.9.0.25 -- which the detector said was _not_ a valid Tor router. To add to
the mystery, that router was supposedly configured as a middle-man only (reject
*:*) in the cached-routers file.
Alarmed, I added the fingerprint for that router to the ExcludeNodes in my torrc
file, cleared all the cache and state files, closed Tor, and re-started.
Surprise, that router was still sometimes being reported as my exit node by the
Tor detector and irc servers. Irc connections were extremely hard to come by
and short-lived.
The Tor Detector page mentioned the possibility of a "multi-homed" router.
Unable to find that term in the documentation, I decided to search the cache
files for similar ip addresses. I found a total of five routers for ip
149.9.*.* -- all of them running FreeBSD i386 and Tor 0.1.0.16:
router mauger 149.9.137.153 9001 0 9030
platform Tor 0.1.0.16 on FreeBSD i386
router donk3ypunch 149.9.25.222 9001 0 9030
platform Tor 0.1.0.16 on FreeBSD i386
router TheGreatSantini 149.9.92.194 9001 0 9030
platform Tor 0.1.0.16 on FreeBSD i38
router aala 149.9.0.25 9001 0 9030
platform Tor 0.1.0.16 on FreeBSD i386
router paxprivoso 149.9.205.73 9001 0 9030
platform Tor 0.1.0.16 on FreeBSD i386
I put *all* their fingerprints in the ExcludeNodes setting, and since then I
have not noticed the anomaly with Tor Detector, nor the unusual irc behavior.
I was using Tor 0.1.1.21 when I noticed phenomenon. It also occurred when I
experimented with 0.1.1.20 and 0.1.0.17.
Is this a problem or expected behavior?
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: anm_3418https://gitlab.torproject.org/tpo/core/tor/-/issues/305Tor uninstall script isn't binary2020-06-27T14:10:54ZAndrew LewmanTor uninstall script isn't binaryThe Tor_Uninstaller.applescript located in /Library/Tor should be shipped as a binary with pretty icon and world executable.
This would allow users to 1) find it; 2) uninstall Tor cleanly.
[Automatically added by flyspray2trac: Operatin...The Tor_Uninstaller.applescript located in /Library/Tor should be shipped as a binary with pretty icon and world executable.
This would allow users to 1) find it; 2) uninstall Tor cleanly.
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]0.1.1.x-finalAndrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/tpo/core/tor/-/issues/306tor servers not publishing dirport sometimes2020-06-27T14:10:54ZRoger Dingledinetor servers not publishing dirport sometimesWhen a Tor server finds its ORPort reachable, publishes a descriptor, and then finds
its DirPort reachable, does it then try to republish a new descriptor?
The operator of 1898 reports no.
[Automatically added by flyspray2trac: Operati...When a Tor server finds its ORPort reachable, publishes a descriptor, and then finds
its DirPort reachable, does it then try to republish a new descriptor?
The operator of 1898 reports no.
[Automatically added by flyspray2trac: Operating System: All]0.1.2.x-finalRoger DingledineRoger Dingledinehttps://gitlab.torproject.org/tpo/core/tor/-/issues/307Win XP tor crash2020-06-27T14:10:54ZTracWin XP tor crashUsing Windows XP Pro, SP2.
Tor: 0.1.1.21 (which isn't in the "reported version" drop down box on this bug reporter!)
It seems Tor is unhappy. First it crashed. Now it seems to have made vidalia unstable (because I can't right-click it's...Using Windows XP Pro, SP2.
Tor: 0.1.1.21 (which isn't in the "reported version" drop down box on this bug reporter!)
It seems Tor is unhappy. First it crashed. Now it seems to have made vidalia unstable (because I can't right-click it's taskbar icon), and when I try to run a new version of videlia I instantly get a:
"Vidalia detected Tor exiting unexpectedly"
This is the log from the start-up:
Jun 23 11:11:07:281 [Debug] conn_read_callback(): socket 1588 wants to read.
Jun 23 11:11:07:281 [Debug] conn_read_callback(): socket 1588 wants to read.
Jun 23 11:11:07:359 [Notice] Tor v0.1.1.21. This is experimental software. Do not rely on it for strong anonymity.
Jun 23 11:11:07:359 [Notice] Initialized libevent version 1.1a+imweasel using method win32. Good.
Jun 23 11:11:07:359 [Notice] connection_create_listener(): Opening Socks listener on 127.0.0.1:9050
Jun 23 11:11:07:359 [Warning] connection_create_listener(): Could not bind to 127.0.0.1:9050: Address already in use [WSAEADDRINUSE ]. Is Tor already running?
Jun 23 11:11:07:359 [Warning] Failed to parse/validate config: Failed to bind one of the listener ports.
Jun 23 11:11:07:359 [Error] tor_init(): Reading config failed--see warnings above. For usage, try -h.
This bug is probably because there's another version of vidalia/tor running that I can't shut down without killing using task-manager. Either way if you try to run a second version at the same time as the first it should die more gracefully.
You'd probably get more bug reports if you didn't force people create an account.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: Moriartyhttps://gitlab.torproject.org/tpo/core/tor/-/issues/308confused by clock skew, doesn't start [debian #354259]2020-06-27T14:10:54Zweasel (Peter Palfrader)confused by clock skew, doesn't start [debian #354259]> Hi!
> first thanks for your effort in tor! It's great! ...> Hi!
> first thanks for your effort in tor! It's great!
> from time to time I have my hw clock resetted back to 1904 if I leave my
> laptop without battery, tor gets confused and won't start:
>
> Jan 01 01:24:26.452 [notice] Tor 0.1.1.12-alpha opening log file.
> [...working normally here...]
> Jan 01 01:24:28.608 [warn] router_set_networkstatus(): Network status
> from directory server "moria1" at 18.244.0
> .188:9031 was published in the future (2006-02-24 12:05:52 GMT).
> Somebody is skewed here: check your clock. Not
> caching.
>
> but warping the clock to the future isn't liked by tor who eats almost
> all the cpu. Then I try to restart it:
>
> Feb 24 14:41:09.619 [notice] Tor 0.1.1.12-alpha opening log file.
> Feb 24 14:41:09.619 [warn] parse_iso_time(): Got invalid ISO time
> "1904-01-01 00:39:26". (Before 1970)
> Feb 24 14:41:09.620 [warn] Invalid time '1904-01-01 00:39:26' for
> keyword 'BWHistoryReadEnds'
> Feb 24 14:41:09.620 [err] set_options(): Acting on config options left
> us in a broken state. Dying.
>
> that is, it stores dates it can't parse back :)
Ooops, I'm sorry I have missed this bug report. I'm forwarding it to
the developers for their attention.
tor-bugs, please CC 354259@bugs.debian.org on future mails about that
bug.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/309New routerlist.c assert in Tor cvs2020-06-27T14:10:54ZTracNew routerlist.c assert in Tor cvsI've had a couple of crashes on tor server clarity. I update from cvs daily.
Crashes started occuring about 6/21 or 6/22? Tor runs for about
24-36 hours before the crash.
(Sorry about the mistaken cvs update bug report...I knew better!)...I've had a couple of crashes on tor server clarity. I update from cvs daily.
Crashes started occuring about 6/21 or 6/22? Tor runs for about
24-36 hours before the crash.
(Sorry about the mistaken cvs update bug report...I knew better!)
Debug output and version info:
clarity 96 -> gdb /usr/local/bin/tor tor.core
GNU gdb 5.3nb1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386--netbsdelf"...
Core was generated by `tor'.
Program terminated with signal 6, Aborted.
Reading symbols from /usr/libexec/ld.elf_so...done.
Loaded symbols for /usr/libexec/ld.elf_so
Reading symbols from /usr/pkg/lib/libz.so.1...done.
Loaded symbols for /usr/pkg/lib/libz.so.1
Reading symbols from /usr/lib/libssl.so.3...done.
Loaded symbols for /usr/lib/libssl.so.3
Reading symbols from /usr/lib/libcrypto.so.2...done.
Loaded symbols for /usr/lib/libcrypto.so.2
Reading symbols from /usr/pkg/lib/libevent-1.1a.so.1...done.
Loaded symbols for /usr/pkg/lib/libevent-1.1a.so.1
Reading symbols from /usr/lib/libc.so.12...done.
Loaded symbols for /usr/lib/libc.so.12
#0 0x4822ffeb in kill () from /usr/lib/libc.so.12
(gdb) bt
#0 0x4822ffeb in kill () from /usr/lib/libc.so.12
#1 0x482a4a3f in abort () from /usr/lib/libc.so.12
legacy/trac#2 0x0808b819 in signed_descriptor_get_body (desc=0x9483540)
at routerlist.c:1165
legacy/trac#3 0x08089ea9 in router_rebuild_store (force=0) at routerlist.c:250
legacy/trac#4 0x0808d70e in router_load_routers_from_string (s=0x9867f95 "",
saved_location=SAVED_NOWHERE, requested_fingerprints=0x8d18c60)
at routerlist.c:2030
legacy/trac#5 0x08071200 in connection_dir_client_reached_eof (conn=0x953bc00)
at directory.c:1079
legacy/trac#6 0x080719d3 in connection_dir_reached_eof (conn=0x953bc00)
at directory.c:1201
legacy/trac#7 0x08060d6a in connection_handle_read (conn=0x953bc00) at connection.c:1228
legacy/trac#8 0x0807b9e7 in conn_read_callback (fd=27, event=2, _conn=0x953bc00)
at main.c:407
legacy/trac#9 0x48210988 in event_process_active () from /usr/pkg/lib/libevent-1.1a.so.1
legacy/trac#10 0x48210bee in event_base_loop () from /usr/pkg/lib/libevent-1.1a.so.1
legacy/trac#11 0x48210a77 in event_loop () from /usr/pkg/lib/libevent-1.1a.so.1
legacy/trac#12 0x482109b6 in event_dispatch () from /usr/pkg/lib/libevent-1.1a.so.1
legacy/trac#13 0x0807cc38 in do_main_loop () at main.c:1157
legacy/trac#14 0x0807d82d in tor_main (argc=7, argv=0xbfbffb1c) at main.c:2132
legacy/trac#15 0x08094f97 in main (argc=7, argv=0xbfbffb1c) at tor_main.c:22
legacy/trac#16 0x0804c072 in ___start ()
clarity 97 -> tor -V
Jun 25 11:58:23.175 [notice] Tor v0.1.2.0-alpha-cvs. This is experimental software. Do not rely on it for strong anonymity.
Jun 25 07:58:23.210 [warn] config_get_commandlines(): Command-line option '-V' with no value. Failing.
Jun 25 07:58:23.211 [err] tor_init(): Reading config failed--see warnings above.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: yancmNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/311dirservers not zlibbing descriptors correctly2020-06-27T14:10:53ZRoger Dingledinedirservers not zlibbing descriptors correctlyJun 28 09:53:32.816 [debug] read_to_buf_impl(): Encountered eof
Jun 28 09:53:32.816 [debug] fetch_from_buf_http(): headerlen 123, bodylen 6436.
Jun 28 09:53:32.816 [debug] connection_dir_client_reached_eof(): Received response from direc...Jun 28 09:53:32.816 [debug] read_to_buf_impl(): Encountered eof
Jun 28 09:53:32.816 [debug] fetch_from_buf_http(): headerlen 123, bodylen 6436.
Jun 28 09:53:32.816 [debug] connection_dir_client_reached_eof(): Received response from directory server '86.59.21.38:80': 200 "OK"
Jun 28 09:53:32.816 [debug] connection_dir_client_reached_eof(): Time on received directory is within tolerance; we are 0 seconds skewed. (That's okay.)
Jun 28 09:53:32.816 [info] tor_gzip_uncompress(): possible truncated or corrupt zlib data
Jun 28 09:53:32.816 [info] connection_dir_client_reached_eof(): Unable to decompress HTTP body (server '86.59.21.38:80').
Jun 28 09:53:32.816 [debug] conn_close_if_marked(): Cleaning up connection (fd 706).
Jun 28 09:53:32.816 [debug] router_set_status(): Marking router 'tor26' as down.
Jun 28 09:53:32.816 [info] connection_dir_request_failed(): Giving up on directory server at '86.59.21.38'; retrying
This is occuring on tor26 and moria2, both of which are running recent cvs.
[Automatically added by flyspray2trac: Operating System: All]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/312100% CPU Usage2020-06-27T14:10:53ZTrac100% CPU UsageWhen used in conjunction with Azureus, tor continuously uses 100% of the CPU. Stopping and starting tor will halt the CPU usage for a few minutes, but the problem inevitably returns.
OS: Windows XP SP2
CPU: AMD Athlon 64 3500+ (NewCast...When used in conjunction with Azureus, tor continuously uses 100% of the CPU. Stopping and starting tor will halt the CPU usage for a few minutes, but the problem inevitably returns.
OS: Windows XP SP2
CPU: AMD Athlon 64 3500+ (NewCastle)
Azureus: 2.4.0.2
Vidalia: 0.0.5
Tor: 0.1.1.21
Qt: 4.1.0
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: aaronsells