I do wonder why $> scripts/maint/updateFallbackDirs.py check_existing tells $> WARNING::1AF72E8906E6C49481A791A6F8F84F8DFEBBB2BA not a candidate: changed address/port recently (2017-10-22 07:00:00)
But 1AF72E8906E6C49481A791A6F8F84F8DFEBBB2BA didn't changed it address/port since end of 2016.
What I did is to establish a 2nd Tor relay at the same hardware at 2 different ports in automn last year: D11D11877769B9E617537B4B46BFB92B443DE33D (to verify if the combined bandwidth/weight of both would be equal to the one of the former single relay at the same IP). And I played a little bit with its configuration values.
What comes in addition into my mind is that at every reboot I do run first "certbot" to check for a renewed LetsEncrypt certificate. And shortly (1 or 2 minutes) after it finished both Tor instances are started.
Hi,
On 17 Jan 2018, at 08:31, Toralf Förster toralf.foerster@gmx.de wrote:
I do wonder why $> scripts/maint/updateFallbackDirs.py check_existing tells $> WARNING::1AF72E8906E6C49481A791A6F8F84F8DFEBBB2BA not a candidate: changed address/port recently (2017-10-22 07:00:00)
But 1AF72E8906E6C49481A791A6F8F84F8DFEBBB2BA didn't changed it address/port since end of 2016.
We use Onionoo data this check, and it gives that date for last_changed_address_or_port:
https://onionoo.torproject.org/details?limit=1&search=1AF72E8906E6C49481...
Onionoo says a relays has changed its address or port if: * it changes the published address or port of an IPv4 or IPv6 ORPort, or IPv4 DirPort, or * it stops publishing an IPv6 ORPort or IPv4 DirPort, for one or more consensuses, even if it changes back.
Onionoo does not say that an address has changed if you add an IPv6 ORPort to a relay that doesn't have an IPv6 ORPort.
What I did is to establish a 2nd Tor relay at the same hardware at 2 different ports in automn last year: D11D11877769B9E617537B4B46BFB92B443DE33D (to verify if the combined bandwidth/weight of both would be equal to the one of the former single relay at the same IP). And I played a little bit with its configuration values.
You probably changed a port value on your existing relay while doing this. If you keep the addresses and ports the same until we next rebuild the list, your relay should be a candidate.
(We require at least 90 days on the same address, because we lose most fallbacks that way.)
What comes in addition into my mind is that at every reboot I do run first "certbot" to check for a renewed LetsEncrypt certificate. And shortly (1 or 2 minutes) after it finished both Tor instances are started.
Startup delays in Tor do not change the address in Onionoo.
T
On 01/16/2018 11:15 PM, teor wrote:
- it stops publishing an IPv6 ORPort or IPv4 DirPort,
for one or more consensuses, even if it changes back.
Ick, that was it. There was an attempt by me to close ports 80 and 443 of IPv6 for 1 minute to let certbot try to renew the LetsEncrypt certificate over IPv6.
On 18 Jan 2018, at 05:18, Toralf Förster toralf.foerster@gmx.de wrote:
On 01/16/2018 11:15 PM, teor wrote:
- it stops publishing an IPv6 ORPort or IPv4 DirPort,
for one or more consensuses, even if it changes back.
Ick, that was it. There was an attempt by me to close ports 80 and 443 of IPv6 for 1 minute to let certbot try to renew the LetsEncrypt certificate over IPv6.
If you need to do this in future, set PublishServerDescriptor 0. (Your relay automatically uploads its descriptor when you change any ports.)
Or just kill your relay, make the change, and turn it back on.
Or you could use different ports if 80 and 443 conflict. Tor really doesn't mind what ports you use.
T
On 01/16/2018 11:15 PM, teor wrote:
Hi,
On 17 Jan 2018, at 08:31, Toralf Förster <toralf.foerster@gmx.de mailto:toralf.foerster@gmx.de> wrote:
I do wonder why $> scripts/maint/updateFallbackDirs.py check_existing tells $> WARNING::1AF72E8906E6C49481A791A6F8F84F8DFEBBB2BA not a candidate: changed address/port recently (2017-10-22 07:00:00)
But 1AF72E8906E6C49481A791A6F8F84F8DFEBBB2BA didn't changed it address/port since end of 2016.
We use Onionoo data this check, and it gives that date for last_changed_address_or_port:
https://onionoo.torproject.org/details?limit=1&search=1AF72E8906E6C49481...
Well, followup question:
Today I got $> cd ~/devel/tor; ./scripts/maint/updateFallbackDirs.py check_existing ... $> WARNING::Excluding 1AF72E8906E6C49481A791A6F8F84F8DFEBBB2BA: in neither blacklist nor whitelist. which let me wonder because $> git grep 1AF72E8906E6C gives $> scripts/maint/fallback.whitelist:5.9.158.75:80 orport=443 id=1AF72E8906E6C49481A791A6F8F84F8DFEBBB2BA ipv6=[2a01:4f8:190:514a::2]:443
Doesn't the "WARNING" refer to the file fallback.whitelist ?
On 22 Jan 2018, at 04:13, Toralf Förster toralf.foerster@gmx.de wrote:
On 01/16/2018 11:15 PM, teor wrote: Hi,
On 17 Jan 2018, at 08:31, Toralf Förster <toralf.foerster@gmx.de mailto:toralf.foerster@gmx.de> wrote:
I do wonder why $> scripts/maint/updateFallbackDirs.py check_existing tells $> WARNING::1AF72E8906E6C49481A791A6F8F84F8DFEBBB2BA not a candidate: changed address/port recently (2017-10-22 07:00:00)
But 1AF72E8906E6C49481A791A6F8F84F8DFEBBB2BA didn't changed it address/port since end of 2016.
We use Onionoo data this check, and it gives that date for last_changed_address_or_port:
https://onionoo.torproject.org/details?limit=1&search=1AF72E8906E6C49481...
Well, followup question:
Today I got $> cd ~/devel/tor; ./scripts/maint/updateFallbackDirs.py check_existing
Please don't run this script more than once a day. It puts some load on Onionoo and the fallbacks.
... $> WARNING::Excluding 1AF72E8906E6C49481A791A6F8F84F8DFEBBB2BA: in neither blacklist nor whitelist. which let me wonder because $> git grep 1AF72E8906E6C gives $> scripts/maint/fallback.whitelist:5.9.158.75:80 orport=443 id=1AF72E8906E6C49481A791A6F8F84F8DFEBBB2BA ipv6=[2a01:4f8:190:514a::2]:443
Doesn't the "WARNING" refer to the file fallback.whitelist ?
In check_existing mode, the whitelist is fallback_dirs.inc. In the default mode, the whitelist is fallback.whitelist.
We should change that message: https://trac.torproject.org/projects/tor/ticket/24953
T
tor-relays@lists.torproject.org