Opened 10 years ago

Last modified 7 years ago

#1269 closed defect (Fixed)

tor 0.2.1.24 guesses random exit IPs when node hostname doesn't resolve

Reported by: rdump Owned by:
Priority: Low Milestone:
Component: Core Tor/Tor Version: 0.2.1.22
Severity: Keywords:
Cc: rdump, nickm, arma, Sebastian Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

[This may or may not be related to task #827.]
[I have not tested this on anything buy Mac OS X 10.5.8; it may or may not
occur on other OSes.]

host.department.example.edu has IP address XXX.YYY.ZZZ.WWW when looked
at from inside example.edu.

host.department.example.edu has no IP address (NXDOMAIN) when looked at
from outside example.edu. XXX.YYY.ZZZ.WWW is outside example.edu, so it
cannot look up its own address from its name.

This failure of DNS resolution causes a service outage in the face of
tor 0.2.1.24's IP address guessing, which fails badly, to the point of
picking apparently randomly distributed IP addresses.

This failure of DNS resolution does not cause a service outage in tor
0.2.1.22, though the situation is logged.

I will attach or provide links to debug log files.

[Automatically added by flyspray2trac: Operating System: OSX 10.5 Leopard]

Child Tickets

Attachments (2)

tor-log-from-0.2.1.24-no-external-dns.txt (1.2 MB) - added by rdump 10 years ago.
Debug log from tor 0.2.1.24 on host with no resolvable external hostname
tor-log-from-0.2.1.22-no-external-dns.txt (358.8 KB) - added by rdump 10 years ago.
Debug log from tor 0.2.1.22 on host with no resolvable external hostname

Download all attachments as: .zip

Change History (8)

Changed 10 years ago by rdump

Debug log from tor 0.2.1.24 on host with no resolvable external hostname

Changed 10 years ago by rdump

Debug log from tor 0.2.1.22 on host with no resolvable external hostname

comment:2 Changed 10 years ago by rdump

Yes, that patch applied to the 0.2.1.24 source (from the tarball) and stuffed into the Vidalia app fixes the IP problem.

comment:3 Changed 10 years ago by DaveK

Just ran into the same problem myself (on a windows host):

Mar 03 21:17:30.359 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Mar 03 21:17:30.359 [notice] Bootstrapped 100%: Done.
Mar 03 21:17:30.359 [notice] Now checking whether ORPort 82.6.108.62:9001 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Mar 03 21:18:10.750 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Mar 03 21:19:14.156 [notice] Performing bandwidth self-test...done.
Mar 04 00:00:00.093 [notice] Configured hibernation. This interval began at 2010-03-04 00:00:00; the scheduled wake-up time was 2010-03-04 00:00:00; we expect to exhaust our quota for this interval around 2010-03-05 00:00:00; the next interval begins at 2010-03-05 00:00:00 (all times local)
Mar 04 01:21:24.265 [notice] Your IP address seems to have changed to 1.249.233.248. Updating.
Mar 04 01:21:24.765 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Mar 04 02:00:24.546 [notice] Your IP address seems to have changed to 2.99.199.40. Updating.
Mar 04 02:00:24.875 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.

Am testing the patch in a fresh build. If you don't hear back from me, it worked - thanks!

comment:4 Changed 10 years ago by nickm

okay, applied to 0.2.1 and master.

comment:5 Changed 10 years ago by nickm

flyspray2trac: bug closed.

comment:6 Changed 7 years ago by nickm

Component: Tor RelayTor
Note: See TracTickets for help on using tickets.