Opened 7 years ago

Closed 4 years ago

#9612 closed defect (duplicate)

Wrong IP used from /etc/hosts

Reported by: massar Owned by:
Priority: Low Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-relay
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Be silly, miss-configure your /etc/hosts file, thus for a host named 'wrongtest' (thus "hostname -a" == wrongtest.wrongdomain" matches that), have in /etc/hosts/

192.0.2.66 wrongtest.wrongdomain

Then have on the REAL interface (eth0) the real IP address 192.0.2.1.

Put in torrc (next to other semi-standard things):

DirPort 192.0.2.1:993
ORPort 192.0.2.1:443

Start tor using that, it will listen on the 192.0.2.1 IP (logs state that and netstat confirms), and then you will see:

[notice] Now checking whether ORPort192.0.2.66:443 and DirPort 192.0.2.66:993 are reachable... (this may take up to 20 minutes -- look for log messages indicating success)
[warn] Your server (192.0.2.66 :443) has not managed to confirm that its ORPort is reachable. Please check your firewalls, ports, address, /etc/hosts file, etc.

Yes, for some mysterious reason 192.0.2.66 is used (which is only to be found in /etc/hosts), even though you specified the other address...

Now, stop tor. Fix /etc/hosts to the right IP (192.0.2.1) and restart Tor and everything works as it should.

Something is causing /etc/hosts to be used which should not even be involved at all, might want to figure out why.

(Of course I should not be silly and have old IPs in the configs left, but hey, can't blame me for that :)

Version not selected in Trac as this pertains to the current (today/last hour) git version and there is no 'tor git' option in the list, but there are a 50 other which are very old, and nicely unsorted btw, might want to clean that up.

Child Tickets

Change History (5)

comment:1 Changed 7 years ago by nickm

Keywords: tor-relay added
Milestone: Tor: unspecified

Something is causing /etc/hosts to be used which should not even be involved at all, might want to figure out why.

When Tor can't figure out its address, and there is no configured address, it sometimes tries to resolve its hostname. (It also looks at interfaces too, but I'm not sure in what order.) Removing the "resolve our hostname" step entirely is probably not in the works, since in some cases it's the only way to figure out our working public address.

One thing we could try to do in this case is to prioritize the guesses more sensibly somehow, or do a better job about noting discrepancies between them, or logging where we got our address guesses so that it's easier to say "oh, I need to fix my /etc/hosts".

(What else could we do here?)

comment:2 Changed 4 years ago by arma

Severity: Normal

The old answer here is "you didn't set your Address line, so what did you expect?"

I wonder if the new answer should be that we look at the IP address you used in your ORPort line, if present, and prefer that guess over the "ask for our hostname, then try to resolve it" heuristic.

(That new answer is newly possible now that ORPorts can have IP addresses in them too.)

That said, am I right that the ORPort 192.0.2.1:443 syntax is bad news because it (maybe surprisingly) doesn't listen on 0.0.0.0, so e.g. it won't listen on localhost? If so I would argue that people who are trying to set their Address line by putting an IP address in the ORPort line are doing it wrong.

I guess a much simpler first step could be to notice when the operator puts an IP address in ORPort or DirPort, but *doesn't* set their Address line, and give them a warning?

comment:3 in reply to:  2 Changed 4 years ago by teor

Replying to arma:

The old answer here is "you didn't set your Address line, so what did you expect?"

I wonder if the new answer should be that we look at the IP address you used in your ORPort line, if present, and prefer that guess over the "ask for our hostname, then try to resolve it" heuristic.

(That new answer is newly possible now that ORPorts can have IP addresses in them too.)

There's an existing ticket for this, #19919.

That said, am I right that the ORPort 192.0.2.1:443 syntax is bad news because it (maybe surprisingly) doesn't listen on 0.0.0.0, so e.g. it won't listen on localhost? If so I would argue that people who are trying to set their Address line by putting an IP address in the ORPort line are doing it wrong.

I guess a much simpler first step could be to notice when the operator puts an IP address in ORPort or DirPort, but *doesn't* set their Address line, and give them a warning?

We implemented this in 0.2.9 in #13953.

Is this ticket now a duplicate? (Or now fixed?)
We also have #17765 and #17782.

comment:4 Changed 4 years ago by arma

I have not read all the other tickets in detail, but I think you're right, this looks like it's now a duplicate ticket. Woo!

comment:5 Changed 4 years ago by teor

Resolution: duplicate
Status: newclosed
Note: See TracTickets for help on using tickets.