Self-test reachability test - Listen address from ORPort is ignored, it uses default address unless specified via Address argument
Tor: 0.2.5.10 OS: Debian Wheezy 64 bit Installation: apt-get from deb.torproject.org
Configuration of server (one gigabit network card): em0: IP1 em0:0 IP2 em0:1 IP3 em0:2 IP4 em0:3 IP5
I tried to run multiple Tor instances to saturate the CPU of the server. I configured instances with different pid, datadirecotry and logfile as manual recommends, and specified the different IP as follows in each config file:
tor1.cfg ORPort IP1:port DirPort IP1:port OutboundBindAddress IP1
tor2.cfg ORPort IP2:port DirPort IP2:port OutboundBindAddress IP2
etc. so on
The first Tor instance started just fine, but the following ones didn't publish server descriptor because self reachability test did not pass. Why? They were all thinking they should be reachable on IP1 (def spend a huge amount of time on this.ault IP, em0 interface). Obviously that IP did not had the requried ports open for the additonal Tor instances so the test could not possibly pass.
Fix: I have added in each config file: Address IP1 Address IP2 and so on
After that it did the self reachability test on the correct IP address, and it passed of course, so server descriptor was published.
Tor should know to prase the IP address from ORPort and/or DirPort and make tests on that, obviously that's the address where the port should be open. Caution at -noadvertise and -nolisten options when this bug is inspected.
Activity
changed milestone to %Tor: 0.2.9.x-final
We'll need to fix this to get #17782 (moved) working correctly.
Trac:
Sponsor: N/A to N/A
Parent: N/A to #17782 (moved)
Severity: N/A to NormalSee https://trac.torproject.org/projects/tor/ticket/17782#comment:9 for a description of issues involved in reachability self-testing.
I think it's a shame we won't fix this in 0.2.9, it's still confusing users, and may well cause reachability issues - see #18819 (moved). (This likely also affects the DirPort listen address.)
Trac:
Keywords: N/A deleted, 029-proposed addedBut we're not testing the address that the ORPort or DirPort are listening on!
There's a minimal fix that changes the order of address usage from:
- Address config option
- auto-discovered address via various methods
To:
- ORPort/DirPort address (if present)
- Address config option
- auto-discovered address via various methods
Bonus points for logging how we got the address, and what to do to change it.
I think this can be simplified to:
- Test the ORPort IP and port (that's about to be) advertised in the descriptor
- Test the DirPort IP and port (that's about to be) advertised in the descriptor
For bonus points, we should re-test it when it changes, but I think that's #17782 (moved).
Replying to teor:
I think this can be simplified to:
- Test the ORPort IP and port (that's about to be) advertised in the descriptor
- Test the DirPort IP and port (that's about to be) advertised in the descriptor
For bonus points, we should re-test it when it changes, but I think that's #17782 (moved).
Oops. Relay descriptors only have one address in their "router" line.
From dir-spec.txt:
"router" nickname address ORPort SOCKSPort DirPort NLSo the ORPort and DirPort need to be on the same IP address.
We should log a warning if the following addresses don't match:
- the IPv4 address used in the descriptor
- resolve_my_address()
- an IPv4 address belonging to an ORPort that matches the ORPort we're about to advertise
- router_get_advertised_or_port()
- skip ORPort addresses with NoAdvertise set
- an IPv4 address belonging to a DirPort that matches the DirPort we're about to advertise
- router_get_advertised_dir_port()
- skip DirPort addresses with NoAdvertise set
For bonus points, and the risk of breaking existing torrcs, we could modify resolve_my_address to use:
- Address
- an IPv4 address belonging to an ORPort that matches the ORPort we're about to advertise
- an IPv4 address belonging to a DirPort that matches the ORPort we're about to advertise
- the other ways we currently try and guess our address
Oh wait, teor said he thinks this one should go in, and that the code to detect a mismatch and warn will be simple.
If it's really a simple solution, let's do that in 0.2.9, but let's watch out for scope-creep.
Trac:
Milestone: Tor: 0.2.??? to Tor: 0.2.9.x-final
Description: Tor: 0.2.5.10 OS: Debian Wheezy 64 bit Installation: apt-get from deb.torproject.orgConfiguration of server (one gigabit network card): em0: IP1 em0:0 IP2 em0:1 IP3 em0:2 IP4 em0:3 IP5
I tried to run multiple Tor instances to saturate the CPU of the server. I configured instances with different pid, datadirecotry and logfile as manual recommends, and specified the different IP as follows in each config file:
tor1.cfg ORPort IP1:port DirPort IP1:port OutboundBindAddress IP1
tor2.cfg ORPort IP2:port DirPort IP2:port OutboundBindAddress IP2
etc. so on
The first Tor instance started just fine, but the following ones didn't publish server descriptor because self reachability test did not pass. Why? They were all thinking they should be reachable on IP1 (default IP, em0 interface). Obviously that IP did not had the requried ports open for the additonal Tor instances so the test could not possibly pass.
Fix: I have added in each config file: Address IP1 Address IP2 and so on
After that it did the self reachability test on the correct IP address, and it passed of course, so server descriptor was published.
Tor should know to prase the IP address from ORPort and/or DirPort and make tests on that, obviously that's the address where the port should be open. Caution at -noadvertise and -nolisten options when this bug is inspected.
to
Tor: 0.2.5.10 OS: Debian Wheezy 64 bit Installation: apt-get from deb.torproject.org
Configuration of server (one gigabit network card): em0: IP1 em0:0 IP2 em0:1 IP3 em0:2 IP4 em0:3 IP5
I tried to run multiple Tor instances to saturate the CPU of the server. I configured instances with different pid, datadirecotry and logfile as manual recommends, and specified the different IP as follows in each config file:
tor1.cfg ORPort IP1:port DirPort IP1:port OutboundBindAddress IP1
tor2.cfg ORPort IP2:port DirPort IP2:port OutboundBindAddress IP2
etc. so on
The first Tor instance started just fine, but the following ones didn't publish server descriptor because self reachability test did not pass. Why? They were all thinking they should be reachable on IP1 (def spend a huge amount of time on this.ault IP, em0 interface). Obviously that IP did not had the requried ports open for the additonal Tor instances so the test could not possibly pass.
Fix: I have added in each config file: Address IP1 Address IP2 and so on
After that it did the self reachability test on the correct IP address, and it passed of course, so server descriptor was published.
Tor should know to prase the IP address from ORPort and/or DirPort and make tests on that, obviously that's the address where the port should be open. Caution at -noadvertise and -nolisten options when this bug is inspected.
When building a descriptor:
- warn if the ORPort address on the advertised IPv4 ORPort doesn't match the IPv4 address in the descriptor
- warn if the DirPort address on the advertised IPv4 DirPort doesn't match the IPv4 address in the descriptor In both cases, tell the user to set "Address" to the correct IPv4 address.
My first attempt at this is in my branch bug13953 on https://github.com/teor2345/tor.git
It could do with some testing, and maybe some unit tests.
Trac:
Status: new to needs_review
Actualpoints: N/A to 3 hourstested teor's branch and it works in practice. Behind NAT it is not a problem, because Tor guesses the public IP address and does the test on that address regardless if it's not configured with
NoListen. It does this with teor's bug13953 branch where I've tested many combinations (didn't test on master or other branches).It becomes a problem when there are multiple public IP addresses on the same server, because Tor will only check the primary (default) address unless differently configured with
Address. That is why I suggest changing the second part of the log message to be more explicit. Something like:Please configure the matching IPv4 address for this router as "Address <IPv4 address>" in the torrc configuration file if you have multiple public IP addresses. If you are behind a NAT and have the right ports forwarded you can ignore this warning or, to remove it, use 2 ORPort lines with options NoListen (for the public IPv4 address line) and NoAdvertise (for the internal NAT IPv4 address line).The rest looks good to me.
On second thought, won't be possible to make this warning automatically go away with this simple logic:
If the address explicitly configured with ORPort, if and only if, is a public IP address - let's call this or-address (and it also matches the DirPort address?), Tor will automatically assume
Address == or-address, unless manually configured by user otherwise, andOutboundBindAddress == or-address, unless manually configured by user otherwise. This requires that the ORPort line to be used must not contain aNoAdvertiseoption. I think this could be a sane default, since it's clearly the intent of any user that specially configures an ORPort : line in torrc.This will ensure:
- We are not breaking any existing torrcs.
- We avoid an additional warning in the log file which could confuse users who don't know so much about networking stuff.
Replying to s7r:
On second thought, won't be possible to make this warning automatically go away with this simple logic:
If the address explicitly configured with ORPort, if and only if, is a public IP address - let's call this or-address (and it also matches the DirPort address?), Tor will automatically assume
Address == or-address, unless manually configured by user otherwise, andOutboundBindAddress == or-address, unless manually configured by user otherwise. This requires that the ORPort line to be used must not contain aNoAdvertiseoption. I think this could be a sane default, since it's clearly the intent of any user that specially configures an ORPort : line in torrc.This will ensure:
- We are not breaking any existing torrcs.
- We avoid an additional warning in the log file which could confuse users who don't know so much about networking stuff.
I was concerned about the possible negative impacts of this change to existing configurations, which is why I chose to just add a log message. And as nickm said in comment 17, if we want to modify Address guessing order, we should do it in the next release (see #19919 (moved)).
That said, I agree we could change the log message as suggested in comment 23 to make it clearer.
Trac:
Status: needs_review to needs_revision
Actualpoints: 3 hours to 0.5(Some people don't have github, so it's hard for us to swap pull requests on Trac.)
The latest branch is: bug13953 on https://github.com/gits7r/tor.git
On review, here's some things we could change:
- make the log message a
static const char *with "ORPort" and "DirPort" replaced with "%sPort" - the OR and Dir code is almost identical - we could put it in its own function to avoid duplication, and pass the inputs as parameters
- add a unit test
Trac:
Status: needs_revision to merge_ready
Keywords: N/A deleted, TorCoreTeam201608 added- make the log message a
Please see my branch bug13953 on https://github.com/teor2345/tor.git
I've removed the duplicate code via refactoring, which means the string is only used once.
I also reworded the log message to make it clearer that:
- if the relay has a static IPv4 address, use 'Address' (the IPv4 address in the descriptor)
- if the relay is behind NAT, use 'ORPort NoListen' for the external port (the IP address on a NoListen port is ignored, only the port is put in the descriptor), and 'ORPort NoAdvertise' for the internal port (binding to all addresses is the most functional default, as NAT often implies DHCP).
This covers the most common causes of this issue: multiple static public IPv4, static IPv4 with NAT, and dynamic IPv4 with NAT.
I didn't write a unit test - if we want to unit test router_build_fresh_descriptor, we should do that in a separate ticket.
s7r, if you're happy with this, please put it into merge_ready for nickm to look at.
Trac:
Actualpoints: 0.5 to 1.0
Status: merge_ready to needs_reviewNice to remove the duplicate code. I am happy with it, but I think we should reword the log message:
_[...]If you have a static public IPv4 address, set 'Address '[...]_
If there's just a static IP address, this setting is unnecessary, Tor will just discover and use it. The setting is necessary when there are multiple public IP addresses and the user wants to use a certain one. Also substitute IPv4 with IP, simpler and should cover IPv6 as well in the future.
Latest branch that includes teor's refactoring and the reworded log message is
bug13953on https://github.com/gits7r/tor.gitTrac:
Status: needs_review to merge_readyReplying to s7r:
Nice to remove the duplicate code. I am happy with it, but I think we should reword the log message:
_[...]If you have a static public IPv4 address, set 'Address '[...]_
If there's just a static IP address, this setting is unnecessary, Tor will just discover and use it.
No, that's not always true. Sometimes Tor's automatic address discovery fails, in particular, when it is not allowed to enumerate the IP addresses on the machine. Sometimes it works, but gets conflicting results (#17782 (moved), #17765 (moved)).
The setting is necessary when there are multiple public IP addresses and the user wants to use a certain one.
Yes, it's necessary in this case, but also necessary in other cases (which are somewhat unpredictable). So I'd rather log a message that encourages relay operators to set
Addresswhenever they have a static IPv4, even if they sometimes don't need to, than have some relays stop working becauseAddresswasn't set.Also substitute IPv4 with IP, simpler and should cover IPv6 as well in the future.
No,
Addressonly takes an IPv4 address. The advertised IPv6 OR address is the address of the first IPv6ORPort. It's not possible to use an IPv6 address withAddress.Latest branch that includes teor's refactoring and the reworded log message is
bug13953on https://github.com/gits7r/tor.gitYou also added:
and 'OutboundBindAddress <IP>I think it's ok to include it, as long as you're sure that pushing all Tor traffic through the relay IP is what most relay operators want. (I think it probably is.)
I've merged that change in to: [bug13953 00557a5] fixup! fixup! fixup! fixup! Reword the router_check_descriptor_address_port_consistency log message on https://github.com/teor2345/tor.git
I also tried to cut down the log message a bit more.
Trac:
Status: merge_ready to needs_reviewI just logged #19988 (moved): Warn when Port addresses have no effect, as a follow-up to this ticket, in case we still see problems with these kinds of issues when operators switch to 0.2.9.
mentioned in issue #17782 (moved)
mentioned in issue #17901 (moved)
mentioned in issue #18819 (moved)
mentioned in issue #18819 (moved)
mentioned in issue #19919 (moved)
mentioned in issue #19988 (moved)
moved to tpo/core/tor#13953 (closed)
mentioned in issue tpo/core/tor#19919 (closed)
mentioned in issue tpo/core/tor#19988 (closed)
