Could not get traffic out via socks using a config that works fine with tor-0.2.3.2_alpha-r2 The log file complains about time outs on a socket. I checked the traffic and the circuit was being established, yet the problem was with the socks-polipo connection. Reproducible: Always Steps to Reproduce: 1. emerge net-misc/ tor-0.2.3.2_alpha-r2 2. try to use socks to connect via tor 3. fails to connect.
Attach that logs and post "emerge --info" output please
emerge --info Portage 2.1.10.9 (unavailable, gcc-4.5.2, glibc-2.13-r4, 3.0.0 x86_64) ================================================================= System uname: Linux-3.0.0-x86_64-Intel-R-_Core-TM-_i5-2400_CPU_@_3.10GHz-with-gentoo-2.0.3 Timestamp of tree: Unknown dev-lang/python: 2.7.2-r2::gentoo, 3.2-r2::gentoo sys-devel/autoconf: 2.13::gentoo, 2.68::gentoo sys-devel/automake: 1.11.1-r1::gentoo sys-devel/binutils: 2.21.1::gentoo sys-devel/libtool: 2.4-r1::gentoo sys-kernel/linux-headers: 2.6.38::gentoo (virtual/os-headers) Repositories: x-portage ACCEPT_KEYWORDS="~amd64" ACCEPT_LICENSE="* -@EULA" CFLAGS="-O2 -march=core2 -mssse3 -msse4.1 -msse4.2 -mcx16 -msahf -maes -mpclmul -mpopcnt -mavx -mtune=core2 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=6144 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -march=core2 -mssse3 -msse4.1 -msse4.2 -mcx16 -msahf -maes -mpclmul -mpopcnt -mavx -mtune=core2 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=6144 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests binpkg-logs distlocks ebuild-locks fixlafiles fixpackages metadata-transfer news nodoc noinfo notitles parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch usersync webrsync-gpg" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/usr/portage/distfiles" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amr apng directfb egl ffmpeg fontconfig gnutls graphite gsm lto mmx mmx2 network policykit pulseaudio sasl sqlite sse sse2 sse3 sse4 sse4_1 sse4_2 threads vaapi video x264 xinerama xvmc" Unset: EMERGE_DEFAULT_OPTS, PORTAGE_BUNZIP2_COMMAND
The new line is the bug line after the circuit is establish, 15 seconds after startup. This is from a torify wget Aug 02 20:34:08.000 [notice] Catching signal TERM, exiting cleanly. Aug 02 20:38:50.000 [notice] Tor 0.2.3.2-alpha (git-bceb136840815bf5) opening log file. Aug 02 20:38:50.000 [notice] Parsing GEOIP file /usr/share/tor/geoip. Aug 02 20:38:51.000 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now. Aug 02 20:38:51.000 [notice] OpenSSL OpenSSL 1.0.0d 8 Feb 2011 looks like version 0.9.8m or later; I will try SSL_OP to enable renegotiation Aug 02 20:38:51.000 [notice] Your Tor server's identity key fingerprint is 'Unnamed E70404689DAD53C8481AF6CBCCBA5DEF63C00F0F' Aug 02 20:38:51.000 [notice] Reloaded microdescriptor cache. Found 0 descriptors. Aug 02 20:38:51.000 [notice] I learned some more directory information, but not enough to build a circuit: We have no usable consensus. Aug 02 20:38:51.000 [notice] Guessed our IP address as 77.186.91.192 (source: 213.115.239.118). Aug 02 20:38:52.000 [notice] Heartbeat: Tor's uptime is 0:00 hours, with 0 circuits open. I've pushed 0 kB and received 0 kB. Aug 02 20:38:52.000 [notice] We're missing a certificate from authority with signing key 3509BA5A624403A905C74DA5C8A0CEC9E0D3AF86: launching request. Aug 02 20:38:52.000 [notice] We're missing a certificate from authority with signing key CFBA08742B80559FD8C823F49939F5F9DC0D68FD: launching request. Aug 02 20:38:52.000 [notice] We're missing a certificate from authority with signing key 8936BDA972B6C9A5C9DEC71A18134749F903A6AA: launching request. Aug 02 20:38:52.000 [notice] We're missing a certificate from authority with signing key 9A54297F29061CDBB677BEE2E4EE2E22672CDE6E: launching request. Aug 02 20:38:52.000 [notice] We're missing a certificate from authority with signing key EEB9299D295C1C815E289FBF2F2BBEA5F52FDD19: launching request. Aug 02 20:38:52.000 [notice] We're missing a certificate from authority with signing key F7C7B9191C74C0BA07363C84D37BBAD3A8A6C6D8: launching request. Aug 02 20:38:52.000 [notice] We're missing a certificate from authority with signing key 2B83C6BE3EC75E91270444DAE41F80A9EFD38912: launching request. Aug 02 20:38:52.000 [notice] We're missing a certificate from authority with signing key 604834622B54F2D9BA39B34AC53924546733AA60: launching request. Aug 02 20:38:52.000 [notice] We're missing a certificate from authority with signing key 5686BC9F510BF2CAAE35DB781A6F641620EB4E96: launching request. Aug 02 20:38:52.000 [notice] We're missing a certificate from authority with signing key 8C58F67FE9404A6E984DA4B1D8F8A737FB7F3B5D: launching request. Aug 02 20:38:52.000 [notice] I learned some more directory information, but not enough to build a circuit: We have no usable consensus. Aug 02 20:38:53.000 [notice] I learned some more directory information, but not enough to build a circuit: We have no usable consensus. Aug 02 20:38:53.000 [notice] Bootstrapped 45%: Asking for relay descriptors. Aug 02 20:38:53.000 [notice] I learned some more directory information, but not enough to build a circuit: We have only 0/2636 usable descriptors. Aug 02 20:38:55.000 [notice] Bootstrapped 53%: Loading relay descriptors. Aug 02 20:38:55.000 [notice] I learned some more directory information, but not enough to build a circuit: We have only 83/2636 usable descriptors. Aug 02 20:38:55.000 [notice] Bootstrapped 55%: Loading relay descriptors. Aug 02 20:38:55.000 [notice] I learned some more directory information, but not enough to build a circuit: We have only 128/2636 usable descriptors. Aug 02 20:38:56.000 [notice] Bootstrapped 59%: Loading relay descriptors. Aug 02 20:38:56.000 [notice] I learned some more directory information, but not enough to build a circuit: We have only 224/2636 usable descriptors. Aug 02 20:38:56.000 [notice] Bootstrapped 61%: Loading relay descriptors. Aug 02 20:38:56.000 [notice] I learned some more directory information, but not enough to build a circuit: We have only 256/2636 usable descriptors. Aug 02 20:38:56.000 [notice] Bootstrapped 65%: Loading relay descriptors. Aug 02 20:38:56.000 [notice] I learned some more directory information, but not enough to build a circuit: We have only 352/2636 usable descriptors. Aug 02 20:38:56.000 [notice] Bootstrapped 66%: Loading relay descriptors. Aug 02 20:38:56.000 [notice] I learned some more directory information, but not enough to build a circuit: We have only 384/2636 usable descriptors. Aug 02 20:38:56.000 [notice] Bootstrapped 71%: Loading relay descriptors. Aug 02 20:38:56.000 [notice] I learned some more directory information, but not enough to build a circuit: We have only 479/2636 usable descriptors. Aug 02 20:38:56.000 [notice] Bootstrapped 75%: Loading relay descriptors. Aug 02 20:38:56.000 [notice] I learned some more directory information, but not enough to build a circuit: We have only 575/2636 usable descriptors. Aug 02 20:38:56.000 [notice] I learned some more directory information, but not enough to build a circuit: We have only 579/2636 usable descriptors. Aug 02 20:38:56.000 [notice] We now have enough directory information to build circuits. Aug 02 20:38:56.000 [notice] Bootstrapped 80%: Connecting to the Tor network. Aug 02 20:39:00.000 [notice] Bootstrapped 85%: Finishing handshake with first hop. Aug 02 20:39:01.000 [notice] Bootstrapped 90%: Establishing a Tor circuit. Aug 02 20:39:16.000 [warn] fetch_from_evbuffer_socks(): Bug: We seem to be caught in a parse loop; breaking out Aug 02 20:39:50.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Aug 02 20:39:54.000 [notice] Catching signal TERM, exiting cleanly.
(In reply to comment #3) And some strace output on the tor server. Sorry, I don't really have time to debug this actual app. Just mark it as not working and send upstream. socket(PF_INET, SOCK_STREAM|SOCK_CLOEXEC, IPPROTO_TCP) = 21 fcntl(21, F_SETFL, O_RDONLY|O_NONBLOCK) = 0 setsockopt(21, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 connect(21, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("91.208.34.19")}, 16) = -1 EINPROGRESS (Operation now in progress) epoll_ctl(3, EPOLL_CTL_ADD, 21, {EPOLLIN|EPOLLOUT, {u32=21, u64=21}}) = 0 epoll_wait(3, {{EPOLLOUT, {u32=21, u64=21}}}, 32, 320) = 1 getsockopt(21, SOL_SOCKET, SO_ERROR, [0], [4]) = 0 writev(21, [{"GET /tor/server/authority.z HTTP"..., 60}], 1) = 60 epoll_ctl(3, EPOLL_CTL_MOD, 21, {EPOLLIN, {u32=21, u64=21}}) = 0 epoll_wait(3, {}, 32, 277) = 0 epoll_wait(3, {{EPOLLIN, {u32=8, u64=8}}}, 32, 333) = 1 accept4(8, {sa_family=AF_INET, sin_port=htons(43567), sin_addr=inet_addr("127.0.0.1")}, [16], SOCK_CLOEXEC) = 24 setsockopt(24, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 fcntl(24, F_SETFL, O_RDONLY|O_NONBLOCK) = 0 epoll_ctl(3, EPOLL_CTL_ADD, 24, {EPOLLIN, {u32=24, u64=24}}) = 0 epoll_wait(3, {{EPOLLIN, {u32=24, u64=24}}}, 32, 211) = 1 ioctl(24, FIONREAD, [24]) = 0 readv(24, [{"\4\360\0\0\0\0\0\1\0www.gentoo.org\0", 24}], 1) = 24 epoll_wait(3, {}, 32, 211) = 0 epoll_wait(3, {}, 32, 333) = 0 epoll_wait(3, {}, 32, 12) = 0 epoll_wait(3, {}, 32, 320) = 0 epoll_wait(3, {}, 32, 333) = 0 epoll_wait(3, {}, 32, 333) = 0 epoll_wait(3, {}, 32, 13) = 0 socket(PF_INET, SOCK_STREAM|SOCK_CLOEXEC, IPPROTO_TCP) = 25 fcntl(25, F_SETFL, O_RDONLY|O_NONBLOCK) = 0 setsockopt(25, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 connect(25, {sa_family=AF_INET, sin_port=htons(9001), sin_addr=inet_addr("213.163.64.43")}, 16) = -1 EINPROGRESS (Operation now in progress) epoll_ctl(3, EPOLL_CTL_ADD, 25, {EPOLLIN|EPOLLOUT, {u32=25, u64=25}}) = 0 epoll_wait(3, {{EPOLLOUT, {u32=25, u64=25}}}, 32, 320) = 1 getsockopt(25, SOL_SOCKET, SO_ERROR, [0], [4]) = 0 epoll_ctl(3, EPOLL_CTL_MOD, 25, {EPOLLIN|EPOLLOUT, {u32=25, u64=25}}) = 0 epoll_wait(3, {{EPOLLOUT, {u32=25, u64=25}}}, 32, 272) = 1 write(25, "\26\3\1\0\314\1\0\0\310\3\1N8E.[\205\24M\313\200M\207\4\275\207.c%\221\370\256"..., 209) = 209 read(25, 0x2f3d310, 7) = -1 EAGAIN (Resource temporarily unavailable) epoll_ctl(3, EPOLL_CTL_MOD, 25, {EPOLLIN, {u32=25, u64=25}}) = 0 epoll_wait(3, {{EPOLLIN, {u32=25, u64=25}}}, 32, 271) = 1 read(25, "\26\3\1\0001\2\0", 7) = 7 read(25, "\0-\3\1N8E.\304\226M\367\302T\f\203P\25\367\303\315\331c\250\16\333\300]\253\232>\27"..., 47) = 47 read(25, "\26\3\1\1\302", 5) = 5 read(25, "\v\0\1\276\0\1\273\0\1\2700\202\1\2640\202\1\35\240\3\2\1\2\2\4N8@\2160\r\6"..., 450) = 450 read(25, "\26\3\1\1\215", 5) = 5 read(25, "\f\0\1\211\0\200\326}\344@\313\273\334\0316\326\223\323J\375\n\325\f\204\3229\244_R\v\270\201"..., 397) = 397 read(25, "\26\3\1\0\4", 5) = 5 read(25, "\16\0\0\0", 4) = 4 write(25, "\26\3\1\0\206\20\0\0\202\0\200\276do\220\4\262\312\263\262_\6\3603\t0\214Oc\216\17\373"..., 198) = 198 read(25, 0x2f3d313, 5) = -1 EAGAIN (Resource temporarily unavailable) epoll_wait(3, {{EPOLLIN, {u32=25, u64=25}}}, 32, 221) = 1 read(25, "\24\3\1\0\1", 5) = 5 read(25, "\1", 1) = 1 read(25, "\26\3\1\0000", 5) = 5 read(25, "\253}q+!\357\356\277W\351Lr:!\327\306\240p\337\244\267\363y\350\326\20\\\223\273\344n\211"..., 48) = 48 write(25, "\26\3\1\0\300\271\301\251\263\374\265\340\265\2339\311o\323c$^\340!\253\307\306\36A\276f\300."..., 197) = 197 read(25, 0x2f3d313, 5) = -1 EAGAIN (Resource temporarily unavailable) epoll_ctl(3, EPOLL_CTL_MOD, 25, {EPOLLIN, {u32=25, u64=25}}) = 0 epoll_wait(3, {{EPOLLIN, {u32=25, u64=25}}}, 32, 171) = 1 read(25, "\26\3\1\0`", 5) = 5 read(25, "s\21\30bd!9{\316\324@\34\367~d'~\363\r\321W\220^5\320\233U\36\232\202\v\""..., 96) = 96 read(25, "\26\3\1\3\240", 5) = 5 read(25, "\1\r\307\340\321M\352w\312\340w\260L\207f\272\10't#\224\250\202\26\316\0070\373\300()\233"..., 928) = 928 read(25, "\26\3\1\1\260", 5) = 5 read(25, "\4\261\2029\252\351\204\216\241!*\305\256\363\205L\224\356\264 \0058\320\v\251\360\335R0\256\353H"..., 432) = 432 read(25, "\26\3\1\0000", 5) = 5 read(25, "\r\271\376\3654\215\274\366\264\364j\377\240\347\237v\242\36\333\313nq\316\342\33\3\17f\251\356\0\267"..., 48) = 48 write(25, "\26\3\1\3\240Bb\361\364\4\"$\372\302\261`|z\356\177\21\37\233\210{Rc\323\7\370/\6"..., 1353) = 1353 read(25, 0x2f3d313, 5) = -1 EAGAIN (Resource temporarily unavailable) epoll_wait(3, {{EPOLLIN, {u32=25, u64=25}}}, 32, 118) = 1 read(25, "\24\3\1\0 ", 5) = 5 read(25, "\376n0\226\33\204\370\223\245Y\16j\24\225\221\33\301\337\fx$0\266GIG\246QK\311\237\267", 32) = 32 read(25, "\26\3\1\0000", 5) = 5 read(25, "\363v\343\17-\2712\275aW\341\337\204\277\356w\313\26\350X\343\256\30`]\323\230\23\363\356!\370"..., 48) = 48 epoll_ctl(3, EPOLL_CTL_MOD, 25, {EPOLLIN, {u32=25, u64=25}}) = 0 epoll_wait(3, {}, 32, 56) = 0 epoll_wait(3, {}, 32, 333) = 0 epoll_wait(3, {}, 32, 333) = 0 epoll_wait(3, {}, 32, 13) = 0 epoll_wait(3, {}, 32, 320) = 0 epoll_wait(3, {}, 32, 329) = 0 epoll_wait(3, {{EPOLLIN, {u32=21, u64=21}}}, 32, 333) = 1 ioctl(21, FIONREAD, [1110]) = 0 readv(21, [{"HTTP/1.0 200 OK\r\nDate: Tue, 02 A"..., 1110}], 1) = 1110 epoll_wait(3, {{EPOLLIN, {u32=21, u64=21}}}, 32, 251) = 1 ioctl(21, FIONREAD, [0]) = 0 readv(21, [{"\0\0\220MZ\2\0\0\0\0\320NZ\2\0\0\0\0 OZ\2\0\0\0\0\300OZ\2\0\0"..., 890}, {"0\33Z\2\0\0\0\0\200\33Z\2\0\0\0\0\320\33Z\2\0\0\0\0000\35Z\2\0\0\0\0"..., 3206}], 2) = 0 uname({sys="Linux", node="qc", ...}) = 0 socket(PF_NETLINK, SOCK_RAW, 0) = 26 bind(26, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 0 getsockname(26, {sa_family=AF_NETLINK, pid=19080, groups=00000000}, [12]) = 0 sendto(26, "\24\0\0\0\26\0\1\3/E8N\0\0\0\0\0\0\0\0", 20, 0, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 20 recvmsg(26, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"0\0\0\0\24\0\2\0/E8N\210J\0\0\2\10\200\376\1\0\0\0\10\0\1\0\177\0\0\1"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 108 recvmsg(26, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"@\0\0\0\24\0\2\0/E8N\210J\0\0\n\200\200\376\1\0\0\0\24\0\1\0\0\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 128 recvmsg(26, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\24\0\0\0\3\0\2\0/E8N\210J\0\0\0\0\0\0\1\0\0\0\24\0\1\0\0\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 20 close(26) = 0 stat("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=51, ...}) = 0 open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 26 fstat(26, {st_mode=S_IFREG|0644, st_size=1234, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f69693e1000 read(26, "# /etc/hosts: Local Host Databas"..., 4096) = 1234 close(26) = 0 munmap(0x7f69693e1000, 4096) = 0 socket(PF_INET, SOCK_DGRAM|SOCK_CLOEXEC, IPPROTO_UDP) = 26 connect(26, {sa_family=AF_INET, sin_port=htons(9), sin_addr=inet_addr("18.0.0.1")}, 16) = 0 getsockname(26, {sa_family=AF_INET, sin_port=htons(43264), sin_addr=inet_addr("172.23.23.1")}, [16]) = 0 close(26) = 0 epoll_ctl(3, EPOLL_CTL_DEL, 21, {EPOLLIN, {u32=21, u64=21}}) = 0
(In reply to comment #3) > Aug 02 20:39:16.000 [warn] fetch_from_evbuffer_socks(): Bug: We seem to be > caught in a parse loop; breaking out > Aug 02 20:39:50.000 [notice] Interrupt: we have stopped accepting new > connections, and will shut down in 30 seconds. Interrupt again to exit now. > Aug 02 20:39:54.000 [notice] Catching signal TERM, exiting cleanly. fetch_from_evbuffer_socks looks like a problem in libevent. I'll push the debugging of the code, but I need to be able to reproduce it: 1) Can I have your torrc. Just mask out anything that might be sensitive info. 2) I need just the bottom of your "emerge --info tor" It'll give me the use flags. 3) I need to know what version of libevent you're using.
Sorry its in tor, not libevent, and its probably this https://trac.torproject.org/projects/tor/ticket/3615 which is fixed by the following commit https://gitweb.torproject.org/tor.git/commitdiff/553ae5dfb5f6bb49889b2b1735217dae803f92d7 If you feel comfortable applying the patch and testing if it fixes the warnings, let me know the results. I can include the patch or we can wait till the next version bump. (It is alpha after all.)
Thanks. I have tried this bug fix, and it did remove the warning from the log files. However, the problem is that it doesn't seem to establish a curcuit. The client side/tor appears to be ok, but with this alpha version no data goes through. As you can see from the logs, there is a timeout, although it was working perfectly previously. Initially, I thought that the ISP was blocking things, so I set up the bridges manually, but I think that there are more serious and fundamental bugs in this version. Here are the logs... Aug 07 17:16:57.000 [notice] Catching signal TERM, exiting cleanly. Aug 07 17:16:57.000 [notice] Tor 0.2.3.2-alpha (git-bceb136840815bf5) opening log file. Aug 07 17:16:57.000 [notice] Parsing GEOIP file /usr/share/tor/geoip. Aug 07 17:16:57.000 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now. Aug 07 17:16:57.000 [notice] OpenSSL OpenSSL 1.0.0d 8 Feb 2011 looks like version 0.9.8m or later; I will try SSL_OP to enable renegotiation Aug 07 17:16:57.000 [notice] Your Tor server's identity key fingerprint is 'Unnamed 6A3F8F930EACD1E83E1354538485171C074E5A5F' Aug 07 17:16:57.000 [notice] Reloaded microdescriptor cache. Found 0 descriptors. Aug 07 17:16:57.000 [notice] We now have enough directory information to build circuits. Aug 07 17:16:57.000 [notice] Bootstrapped 80%: Connecting to the Tor network. Aug 07 17:16:58.000 [notice] Bootstrapped 85%: Finishing handshake with first hop. Aug 07 17:16:58.000 [notice] Heartbeat: Tor's uptime is 0:00 hours, with 2 circuits open. I've pushed 1 kB and received 2 kB. Aug 07 17:18:57.000 [notice] Tried for 120 seconds to get a connection to [scrubbed]:80. Giving up. (waiting for circuit) Aug 07 17:19:04.000 [notice] Tried for 120 seconds to get a connection to [scrubbed]:80. Giving up. (waiting for circuit) > Sorry its in tor, not libevent, and its probably this > > https://trac.torproject.org/projects/tor/ticket/3615 > > which is fixed by the following commit > > > https://gitweb.torproject.org/tor.git/commitdiff/553ae5dfb5f6bb49889b2b1735217dae803f92d7 > > If you feel comfortable applying the patch and testing if it fixes the > warnings, let me know the results. I can include the patch or we can wait till > the next version bump. (It is alpha after all.)
And so on and on and on and on and on... ug 07 17:30:06.000 [warn] Problem bootstrapping. Stuck at 85%: Finishing handshake with first hop. (DONE; DONE; count 10; recommendation warn) Aug 07 17:30:06.000 [warn] 10 connections have failed: Aug 07 17:30:06.000 [warn] 10 connections died in state handshaking (Tor) with SSL state SSL_ST_OK Aug 07 17:31:07.000 [warn] Problem bootstrapping. Stuck at 85%: Finishing handshake with first hop. (DONE; DONE; count 11; recommendation warn) Aug 07 17:31:07.000 [warn] 11 connections have failed: Aug 07 17:31:07.000 [warn] 11 connections died in state handshaking (Tor) with SSL state SSL_ST_OK Aug 07 17:32:08.000 [warn] Problem bootstrapping. Stuck at 85%: Finishing handshake with first hop. (DONE; DONE; count 12; recommendation warn) Aug 07 17:32:08.000 [warn] 12 connections have failed: Aug 07 17:32:08.000 [warn] 12 connections died in state handshaking (Tor) with SSL state SSL_ST_OK Aug 07 17:33:09.000 [warn] Problem bootstrapping. Stuck at 85%: Finishing handshake with first hop. (DONE; DONE; count 13; recommendation warn) Aug 07 17:33:09.000 [warn] 13 connections have failed:
I can't get far with this since I can't reproduce it. Can you give me the information in comment 6.
(In reply to comment #9) > I can't get far with this since I can't reproduce it. Can you give me the > information in comment 6. Sorry, I meant comment 5.
I tried the vanilla unpatched version and it worked fine. So I took the ebuild version and had a look. I didn't bother trying to find the why or wherefores but in the patch tor-0.2.3.2_alpha-fix-asneeded.patch something didn't seem right. nat_pmp_ldadd was commented out in the line above. I have no idea what the shared code does, but b/tor-0.2.3.2-alpha/src/tools/tor-fw-helper/Makefile.am needs to have nat_pmp_ldadd = -lnatpmp if you are going to use the patch. ie. please uncomment the line #nat_pmp_ldadd = -lnatpmp in the abovementioned file.
This doesn't really inspire me with confidence: *-fix-asneeded.patch
(In reply to comment #9) > I can't get far with this since I can't reproduce it. Can you give me the > information in comment 6. I suspect given the name of the file and its location that you are not testing behind a firewall?
(In reply to comment #13) > (In reply to comment #9) > > I can't get far with this since I can't reproduce it. Can you give me the > > information in comment 6. > > I suspect given the name of the file and its location that you are not testing > behind a firewall? I did test behind a firewall. I'm confused as to what you are suggesting in Comment 11. Do you want to produce a patch. Also, I can't reproduce this without more information. Can you give me the information in Comment 5 and also tell me what sort of networking environment you are using.
Quite interestingly it is trying to us uPnp, even though I have the ports forwared manually on uPnP. But that library, is from its name, trying to use nat-pmp. Should I dump port 1900 udp? If I add that library it works fine and the port discovery works. Take it out and it fails. (In reply to comment #14) > (In reply to comment #13) > > (In reply to comment #9) > > > I can't get far with this since I can't reproduce it. Can you give me the > > > information in comment 6. > > > > I suspect given the name of the file and its location that you are not testing > > behind a firewall? > > I did test behind a firewall. > > I'm confused as to what you are suggesting in Comment 11. Do you want to > produce a patch. > > Also, I can't reproduce this without more information. Can you give me the > information in Comment 5 and also tell me what sort of networking environment > you are using.
I am hitting the bug, as mentioned in comment #8. It's possible the problem started before I upgraded to this version of tor (perhaps after other peers upgraded to it), and continued after I upgraded to it. It was working a few days ago, at least.
(In reply to comment #16) > I am hitting the bug, as mentioned in comment #8. It's possible the problem > started before I upgraded to this version of tor (perhaps after other peers > upgraded to it), and continued after I upgraded to it. It was working a few > days ago, at least. Can you please give me the information I asked for in comment #5.
dev-libs/libevent-2.0.12 USE="bufferevents threads -doc -nat-pmp -tor-hardening -transparent-proxy -upnp" User tor Group tor PIDFile /var/run/tor/tor.pid Log notice file /var/log/tor/tor.log DataDirectory /var/lib/tor/data BandwidthRate 40 KB BandwidthBurst 42 KB BridgeRelay 1 ExitPolicy reject *:*
(In reply to comment #18) > dev-libs/libevent-2.0.12 > > USE="bufferevents threads -doc -nat-pmp -tor-hardening -transparent-proxy > -upnp" > > User tor > Group tor > PIDFile /var/run/tor/tor.pid > Log notice file /var/log/tor/tor.log > DataDirectory /var/lib/tor/data > BandwidthRate 40 KB > BandwidthBurst 42 KB > BridgeRelay 1 > ExitPolicy reject *:* Are you behind a NAT or does your bridge have a public IP?
I am behind a router/server, although I'm masqueraded, and I have the ports forwarded to me. Also, as I mentioned, it was working fine a few days ago, and it probably stopped working without any intervention on my part, I believe. I upgraded to see if it would resolve anything -- it didn't.
I seem to be able to connect/bootstrap fine with 0.2.2.30_rc-r1. Before it would get stuck at "90%": [warn] Problem bootstrapping. Stuck at 90%: Establishing a Tor circuit. (Network is unreachable; NOROUTE; count 4; recommendation warn) [warn] 3 connections have failed: [warn] 2 connections died in state handshaking (TLS) with SSL state SSL23_ST_CR_SRVR_HELLO_A [warn] 1 connections died in state handshaking (Tor) with SSL state SSL_ST_OK Looks like some kind of ssl problem?
(In reply to comment #21) > I seem to be able to connect/bootstrap fine with 0.2.2.30_rc-r1. > > Before it would get stuck at "90%": > > [warn] Problem bootstrapping. Stuck at 90%: Establishing a Tor circuit. > (Network is unreachable; NOROUTE; count 4; recommendation warn) > [warn] 3 connections have failed: > [warn] 2 connections died in state handshaking (TLS) with SSL state > SSL23_ST_CR_SRVR_HELLO_A > [warn] 1 connections died in state handshaking (Tor) with SSL state SSL_ST_OK > > Looks like some kind of ssl problem? I've been trying for a few days and I can't hit this with your config and network environment. I'll keep trying.
Fixed in net-misc/tor-0.2.2.31_rc. Thanks again.
Was it a problem upstream? And what about the 0.2.3.2 version(s)?
(In reply to comment #24) > Was it a problem upstream? And what about the 0.2.3.2 version(s)? That's exactly the point. It is a 2.3.2 problem and I want to push this upstream, but I can't reproduce it. I've tried several times. I don't want to just throws something upstream without giving them a better clue as to what's going on. The only thing we have is that it dies at SSL23_ST_CR_SRVR_HELLO_A. I'm going to reopen this since its about 2.3.2. The whole reason I put alpha/betas on the tree is so we can be a good downstream and do some testing for the tor devs. If you need stable, go with what's marked stable.
Can those of you who hit the bug test tor-0.2.3.3_alpha which I just added to the tree. If this is still a problem, I'll push the bug upstream with what little data we have.
0.2.3.3_alpha works for me with USE=-bufferevents. Otherwise, it will fail somewhere -- sometimes 85% into boostrapping, sometimes after 100% bootstrapping and after "Tor now sees network activity", but "Your server has not managed to confirm that it's ORPort is reachable".
ie. net-misc/tor-0.2.3.3_alpha USE="threads -bufferevents -doc -nat-pmp -tor-hardening -transparent-proxy -upnp"
Hmmm... it appears to work with bufferevents, with dev-libs/libevent-2.0.14 (but not older). Success!
(In reply to comment #29) > Hmmm... it appears to work with bufferevents, with dev-libs/libevent-2.0.14 > (but not older). Success! tor-0.2.3.3_alpha now depends on >=dev-libs/libevent-2.0.13. Can you test that USE="bufferevents" (which is on by default) and =dev-libs/libevent-2.0.13 fixes the problem as well as .14. If so, then I think we're done.
It doesn't work with =dev-libs/libevent-2.0.13. Only >= .14, I believe.
Yes, that seems to be it. Well done. > It doesn't work with =dev-libs/libevent-2.0.13. Only >= .14, I believe.
I will change the dependency to be on libevent-2.0.14 and pass this bug upstream for them to look at. BTW, the original summary "tor-0.2.3.2 doesn't work" is vague so I changed it. I know in this case you weren't originally able to be more specific when you first opened the bug. Thanks for the testing.
There was already a bug open against this at https://trac.torproject.org/projects/tor/ticket/3769
(In reply to comment #34) > There was already a bug open against this at > > https://trac.torproject.org/projects/tor/ticket/3769 On second look, the upstream error and this both end in the ssl handshake, but give a different report, so it may not be the same error. This bug ends with SSL23_ST_CR_SRVR_HELLO_A while upstreams ends with SSL3_ST_SR_CERT_A. I'll let upstream sort out if its due to do the same underlying cause or not.
