With the ORListenAddress line uncommented, a slightly different failure results:
Orbot is starting… Orbot is starting… got tor proc id: 28490 Tor process id=28490 Connecting to control port: 9051 SUCCESS connected to control port SUCCESS authenticated to control port Starting Tor client… complete. adding control port event handler SUCCESS added control port event handler Starting privoxy process /data/data/org.torproject.android/app_bin/privoxy /data/data/org.torproject.android/app_bin/privoxy.config & NOTICE: Heartbeat: Tor's uptime is 0:00 hours, with 0 circuits open. I've sent 0 kB and received 0 kB. Privoxy is running on port:8118 Privoxy process id=28508 Network connectivity is good. Waking Tor up... Circuit (1) LAUNCHED: NOTICE: Bootstrapped 5%: Connecting to directory server. orConnStatus (173.255.119.202:443): LAUNCHED NOTICE: Bootstrapped 10%: Finishing handshake with directory server. Circuit (1) FAILED: ONEHOP_TUNNEL > IS_INTERNAL > NEED_CAPACITY NOTICE: Your application (using socks4a to port 443) instructed Tor to take care of the DNS resolution itself if necessary. This is good. NOTICE: Your application (using socks4a to port 80) instructed Tor to take care of the DNS resolution itself if necessary. This is good. NOTICE: Your application (using socks4a to port 443) instructed Tor to take care of the DNS resolution itself if necessary. This is good. NOTICE: Your application (using socks4a to port 80) instructed Tor to take care of the DNS resolution itself if necessary. This is good. NOTICE: Your application (using socks4a to port 443) instructed Tor to take care of the DNS resolution itself if necessary. This is good. NOTICE: Your application (using socks4a to port 80) instructed Tor to take care of the DNS resolution itself if necessary. This is good. NOTICE: Your application (using socks4a to port 443) instructed Tor to take care of the DNS resolution itself if necessary. This is good. NOTICE: Tried for 120 seconds to get a connection to [scrubbed]:443. Giving up. (waiting for circuit) NOTICE: Your application (using socks4a to port 443) instructed Tor to take care of the DNS resolution itself if necessary. This is good. On Aug 15, 2013 1:41 AM, "lee colleton" <[email protected]> wrote: > When I attempt to connect to this bridge, I see a failure in handshaking: > > Orbot is starting… > Orbot is starting… > got tor proc id: 27365 > Tor process id=27365 > Connecting to control port: 9051 > SUCCESS connected to control port > SUCCESS authenticated to control port > Starting Tor client… complete. > adding control port event handler > SUCCESS added control port event handler > Starting privoxy process > /data/data/org.torproject.android/app_bin/privoxy > /data/data/org.torproject.android/app_bin/privoxy.config & > NOTICE: Heartbeat: Tor's uptime is 0:00 hours, with 0 circuits open. I've > sent 0 kB and received 0 kB. > Privoxy is running on port:8118 > Privoxy process id=27393 > Network connectivity is good. Waking Tor up... > Circuit (1) LAUNCHED: > NOTICE: Bootstrapped 5%: Connecting to directory server. > orConnStatus (173.255.119.202:443): LAUNCHED > NOTICE: Bootstrapped 10%: Finishing handshake with directory server. > NOTICE: We weren't able to find support for all of the TLS ciphersuites > that we wanted to advertise. This won't hurt security, but it might make > your Tor (if run as a client) more easy for censors to block. > NOTICE: To correct this, use a more recent OpenSSL, built without > disabling any secure ciphers or features. > Circuit (1) FAILED: ONEHOP_TUNNEL > IS_INTERNAL > NEED_CAPACITY > orConnStatus (173.255.119.202:443): FAILED > WARN: Problem bootstrapping. Stuck at 10%: Finishing handshake with > directory server. (DONE; DONE; count 1; recommendation warn) > WARN: 1 connections have failed: > WARN: 1 connections died in state handshaking (TLS) with SSL state > SSLv2/v3 read server hello A in HANDSHAKE > NOTICE: Your application (using socks4a to port 80) instructed Tor to take > care of the DNS resolution itself if necessary. This is good. > NOTICE: Your application (using socks4a to port 443) instructed Tor to > take care of the DNS resolution itself if necessary. This is good. > NOTICE: Your application (using socks4a to port 80) instructed Tor to take > care of the DNS resolution itself if necessary. This is good. > On Aug 15, 2013 12:31 AM, "lee colleton" <[email protected]> wrote: > >> When I comment out the ORListenAddress line things look OK. >> >> # Listen on a port other than the one advertised in ORPort (that is, >> # advertise 443 but bind to 9001). >> #ORListenAddress 0.0.0.0:9001 >> >> Aug 15 06:52:50.000 [notice] Tor 0.2.4.16-rc (git-dcf6b6d7dda9ffbd) opening >> log file. >> Aug 15 06:52:50.000 [notice] We were built to run on a 64-bit CPU, with >> OpenSSL 1.0.1 or later, but with a version of OpenSSL that apparently lacks >> accelerated support for the NIST P-224 and P-256 groups. Building openssl >> with such support (using the enable-ec_nistp_64_gcc_128 option when >> configuring it) would make ECDH much faster. >> Aug 15 06:52:50.000 [notice] Your Tor server's identity key fingerprint is >> 'gcedemo 08C752E8E86EB5916574A8625030B0EC204EABB8' >> Aug 15 06:52:50.000 [notice] Configured hibernation. This interval began at >> 2013-08-15 00:00:00; the scheduled wake-up time was 2013-08-15 00:00:00; we >> expect to exhaust our quota for this interval around 2013-08-16 00:00:00; >> the next interval begins at 2013-08-16 00:00:00 (all times local) >> Aug 15 06:52:50.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip. >> Aug 15 06:52:50.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6. >> Aug 15 06:52:50.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 15 06:52:51.000 [notice] We now have enough directory information to >> build circuits. >> Aug 15 06:52:51.000 [notice] Bootstrapped 80%: Connecting to the Tor network. >> Aug 15 06:52:52.000 [notice] Bootstrapped 85%: Finishing handshake with >> first hop. >> Aug 15 06:52:53.000 [notice] Guessed our IP address as 173.255.119.202 >> (source: 38.229.70.33). >> Aug 15 06:52:53.000 [notice] Bootstrapped 90%: Establishing a Tor circuit. >> Aug 15 06:52:53.000 [notice] Registered server transport 'obfs3' at >> '0.0.0.0:40872' >> Aug 15 06:52:53.000 [notice] Registered server transport 'obfs2' at >> '0.0.0.0:52176' >> Aug 15 06:52:55.000 [notice] Tor has successfully opened a circuit. Looks >> like client functionality is working. >> Aug 15 06:52:55.000 [notice] Bootstrapped 100%: Done. >> Aug 15 06:52:55.000 [notice] Now checking whether ORPort 173.255.119.202:443 >> is reachable... (this may take up to 20 minutes -- look for log messages >> indicating success) >> Aug 15 06:53:04.000 [notice] New control connection opened. >> Aug 15 07:10:11.000 [notice] Self-testing indicates your ORPort is reachable >> from the outside. Excellent. Publishing server descriptor. >> >> >> >> On Wed, Aug 14, 2013 at 9:53 PM, lee colleton <[email protected]> wrote: >> >>> Yes, I've opened the ports in the Google Compute Engine (see below). >>> I'll follow up on their forum to make sure I've altered the firewall >>> properly. >>> >>> --lee >>> >>> lee@li388-156:~$ gcutil --service_version="v1beta15" >>> --project="colleton.net:tor-cloud" listfirewalls >>> +------------------------+---------------------------------------+---------+------------+-------------+-------------+ >>> | name | description | network >>> | source-ips | source-tags | target-tags | >>> +------------------------+---------------------------------------+---------+------------+-------------+-------------+ >>> | default-allow-internal | Internal traffic from default allowed | default >>> | 10.0.0.0/8 | | | >>> | default-ssh | SSH allowed from anywhere | default >>> | 0.0.0.0/0 | | | >>> | tor-obfsproxy | | default >>> | 0.0.0.0/0 | | obfsproxy | >>> +------------------------+---------------------------------------+---------+------------+-------------+-------------+ >>> lee@li388-156:~$ gcutil --service_version="v1beta15" >>> --project="colleton.net:tor-cloud" getfirewall tor-obfsproxy >>> +---------------+-------------------------------+ >>> | property | value | >>> +---------------+-------------------------------+ >>> | name | tor-obfsproxy | >>> | description | | >>> | creation-time | 2013-08-07T18:37:35.986-07:00 | >>> | network | default | >>> | source-ips | 0.0.0.0/0 | >>> | source-tags | | >>> | target-tags | obfsproxy | >>> | allowed | tcp: 443, 9001, 40872, 52176 | >>> +---------------+-------------------------------+ >>> lee@li388-156:~$ >>> >>> >>> >>> On Wed, Aug 14, 2013 at 9:19 PM, Roger Dingledine <[email protected]> wrote: >>> >>>> On Wed, Aug 14, 2013 at 09:08:03AM -0700, lee colleton wrote: >>>> > There's a more serious issue in that my server doesn't appear to be >>>> > reachable. I've opened tcp:443,9001 along with the two >>>> specifiedobfsproxy >>>> > ports >>>> > >>>> > Aug 14 15:26:58.000 [notice] Bootstrapped 100%: Done. >>>> > Aug 14 15:26:58.000 [notice] Now checking whether ORPort >>>> > 173.255.119.202:443 is reachable... (this may take up to 20 minutes >>>> -- >>>> > look for log messages indicating success) >>>> > Aug 14 15:28:00.000 [notice] New control connection opened. >>>> > Aug 14 15:46:56.000 [warn] Your server (173.255.119.202:443) has not >>>> > managed to confirm that its ORPort is reachable. Please check your >>>> > firewalls, ports, address, /etc/hosts file, etc. >>>> >>>> Well, that's because it's unreachable. (I just tried.) >>>> >>>> Can you try following the suggestion in the log message? >>>> >>>> --Roger >>>> >>>> -- >>>> tor-talk mailing list - [email protected] >>>> To unsusbscribe or change other settings go to >>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk >>>> >>> >>> >> -- tor-talk mailing list - [email protected] To unsusbscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
