Opened 11 years ago

Last modified 7 years ago

#827 closed defect (Fixed)

Tor detects imaginary IP change

Reported by: Noino667 Owned by:
Priority: Low Milestone: 0.2.1.x-final
Component: Core Tor/Tor Version: 0.2.0.31
Severity: Keywords:
Cc: Noino667, arma, nickm, downie, mavior Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Weird! Details : had Tor set to "guess" our WAN IP. Minutes before starting the Tor (server), I voluntarily changed my ISP assigned IP.
Launched Tor : it detected the correct IP (line 1). But 1 minute later, Tor senses an *imaginary* change of IP address (line 6) that was to the FORMER
IP address, i.e. one that was in effect BEFORE the server was launched. I can only suppose Tor found the IP number from some stale file or cache !

First time ever seen that, but usually I didn't let Tor "guess" the WAN IP, rather giving it a (dynamic DNS) host name.

Oh and 10 minutes later, Tor redected our IP, this time correctly (not shown in below log).

Log excerpt :
_
Sep 27 12:23:41.203 [notice] Guessed our IP address as XX.XX.237.161.
Sep 27 12:23:44.109 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Sep 27 12:23:44.109 [notice] Now checking whether ORPort XX.XX.237.161:110 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Sep 27 12:24:00.093 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Sep 27 12:24:18.609 [notice] Performing bandwidth self-test...done.
Sep 27 12:24:42.593 [notice] Our IP Address has changed from XX.XX.237.161 to XX.XX.250.23; rebuilding descriptor.
_

[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]

Child Tickets

Attachments (3)

dtlog.txt (1.8 MB) - added by downie 11 years ago.
dtlogm20.txt (152.0 KB) - added by downie 11 years ago.
0.2.1.13-alpha (r18828) on OSX10.3.9 IP problem
dtlog25m.txt (370.4 KB) - added by downie 11 years ago.
0.2.1.13-alpha (r18828) on OSX10.3.9 IP problem take 2

Change History (36)

comment:1 Changed 11 years ago by arma

Is this repeatable?

If so, can you post a debug-level log for this time period? Including the
startup messages from Tor, like what version it's running.

Also, can you post your torrc?

comment:2 Changed 11 years ago by Noino667

Hi! Roger. I was hoping this symptom would be an easy one to spot where it arose from, for you ppl with knowledge of
what the code does (crucially, how exactly does it "guess" our IP when not given a fixed IP or DNS hostname ?).

Running Tor v0.2.0.31 (r16744) on Win 2k SP4.

Unfortunately I won't be able to try and repeat the bug before a few days, hopefully you or someone working on the
project can figure it out even earlier.

Here's a slightly trimmed copy of my torrc . Notice how the 'Address' line was commented out, so Tor was left to guess
my IP. This may well be essential for reproducing the bug.

The 'contactinfo' addie is /valid/ ... just in case :=)

Regards...

_
## TOR Configuration file
## after template for Tor 0.1.2.3-alpha.

## Replace this with "SocksPort 0" if you run Tor only as a server :
SocksPort 9050 # what port to open for local application connections
SocksListenAddress 0.0.0.0

## Entry policies to allow/deny SOCKS requests based on IP address.
## First match wins.

SocksPolicy accept 127.0.0.0/24
SocksPolicy accept 10.0.0.0/24
SocksPolicy reject *

## Logs go to stdout at level "notice" unless redirected by something

Log notice stderr
SafeLogging 0

## listen for connections from Tor controller applications (local)
ControlPort 9051

################ This section is just for servers #####################

## Required: A unique handle for your server.
Nickname noino

## The IP or FQDN for your server. Leave commented out and Tor will guess.
# Address xxxx.mine.nu

## Define these to limit your bandwidth usage. Note that BandwidthRate
## must be at least 20 KB.

BandwidthRate 20 KB # Throttle traffic to 20 kB/s (160 kbit/s)
BandwidthBurst 28 KB # But allow bursts up to 28 kB/s (224 kbit/s)

