-tor-relay +tor-relays
On Thu, Aug 15, 2013 at 10:13 AM, lee colleton <l...@colleton.net> wrote: > All of the ports respond on the external IP except for 443 but I can > connect via SSL on 9001. I don't understand how ORListenAddress is > supposed to work: my bridge times out on 443 but when I comment out the > ORListenAddress > line it doesn't connect via obfsproxy at all. > > Please advise. > > > On Thu, Aug 15, 2013 at 1:47 AM, lee colleton <l...@colleton.net> wrote: > >> 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" <l...@colleton.net> 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" <l...@colleton.net> 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 <l...@colleton.net> 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 <a...@mit.edu>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 - tor-t...@lists.torproject.org >>>>>> To unsusbscribe or change other settings go to >>>>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk >>>>>> >>>>> >>>>> >>>> >
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
