Skip to content
Snippets Groups Projects
New look: Off

resolve_my_address() resolves incorrect address.

    • Closed (moved) Issue created by Trac @tracbot

    I have tried tor 0.2.1.26, 0.2.1.27, and 0.2.2.19-alpha. They all detect my IP address as either 8.15.7.117 or 63.251.179.13. Neither is correct. Every 10 minutes or so, tor will switch between the two incorrect IP addresses. Tor seems to be working correctly has a client, but not as a relay. I have set the correct Address in my torrc, and then tor displays the correct address, but is not any more functional.

    My network is pretty standard. I am behind a NAT router, but all ports are forwarded to my computer running tor. Other networking programs like bittorrent, edonkey, and freenet all work correctly. Nothing interesting shows up in the logs.

    Trac:
    Username: eric225125

    To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information

    Child items ...

    • Activity

    • Trac changed milestone to %Tor: 0.2.4.x-final

      changed milestone to %Tor: 0.2.4.x-final

    • Trac added component::core tor/tor milestone::Tor: 0.2.4.x-final priority::medium reporter::eric225125 resolution::fixed status::closed tor-relay type::defect labels

      added component::core tor/tor milestone::Tor: 0.2.4.x-final priority::medium reporter::eric225125 resolution::fixed status::closed tor-relay type::defect labels

    • Trac
      Trac @tracbot ·
      Author

      It seems this problem is related to my DNS server. The two incorrect IP addresses are somehow resolved from my ISP's server. I tried OpenDNS's and had the same problem. After switching to another DNS server from my ISP, my IP address is correctly resolved.

      This is the message I get with the bad DNS servers: Dec 08 16:52:15.401 [notice] Your DNS provider has given "67.215.65.132" as an answer for 11 different invalid ad dresses. Apparently they are hijacking DNS failures. I'll try to correct for this by treating future occurrences of "67.215.65.132" as 'not found'.

      I had thought this was harmless, but I guess not.

      Trac:
      Username: eric225125

    • R
      Robert Ransom @rransom ·

      boboper points out that resolve_my_address tries to resolve the system's hostname using tor_lookup_hostname, which uses the system's gethostbyname function, and in this case, the request was sent to the DNS server, not processed locally.

      What operating system are you using?

    • Trac
      Trac @tracbot ·
      Author

      I am having somewhat the same problem. TOR is functional but I can't set it up as a relay as ORPort and DIRPort will now work. I recently upgraded my system to a higher bandwidth which required changing the IP address in my router. TOR now tells me that ORPort and DIRPort should open on IP 216.220.113.37. My actual IP is 192.168.1.102 and the DNS servers are 216.220.96.17 and .18. How can I fix this?

      Trac:
      Username: Myshkin

    • R
      Robert Ransom @rransom ·

      Replying to Myshkin:

      I am having somewhat the same problem. TOR is functional but I can't set it up as a relay as ORPort and DIRPort will now work. I recently upgraded my system to a higher bandwidth which required changing the IP address in my router. TOR now tells me that ORPort and DIRPort should open on IP 216.220.113.37. My actual IP is 192.168.1.102 and the DNS servers are 216.220.96.17 and .18. How can I fix this?

      Switch to Google's DNS servers (8.8.8.8 and 8.8.4.4).

      What operating system are you using?

    • S
      Sebastian Hahn @sebastian ·

      The google dns suggestion is unlikely to help here, I think Myshkin is probably just a bit confused about private IP addresses. Your actual IP is 192.168.1.102 on your local network only, on the internet you will have a different IP (and 216.220.113.37 is likely to be the correct one as indicated by the same prefix as compared to the dns server). The issue is more likely port forwarding here.

    • R
      Robert Ransom @rransom ·

      Replying to Myshkin:

      I am having somewhat the same problem. TOR is functional but I can't set it up as a relay as ORPort and DIRPort will now work. I recently upgraded my system to a higher bandwidth which required changing the IP address in my router. TOR now tells me that ORPort and DIRPort should open on IP 216.220.113.37. My actual IP is 192.168.1.102 and the DNS servers are 216.220.96.17 and .18. How can I fix this?

      Sebastian is right -- 216.220.113.37 is a home router/firewall, and is currently exposing a web-based configuration interface to the Internet on port 80, along with several other configuration interfaces. Please turn off the external configuration interfaces.

    • Trac
      Trac @tracbot ·
      Author

      Sorry, I forgot to update this ticket. It turns out the source of my problem was that I forgot to set my local hostname in my hosts file to 127.0.0.1, so tor was looking it up with my dns, and my bad ISP dns was returning a bad IP. A good dns failed the hostname lookup even when it wasn't defined. After defining my hostname in my hosts file, all dns worked.

      Trac:
      Username: eric225125

    • Nick Mathewson
      Nick Mathewson @nickm ·

      Shall we close as notabug, or add some more log messages to communicate better how we decided what address to publish?

      Trac:
      Milestone: N/A to Tor: unspecified

    • S
      Sebastian Hahn @sebastian ·

      Trac:
      Points: N/A to N/A
      Resolution: N/A to not a bug
      Status: new to closed
      Actualpoints: N/A to N/A

    • R
      Robert Ransom @rransom ·

      We had another report of this recently in #tor. Something must be done.

      Trac:
      Status: closed to reopened
      Resolution: not a bug to N/A

    • Nick Mathewson
      Nick Mathewson @nickm ·

      Something must be done.

      Any suggestions of what?

    • R
      Robert Ransom @rransom ·

      Replying to nickm:

      Something must be done.

      Any suggestions of what?

      velope wants a log message, saying what hostname Tor resolved and what IP address it resolved to.

      I want (a) a flag which indicates that Tor learned its external IP address by resolving its hostname, (b) a flag that tells Tor to not try to learn its external IP address by resolving its hostname, and (c) a routine (called when Tor has learned its external IP address by resolving its hostname and Tor has detected that its DNS servers lie) that checks whether Tor's external IP address matches an address used for DNS hijacking, and, if so, sets the ‘don't learn your address from your lying DNS servers’ flag and causes Tor to try to determine its IP address again.

    • Nick Mathewson
      Nick Mathewson @nickm ·

      Replying to rransom:

      Replying to nickm:

      Something must be done.

      Any suggestions of what?

      velope wants a log message, saying what hostname Tor resolved and what IP address it resolved to.

      I want (a) a flag which indicates that Tor learned its external IP address by resolving its hostname, (b) a flag that tells Tor to not try to learn its external IP address by resolving its hostname, and (c) a routine (called when Tor has learned its external IP address by resolving its hostname and Tor has detected that its DNS servers lie) that checks whether Tor's external IP address matches an address used for DNS hijacking, and, if so, sets the ‘don't learn your address from your lying DNS servers’ flag and causes Tor to try to determine its IP address again.

      I think that velope's idea should be really doable for 0.2.3.x. I like your idea too, but it feels more like an 0.2.4.x thing to me.

    • Roger Dingledine
      Roger Dingledine @arma ·

      See bug2267a in my git repo for a better log message.

    • Roger Dingledine
      Roger Dingledine @arma ·

      Also, I notice that resolve_my_address() can call get_interface_address(). If that's how it learned it, it sure is misleading for check_descriptor_ipaddress_changed() to pass "source: resolve" to log_addr_has_changed().

    • Nick Mathewson
      Nick Mathewson @nickm ·

      arma: your bug2267a looks like an improvement, but needs a changes file. Also, the comment you made about get_interface_address() seems correct; we shouldn't log "resolved from foo" when that happens.

      Trac:
      Status: reopened to needs_revision

    • Nick Mathewson
      Nick Mathewson @nickm ·

      Trac:
      Keywords: N/A deleted, tor-relay added

    • Nick Mathewson
      Nick Mathewson @nickm ·

      Trac:
      Component: Tor Relay to Tor

    • Roger Dingledine
      Roger Dingledine @arma ·

      See my bug2267b branch.

      In particular, be sure to fix the "const char **method_out" part as needed, since I never quite put my consts in the right places.

      This branch also fixes #8200 (moved).

      Trac:
      Status: needs_revision to needs_review

    • Nick Mathewson
      Nick Mathewson @nickm ·

      d3695ea0ad04e looks good.

      In the other commit (d8f3a49060d), where you log "METHOD=%s %s%s), there's going to be an extra space sometimes. That'll be easy to fix.

      The call to resolve_my_address in check_descriptor_ipaddress_changed() didn't get a "if (!hostname) hostname = tor_dup_ip(addr)" like the other calls did. Should it?

      Trac:
      Milestone: Tor: unspecified to Tor: 0.2.4.x-final

    • Nick Mathewson
      Nick Mathewson @nickm ·

      Replying to nickm:

      d3695ea0ad04e looks good.

      In the other commit (d8f3a49060d), where you log "METHOD=%s %s%s), there's going to be an extra space sometimes. That'll be easy to fix.

      The call to resolve_my_address in check_descriptor_ipaddress_changed() didn't get a "if (!hostname) hostname = tor_dup_ip(addr)" like the other calls did. Should it?

      Oh, nevermind: hostname was NULL there.

    • Nick Mathewson
      Nick Mathewson @nickm ·

      Replying to nickm:the other calls did. Should it?

      Oh, nevermind: hostname was NULL there.

      Wait; apparently not. But we are, I guess, checking for whether hostname is NULL a bit later on.

    • Nick Mathewson
      Nick Mathewson @nickm ·

      See "bug2267b" in my public repository for the minor tweak. Other than that, IMO, it's good to go.

    • Roger Dingledine
      Roger Dingledine @arma ·

      Replying to nickm:

      See "bug2267b" in my public repository for the minor tweak. Other than that, IMO, it's good to go.

      Looks good to me. Thanks!

      (This patch will result in several log lines with a lot of redundant information between them, when your IP address changes. That's something we can clean up in 0.2.5 or something if it bothers us.)

    • Roger Dingledine
      Roger Dingledine @arma ·

      Merged. And closing #8200 (moved) too.

      Trac:
      Resolution: N/A to fixed
      Status: needs_review to closed

    • Trac closed

      closed

    • Robert Ransom mentioned in issue #2410 (moved)

      mentioned in issue #2410 (moved)

    • Roger Dingledine mentioned in issue #8200 (moved)

      mentioned in issue #8200 (moved)

    • Trac moved to tpo/core/tor#2267 (closed)

      moved to tpo/core/tor#2267 (closed)

    Please register or sign in to reply