## Contact info to be published in the directory, so we can contact you
ContactInfo <i8vzret02@…>

## Required: what port to advertise for Tor connections.
ORPort 110
## ... but listen on a port other than the one advertised
ORListenAddress 0.0.0.0:9001

## EXIT POLICIES : a comma-separated list. First match wins.

ExitPolicy accept *:443,accept *:587,accept *:465,accept *:993,accept *:994,accept *:995,reject *:*
#ExitPolicy reject *:* # No exit allowed.
_

comment:3 Changed 11 years ago by Noino667

Oooops... The contactinfo addie was scrubbed by this board - prolly cause it was enclosed in angled chevrons.

Here's (as an experiment... we'll see if the spam starts flowing in ;=)

ContactInfo i8vzret02 AT sneakemail.com

--
Noino

comment:4 Changed 11 years ago by arma

Tor relays guess their IP address based on directory requests. Whenever they
make a directory request, the server they ask sends back an HTTP header that
says X-Your-Address-Is: followed by the IP address the request came from.

So in order for it to guess the wrong one, it would have to be in the Address
field somehow, or it would have to genuinely be the IP address that the
directory authority saw.

Or there is an unknown bug somewhere. This is the first I've heard of this
bug in 0.2.0.x, though there were bugs in previous Tor versions.

comment:5 Changed 11 years ago by Noino667

I am absolutely positive my WAN IP did not change during the reported sequence.
That Tor found an IP which had been /formerly/ in use on the machine suggests it was
consulting a cached value from the local tor data folder. That value would have been retrieved
and cached by the instance of Tor that was running minutes before.

IIRC, - had Tor running as client only,

  • shtdown Tor; changed IPs for an unrelated reason
  • launched Tor server ... got the bug as above reported

The fake IP "found" by the latest instance of Tor was active while the previous instance run.

HTH

comment:6 Changed 11 years ago by Noino

... or, another wild guess, might a Tor directory server have cached my previous IP and returned that instead of the new one ?

comment:7 Changed 11 years ago by bsdtechie

Hi. Can confirm all the imaginary IP changes with my FreeBSD server too. This statement is valid only for the versions
0.2.0.31 and 0.2.1.5.a. As a workaround every morning I had to set up my new IP in torrc manually.

Last weekend I did update to 0.2.1.6.a and now everything seems to be ok. Although my ISP is renewing the IP every night
Tor does recognize this and it keeps all the connections.

Info: In torrc for 'Address' neither an IP number nor a FQDN is given.

Randy

Changed 11 years ago by downie

Attachment: dtlog.txt added

comment:8 Changed 11 years ago by downie

Tor v0.2.0.31 (r16744). Mac OSX10.3.9 500Mhz 640Mb Libevent 1.4.7 ORPort 9001
I have this problem too - and similarly the 'wrong' address is one I've been using previously, as a client only.
See the attached 'dtlog.txt'.
Tor initially gets the right IP, then at 23:36:00.198 thinks it has changed to xx.yy.143.233 when it hasn't,
(yet at 23:36:33.517 thinks it is reachable still) then 20 minutes later at 23:54:52.677 thinks it has changed back to the real xx.yy.86.79 .
If I'd let it keep running it would have flipped back and forth like that all night.

comment:9 Changed 11 years ago by Noino667

I'm the original poster for this bug; is it diagnosed, or is it assigned ?
Despite several independent confirmations I see it is still marked "unconfirmed";
out of curiosity, what does it take for a bug report to lose the "unconfirmed" status ? ;=)

Regards

comment:10 Changed 11 years ago by nickm

noino: we're not great about updating statuses. Haven't got a diagnosis yet.

comment:11 Changed 11 years ago by Noino

@Nick : received 5/5. Keep keeping on !

comment:12 Changed 11 years ago by nickm

Roger's r17549 may make Tor generate more useful log messages when our guessed IP changes. We should also add
some logs for when we guess an IP, explaining the chain of reasoning that made us guess it.

