IPv6-Flagging of Relay not accurate

Our Node (D529E870E7CCFCDA2CFEE9D317A8DC6E85497FDA) is reachable via IPv6, but gets flagged with "unreachable IPv6" by the Consensus.

All IPv6-enabled Authorities can be pinged successfully via IPv6 from the Relay, and the advertised Ports are open for connections via IPv6.

Trac:
Username: ruebezahl

changed milestone to %Tor: unspecified

added 035-roadmap-proposed component::core tor/tor ipv6 milestone::Tor: unspecified owner::metrics-team parent::24864 priority::medium reporter::ruebezahl resolution::duplicate severity::normal status::closed type::defect version::tor 0.3.3.6 labels

Please include timing information. The consensus at what time? What tool do you use for consensus data lookup? ("Core Tor/DirAuth" might not be the right component for this trac entry)

As per consensus 2018-06-04 09:00 UTC D529E870E7CCFCDA2CFEE9D317A8DC6E85497FDA is "ReachableIPv6".

enter your fingerprint at the bottom of this page: https://consensus-health.torproject.org/

onionoo's opinion:

https://onionoo.torproject.org/details?fingerprint=D529E870E7CCFCDA2CFEE9D317A8DC6E85497FDA&fields=unreachable_or_addresses

{"version":"6.0",
"build_revision":"fac3576",
"relays_published":"2018-06-04 08:00:00",
"relays":[
{"unreachable_or_addresses":["[2a00:1328:e102:8000::131]:443"]}
],
"bridges_published":"2018-06-04 08:04:10",
"bridges":[
]}

The consensus at the time since rebooting the relay yesterday at 2018-06-03 20:34:05 till the creation of this ticket (obviously...) as shown on metrics.

No idea as why it is now correctly flagged. I did not change any configuration nor did I restart / sighup the relay.

Please feel free to correct the trac component.

Trac:
Username: ruebezahl

I believe this was just a time of check problem.

Relay Search/onionoo is always a bit behind consensus 2018-06-04 08:00 vs 2018-06-04 09:00

now it is updated and fine:

https://onionoo.torproject.org/details?fingerprint=D529E870E7CCFCDA2CFEE9D317A8DC6E85497FDA&fields=unreachable_or_addresses

{"version":"6.0",
"build_revision":"fac3576",
"relays_published":"2018-06-04 09:00:00",
"relays":[
{}
],
"bridges_published":"2018-06-04 09:04:10",
"bridges":[
]}

please reopen if you are unhappy with this reply.

Trac:
Owner: N/A to metrics-team
Component: Core Tor/DirAuth to Metrics
Status: new to closed
Resolution: N/A to worksforme

Even if relay search/onionoo is behind one hour, this does not explain why it displayed the incorrect flag - or got flagged wrongly - for the remaining 12 hours of relay uptime.

Might be worth investigating, just saying.

Trac:
Username: ruebezahl

Ok, reopened.

Can you describe in detail what you did exactly to help collect relevant information for finding the root-cause?

From previous descriptors on that IP:ORPort (IPv4:217.115.10.131:443) we can see that it was probably more than just a reboot?

previous key and platform: B01B7973207B1FD2F71D51D1B51B89EE77035CF4 Tor 0.3.3.4-alpha on Linux, last seen: 2018-06-01 20:00 first_seen: 2016-04-02 00:00 (Note: this one had no IPv6 ORPort)

current relay: D529E870E7CCFCDA2CFEE9D317A8DC6E85497FDA Tor 0.3.3.6 on SunOS, first seen: 2018-06-02 21:00

Trac:
Resolution: worksforme to N/A
Component: Metrics to Core Tor/DirAuth
Status: closed to reopened

Yes, we changed hardware and deployment, which now includes IPv6 connectivity.

D529E870E7CCFCDA2CFEE9D317A8DC6E85497FDA is active and online since 2018-06-02 21:00:00, the change can be verified at https://www.ccc.de/en/anonymizer

I checked the flags displayed on metrics regulary since configuring ORPort in torrc. I verified working IPv6 connectivity in- and outgoing at 2018-06-03 20:34:05.

Trac:
Username: ruebezahl

Trac:
Cc: N/A to teor
Keywords: N/A deleted, ipv6 035-proposed added

We don't have enough information to diagnose this issue. It could be a bug in Core Tor, metrics, or the relay's IPv6 connectivity.

In most cases that we investigate, the problem is on the relay, or the relays network. (It's more likely that one operator has made a mistake, than 6 directory authorities.) In some cases, Onionoo is outdated.

If it is a bug in Tor, it could be #24864 (moved), where some directory authorities take a while to vote on new descriptors. We added #24862 (moved) to consensus health to diagnose that issue. So if it happens again, please tell us the descriptor timestamp from consensus health, and the descriptor timestamp from the relay itself: http://217.115.10.131/tor/server/authority

Ultimately, we will resolve this issue (or make it much easier to diagnose) by making relays check their own IPv6 addresses in #24403 (moved).

Trac:
Status: reopened to needs_information
Component: Core Tor/DirAuth to Core Tor/Tor
Parent: N/A to #24403 (moved)

Trac:
Keywords: ipv6 035-proposed deleted, 035-roadmap-proposed, ipv6 added

We think this happened due to the delayed descriptor updates in #24864 (moved), or the missing IPv6 reachability checks in #24403 (moved).

If it happens again, please open a new ticket with:

• the descriptor timestamp from consensus health, and
• the descriptor timestamp from the relay itself:
  • ​http://217.115.10.131/tor/server/authority

Trac:
Resolution: N/A to duplicate
Parent: #24403 (moved) to #24864 (moved)
Status: needs_information to closed

closed

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