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