comment:13 Changed 11 years ago by downie

Also happens in 0.2.0.32 (OSX10.3.9)
I also have Kqueue turned off because of

http://bugs.noreply.org/flyspray/index.php?do=details&id=863

but Kqueue was on when 0.2.0.31 was showing this bug.

comment:14 Changed 11 years ago by Noino

Off-topic : spam to my contact address.

FYI the contact address I gave out earlier in this thread started receiving its share of "spam" !
It could have been harvested from the Tor server's " Contact info",
but I'd rather bet it was taken from this here board.

(they can spam that particular address, is no big problem to me - but be warned, don't publish
any *valuable* email addies here) ;=)

comment:15 Changed 11 years ago by mavior

I can indeed confirm this behaviour:

I am using Tor version 0.2.0.34 (r18423), and from at least version 0.2.0.30 I faced this problem.
As described if tor is shut-downed and in the meantime the router/gateway ip address change, when tor will be restarted again

  1. it will notice the ip change correctly.
  2. After some minutes it will notice a false ip change: it will notice that the ip is changed again to the one it had before it was shutted down!
  3. Again after some minutes it goes back to the point number 1

And it will continue the 3 steps loop above until I manually restart the process.
At this point it will execute just the 1. and will correctly public the correct ip.

comment:16 Changed 11 years ago by nickm

"Roger's r17549 may make Tor generate more useful log messages when our guessed IP changes. We should also add
some logs for when we guess an IP, explaining the chain of reasoning that made us guess it."

I guess I should be more explicit when I say stuff like this.

r17549 introduces some debugging code that might make Tor give us more useful information to track down this bug.

This patch applies only to the 0.2.1.x series.

I do not think I can make progress on this bug without the debugging output this patch will produce.

If you are seeing this bug, please run the latest (alpha 0.2.1.13-alpha) at log level INFO until the bug appears,
and upload the log. That would help a lot.

comment:17 Changed 11 years ago by downie

comment:18 Changed 11 years ago by nickm

