Private IP Address

Having this "error" for a few versions now (both stable and alpha) but wondering why they are appearing. Currently using the latest Vidalia alpha to run a relay on a Windows 7 unprivileged account. The machine is behind a router with UPnP enabled.

[Info] resolve_my_address() Guessed local hostname 'Myname-PC' resolves to private IP address (192.168.1.15). Trying something else. [Info] resolve_my_address() Interface IP address '192.168.1.15' is a private address too. Ignoring. [Info] resolve_my_address() Address 'Myname-PC' resolves to private IP address '192.168.1.15'. Tor servers that use the default DirServers must have public IP addresses. [Info] router_pick_published_address() Could not determine our address locally. Checking directory headers to provide any hints.

These 4 messages loop over and over infinitely at random but frequent intervals.

UPnP appears to work correctly, the ports forward, and I DO get a various amount of traffic after an hour or so, although whether it's working I'm not sure, I'd like to solve this error. Other applications are able to acquire my public IP address perfectly fine.

I'm open to any and all questioning.

Trac:
Username: funkstar

added component::core tor/tor priority::low reporter::funkstar resolution::fixed status::closed tor-relay type::defect version::tor 0.2.2.13-alpha labels

This doesn't look like a bug to me at all. You are posting info-level logmessages, which don't indicate error conditions but help when we're debugging Tor to see what's going on currently. If you have no other indication that your relay might not be working, everything should be just fine. If you tell us your name or ip address, we can look it up.

Trac:
Priority: major to minor

Trac:
Status: new to closed
Parent: N/A to N/A
Resolution: N/A to worksforme

How does changing it to "worksforme" help solve the issue? It obviously DOESN'T work otherwise I wouldn't be here. I've recently decided to start running tor relays again to test if it's been fixed yet in the latest .14 alpha, it appears to have not been fixed.

Whether the tor relay functions or not is immaterial, Tor fails to detect my public IP address, yet every other program I have does. For that matter, how in the name of god can Tor tell others my public IP address if it doesn't know it?

Sounds like broken module communication to me, 1 module can find out my IP just fine and have the tor relay work, yet this DirServer module can't? Seems like an issue to me!

I'm willing to provide any information and assistance required to have this issue be resolved, but if it's going to be ignored, I won't bother running Tor relays, as I dislike being ignored when trying to help people.

Trac:
Username: funkstar
Resolution: worksforme to N/A
Status: closed to reopened

What are the notice-level logs you get?

You should see some lines like

Aug 15 04:09:47.846 [notice] Now checking whether ORPort 128.31.0.34:9005 and DirPort 128.31.0.34:9035 are reachable... (this may take up to 20 minutes -- look for log messages indicating success) Aug 15 04:09:53.120 [notice] Self-testing indicates your DirPort is reachable from the outside. Excellent. Aug 15 04:09:54.223 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. Aug 15 04:10:52.852 [notice] Performing bandwidth self-test...done.

If you have any warn-level logs, those would also be good to see.

[Adding another comment to try to cause trac to send mail about my earlier comment. Stupid program.]

Let me try again to explain why I think this is probably not a bug.

The code does two things to determine your IP address, first it tests your local interface and if that fails it uses an external resource to do the test.

The info (aka NOT a problem) log messages just point out that the first of two methods failed. The second method can still succeed (and since it appears that you can run a relay without any problem, it looks like it indeed does), there is absolutely nothing to worry about UNLESS you get log messages at a higher level (notice or warn) that tell you about a real issue.

@arma It tells me both ports are reachable as expected, as they are successfully forwarded to the specific PC using UPnP, I couldn't find anything about publishing though.

@sebastian, if that were the case, why would it be printing this warning 4 times every minute? Adding a "successful" print to info level might help to debug this, if there is one, I don't have it.

Trac:
Username: funkstar

It's seeing every so often whether it should change its mind about its best guess for your IP address. So I think the behavior you are seeing is fine and expected.

But really, Sebastian is right: info-level logs are not intended for users to understand or act on. Everything that a user is supposed to know is at notice, warn, or err, and we try to make sure those are comprehensible. Info-level logs are there to help developers debug things.

So you couldn't find anything about publishing? It would help for us to see all of your notice-and-above logs (without any debug or info logs).

arma, If it was successful in gaining the IP, I don't see why it would loop the same function 4 times. One would think it would run the 1st function, fail to get the IP locally, run the 2nd function, succeed in getting the IP (or fail and loop back to the first), then run again after X amount of time (like you explain). This is however not the case, the exact same function is ran 4 times (obviously a loop since it's instant), then a minute later, it is ran 4 times once again.

I'll get you those notice level entries tomorrow when I re-launch! :)

Trac:
Username: funkstar

The goal is to quickly recognize when your ISP has given you a new IP address, so we can get a new descriptor published to point clients to your new location.

So it checks whether your address has changed whenever it's doing other stuff, like fetching or publishing directory information.

In this case I believe it's happening because it's considering whether it needs to fetch any more directory information, and to do that it needs to know what schedule it should use for fetching it (how aggressively), and to know that it needs to know whether you already know your IP address (if you don't you should make a directory request even if you don't need anything, so you can learn your address), and to know whether you already know your IP address it double-checks some things that are cheap to check on your side.

On the one hand, we could try to make it do those checks less often. On the other hand, we actually want to notice even faster than we do already when your IP address changes.

Really, info-level logs that confuse you are not bugs.

I'm not asking to do the check less often, checking often is a good thing as you've stated, I was curious as to why the check is ran 4 times in a loop every minute, instead of once every minute.

Anyway, I think adding a "success" info level print would clear this up entirely, assuming it is successful ofcourse.

Trac:
Username: funkstar

My log as requested: http://pastebin.com/dC87WGQF

Seems normal, but that only seems to tell me that the ports are open, not that it found my IP address (though I realize it would need to know it to test it) although I'm sure I remember there being a log entry about tor functioning properly and getting connections within 2 hours.

Anyway, if it is functioning normally, my request still stands for "success" prints.

Trac:
Username: funkstar

So any chance of having prints added?

Trac:
Username: funkstar

Replying to funkstar:

So any chance of having prints added?

Good idea. I've added this, and it will be part of 0.2.2.18-alpha.

As for the more general problem with resolving our address so often, I've opened that as bug #1992 (moved), to be addressed sometime in 0.2.3.x.

Thanks!

(Ok to close?)

If you have anything to add please reopen.

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

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

Trac:
Component: Tor Relay to Tor

closed

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