Custom Query (25333 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (124 - 126 of 25333)

Ticket Resolution Summary Owner Reporter
#245 Fixed tcp connection rollover still buggy weasel
Description

<weasel> hmm, weird <weasel> tor26 uses 2500 FDs, but there are only 600 connections to its ORPort <arma> dir connections? <arma> kill -usr1 it and see what they are? :) <weasel> no, those are well below 50 <weasel> netstat suggests there are about 1700 connections from tor26 to other nodes <arma> 600 + 1700 + 50 + fudge = 2500 <weasel> yes, only 1700 is a bit much, isn't it? <weasel> there aren't that many routers :) <weasel> ouch <arma> ? <weasel> there's over 90 connections just to 140.247.62.121:9001 <weasel> (rodos) <weasel> bug? <arma> does each connection have a circuit open? <arma> or are all the circuits clustered on one or a few connections?

  • weasel USR1s tor

<arma> were they all born around the same time, or are they spaced evenly? <weasel> grr <weasel> they are all [scrubbed] :) <weasel> | Jan 22 22:37:26.798 [info] OR rodos [DFF1D66324E1CD02DC7A594EB7DC5F573CDDBDE0]: 93/93 good connections; uptime 118912/118912 sec (100.00%) <weasel> (it seems it never expired a single one of them tho) <arma> exciting. <weasel> there are several that don't have any connections, <arma> i keep oscillating between fixing this bug and creating new ones. <weasel> and also several that have connections <arma> you mean circuits <weasel> yes <arma> Jan 22 16:43:46.483 [notice] Average bandwidth: 288565965253/426289 = 676925 byt <arma> es/sec reading <arma> Jan 22 16:43:46.483 [notice] Average bandwidth: 377444609668/426289 = 885419 byt <arma> es/sec writing <arma> Jan 22 16:43:46.483 [notice] --------------- Dumping memory information: <arma> Jan 22 16:43:46.483 [notice] In buffers: 8255274 used/86016000 allocated (5803 c <arma> onns). <arma> Jan 22 16:43:46.483 [notice] In rephist: 4579240 used by 62619 Tors. <arma> Jan 22 16:43:46.483 [notice] In 605 live descriptors: 1485855 bytes. In 2247 ol <arma> d descriptors: 5706345 bytes. <weasel> 59 without circuits. 32 with circuits <weasel> most circuits any connection has is 17. then 11, 10, 8, 4, 4, 4, 4, 3, 3, 3, 3, 2, 2, 2, and the rest has 1 or 0 <arma> moria2 has 5803 conns open.

[Automatically added by flyspray2trac: Operating System: All]

#246 Not a bug segfault after upgrade to Openssl-0.9.8 mindcandy28
Description

After upgrading to Openssl-0.9.8, tor SegFaults when trying to establish a TLSv3 session. This bug exists in both current-stable, and .11-alpha and .12-alpha.

Relevent debug info : (tor compiled with --enable-debug)

Jan 25 10:32:02.287 [debug] connection_or_finished_connecting(): OR connect() to router at 82.165.233.43:9001 finished. Jan 25 10:32:02.287 [debug] connection_tls_start_handshake(): starting TLS handshake on fd 7 Jan 25 10:32:02.287 [debug] connection_tls_continue_handshake(): wanted read Jan 25 10:32:02.287 [debug] connection_tls_continue_handshake(): wanted read Jan 25 10:32:02.501 [debug] conn_read_callback(): socket 7 wants to read. Segmentation fault (core dumped)

stack backtrace :

#268 0x40066fd0 in ?? () from /usr/lib/libssl.so.0 #269 0x082a4a78 in ?? () #270 0x081c2120 in ?? () #271 0xbfdd26a8 in ?? () #272 0x4005485a in SSL_connect () from /usr/lib/libssl.so.0 #273 0x082a4a78 in ?? () #274 0x0825bbe8 in ?? () #275 0x082d5fe0 in ?? () #276 0x080be2eb in tor_tls_handshake (tls=0xbfdd23c4) at tortls.c:556 Previous frame inner to this frame (corrupt stack?)

OpenSSL version info :

OpenSSL 0.9.8a 11 Oct 2005 built on: Tue Jan 24 14:01:00 EST 2006 platform: linux-elf options: bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) idea(int) blowfish(idx) compiler: gcc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -mcpu=pentium -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM OPENSSLDIR: "/etc/ssl"

LDD info for TOR binary :

ldd /usr/local/bin/tor

libz.so.1 => /usr/lib/libz.so.1 (0x40026000) libssl.so.0 => /usr/lib/libssl.so.0 (0x40037000) libpthread.so.0 => /lib/libpthread.so.0 (0x40068000) libdl.so.2 => /lib/libdl.so.2 (0x400b9000) libevent-1.1a.so.1 => /usr/local/lib/libevent-1.1a.so.1 (0x400bd000) libc.so.6 => /lib/libc.so.6 (0x400c4000) libcrypto.so.0 => /usr/lib/libcrypto.so.0 (0x401f3000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

[Automatically added by flyspray2trac: Operating System: Other Linux]

#247 Not a bug Tor doesn't seem to work with Network configuration dedwards
Description

Running OS X 10.3.9 with Tor installed; Network settings pointing to Privoxy on 127.0.0.1, port 8118 for HTTP, HTTPS, and Gopher. Using Safari 1.3, Camino 1.0b1 and Firefox 1.5 with SwitchProxy and the browser's Connection settings pointing to Privoxy as well.

Connecting to ipid.shat.net/ using Safari or Camino shows an ip address in a different part of the country or world, as expected. Using Firefox 1.5 with SwitchProxy turned off (Network settings for OS X are still enabled), I get an ip address for my ISP, even though they're not running any Tor servers. If I use Network Utility to do a Whois lookup, it also says I'm coming from my ISP; same if I go to www.dnsstuff.com (Java and JavaScript are off). Turning on SwitchProxy (even while Network settings are enabled) and trying again gets me an IP address in a different part of the country or world, as it should be.

This makes no sense, and it doesn't inspire confidence, since I get different results depending on which browser I'm using. I followed the directions for installation and setup, so I can only presume it's a bug of some sort, perhaps with OS X, or Tor.

[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]

Note: See TracQuery for help on using queries.