Look in the parent directory ( https://www.torproject.org/dist/vidalia-bundles/ ). I bet you'll find something.

comment:19 Changed 11 years ago by arma

Whoops. I just fixed the 0.2.1.13-0.1.11 ppc links. Thanks for pointing it out!

Changed 11 years ago by downie

Attachment: dtlogm20.txt added

0.2.1.13-alpha (r18828) on OSX10.3.9 IP problem

comment:20 Changed 11 years ago by downie

OK I'm running 0.2.1.13-alpha (r18828). First thing to point out perhaps is that it disables kqueue always for OSX<10.4 .
See the attached dtlogm20.txt
It seems that the IP has been guessed wrongly right at the start, and now it isn't flipping over to the right IP at all - the xxx.xxx.161.59 is wrong, and is what ends up on http://moria.seul.org:9032/tor/status/authority.
Consequently I have no traffic. Using lsof -i I see lots of connections 192.168.1.2:etlservicemgr-><remote tor node>
but none the other way.

downie

comment:21 Changed 11 years ago by nickm

Downie ... is there an "Address" line set in your torrc? What's on it?

comment:22 Changed 11 years ago by downie

No Address line for that run with the log, no.
That is the workaround for this bug of course, but since I'm on a dynamic IP I have to detect the address in my startup script every time.

comment:23 Changed 11 years ago by downie

Tell a lie, there wasn't but now there is!
Address "xxx.xxx.161.59\r"

comment:24 Changed 11 years ago by Noino

downie wrote:
" since I'm on a dynamic IP I have to detect the address in my startup script every time"

Actually you don't need to, you might subscribe to an account with dyndns.com (or similar),
use a client to update your info with them automatically, that will give you a dyn domain name
which you may use in your Tor config file instead of a numerical IP.

Works for me and HTH. Of course this is not addressing the bug either !

Changed 11 years ago by downie

Attachment: dtlog25m.txt added

0.2.1.13-alpha (r18828) on OSX10.3.9 IP problem take 2

comment:25 Changed 11 years ago by downie

Ok this time I made SURE there was no Address line in the torrc beforehand:
http://bugs.noreply.org/flyspray/index.php?getfile=115
Highlights (my comments in angle brackets):

<Ran Tor using Vidalia, as a client only>
<IP whilst running client only: xxx.zzz.163.37 >
<Stopped Vidalia & Tor and changed IP.>
<Started Relay with IP xxx.yyy.88.181 but no address in the torrc.>
Mar 25 06:56:52.233 [notice] Guessed our IP address as xxx.yyy.88.181. <correct>
Mar 25 06:58:05.883 [notice] Our IP Address has changed from xxx.yyy.88.181 to xxx.zzz.164.245 <wrong, very old>; rebuilding descriptor (source: 149.9.0.57).
<0721 started Vidalia>
<0724 Moria has the wrong IP (above) now - bandwidth graph flat>
<0805 no change to the IP as seent by Moria - gave up>

comment:26 Changed 11 years ago by downie

Lol well angle brackets need escaping:
&lt;Ran Tor using Vidalia, as a client only&gt;
&lt;IP whilst running client only: xxx.zzz.163.37 &gt;
&lt;Stopped Vidalia & Tor and changed IP.&gt;
&lt;Started Relay with IP xxx.yyy.88.181 but no address in the torrc.&gt;
Mar 25 06:56:52.233 [notice] Guessed our IP address as xxx.yyy.88.181. &lt;correct&gt;
Mar 25 06:58:05.883 [notice] Our IP Address has changed from xxx.yyy.88.181 to xxx.zzz.164.245 &lt;wrong, very old&gt;; rebuilding descriptor (source: 149.9.0.57).
&lt;0721 started Vidalia&gt;
&lt;0724 Moria has the wrong IP (above) now - bandwidth graph flat&gt;

&lt;0805 no change to the IP as seent by Moria - gave up&gt;

comment:27 Changed 10 years ago by arma

Ah ha! I think I've found it.

And fixed it in r19291 and r19292.

Alas, the fix only really works once every directory mirror has upgraded. Otherwise
if your relay asks an un-upgraded directory mirror, and that mirror hasn't fetched
a new relay descriptor for you yet, it'll lie to you and give you your old address
back. I wonder if we should work on a workaround for that.

comment:28 Changed 10 years ago by nickm

We could check the declared version of the directory mirror. Or we could only believe an address once
we've heard it from more than one directory mirror.

comment:29 Changed 10 years ago by arma

It turns out that relays with a dirport enabled and advertised don't use
begindir for their dir requests. So they would be immune to this bug.

My workaround for now (r19296) is that if you have ORPort set and Address
not set, you never use begindir. Now these relays won't be tricked by
directory mirrors that haven't upgraded yet.

The only case I'm worried about is bridges: now they fetch dir info like
they have an ORPort on, which isn't how a client would do it. So the only
sets they get to blend in with are a) 0.1.2.x clients, and b) relays that
can't find themselves reachable.

But set (a) is pretty big still, so I'm not too worried yet. Down the road,
once a lot of the network has upgraded, we should consider changing this
logic to (if ORPort and !Address) just avoiding the old-version directory
mirrors.

comment:30 Changed 10 years ago by stars

hello,

Same on Kubuntu karmic 9.10 and origin/master commit afc76a4e714a192e76281793f39c412c87964e46,

Sometime when it start Tor , it told me that my ip have changed but in fact was not the case....

Well i am not worries , just to confirm that's something seem not right somewhere.

I have Dir 443 and Ort 80

my best regards

comment:31 Changed 10 years ago by arma

I'm going to call this particular bug closed. If new ones show up, we can
open a new bug report.

comment:32 Changed 10 years ago by arma

flyspray2trac: bug closed.

comment:33 Changed 7 years ago by nickm

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