#25034 closed defect

inconsistent eff. family counter in Relay Search

Reported by: cypherpunks Owned by: irl
Priority: Low Milestone:
Component: Metrics/Relay Search Version:
Severity: Normal Keywords:
Cc: metrics-team Actual Points: 0.02
Parent ID: Points: 0.1
Reviewer: Sponsor:

Description

While trying to understand why atlas / Relay Search
displays inconsistent family counters I stumbled on a minor bug.

Unfortunately this was only observed on data from
2018-01-26 04:00:00 UTC and the problem disappeared in the data from
2018-01-26 05:00:00 UTC.
(I have the full details files if need should be)

https://atlas.torproject.org/#search/family:FC9AC8EA0160D88BCCFDE066940D7DD9FA45495B

The effective_family counters displayed next to the nickname is probably implemented
as len(effective_family)+1 but should be len(effective_family-self)+1.

This could be fixed in onionoo by always or never include the self fingerprint
in the effective_family array.

I like teor's suggestions for priorities so I'm including it here:> When someone asks for a task, they could tell you:

  • how important it is

This is a "nice-to-have" display fix

  • when they need it done by

There is no actual hard requirement.
Maybe by the end of the year 2018?

  • what will happen if it's not done

A minor number of relay operators might be confused by incorrectly
displayed eff. family member counters (but most don't know the meaning
of that number and so it might be not that confusing after all)

Child Tickets

Change History (10)

comment:1 Changed 16 months ago by irl

Am I understanding correctly that the effective family was including the fingerprint of the relay itself causing the number to be one more than it should have been?

comment:2 Changed 16 months ago by cypherpunks

your understanding is correct with the addition that onionoo does not always include the relays own fingerprint in effective_family so it leads to an inconsistency and can not simply fixed by reducing the counter by one.

I stumbled on it some more times since reporting it and I find it more important to fix than I expected initially, but this should probably be fixed in onionoo not in relay search.

Last edited 16 months ago by cypherpunks (previous) (diff)

comment:3 Changed 16 months ago by irl

Points: 0.1

comment:4 Changed 16 months ago by irl

I have reported #25241 for the Onionoo side of this issue. It's still worth having a mitigation for this in Relay Search as it should be an easy fix.

comment:5 Changed 16 months ago by irl

Cc: metrics-team added
Owner: changed from metrics-team to irl
Status: newaccepted

Looking at this just now.

comment:6 Changed 16 months ago by irl

Actual Points: 0.02
Resolution: fixed
Status: acceptedclosed

Fixed in 409e410.

comment:7 Changed 16 months ago by cypherpunks

the fix does not appear to be effective

example:
https://atlas.torproject.org/#search/family:2558A0DAD0D073D9826AEEBEF73E3B447079F139

jaffacakemonster2 (3) but should say jaffacakemonster2 (2)
published: 2018-02-16 15:00:00 UTC.

tor-relays:
https://lists.torproject.org/pipermail/tor-relays/2018-February/014548.html

comment:8 Changed 16 months ago by cypherpunks

Resolution: fixed
Status: closedreopened

comment:9 Changed 16 months ago by cypherpunks

also consider ignoring the atlas part and just wait for onionoo #25241

comment:10 Changed 16 months ago by irl

Status: reopenedclosed

It would appear I pushed to the wrong repository and then didn't actually deploy the fix to the static mirrors. It is working here:

https://metrics.torproject.org/rs.html#search/family:2558A0DAD0D073D9826AEEBEF73E3B447079F139

In #25281 I'm about to redirect the static mirrors to the above URL anyway.

Note: See TracTickets for help on using tickets.