Opened 8 years ago

Closed 3 years ago

#2467 closed defect (wontfix)

torweather refuses to accept the fingerprint of my relay.

Reported by: murble Owned by: kaner
Priority: Very High Milestone:
Component: Metrics/Tor Weather Version:
Severity: Keywords: fingerprint
Cc: barkerjr@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

When i try and register my relay at https://weather.torproject.org/subscribe/ I get the message
We could not locate a Tor node with that fingerprint.

4AC95D85CA324AD71E30F1D8C681D1DF6DAEDA8A is in /var/lib/tor/fingerprint the nickname is murble42
(http://torstatus.blutmagie.de/router_detail.php?FP=4ac95d85ca324ad71e30f1d8c681d1df6daeda8a)

This relay was previously a bridge if that is in any way related.

Child Tickets

TicketStatusOwnerSummaryComponent
#17185closedWeather could not locate a Tor nodeMetrics/Tor Weather

Change History (13)

comment:1 Changed 8 years ago by arma

I just tried to reproduce, and it also failed for me.

murble42 is up and in the consensus:
https://metrics.torproject.org/relay-search.html?search=4AC95D85

but weather still tells me "We could not locate a Tor node with that fingerprint."

comment:2 Changed 8 years ago by BarkerJr

Cc: barkerjr@… added

I have the same problem with 3FDC045E9404A288809DC403525B794898AE885D

comment:3 Changed 8 years ago by marvin

Same problem for me with C3EC 4B23 EF08 15BC 597B A0AD 3035 87EF 43A1 77B5.

comment:4 Changed 8 years ago by kaner

Status: newaccepted

I can reproduce it. The router's currently are not seen by Weather, even though they're in the consensus file of Weather's Tor relay. I'll figure out why.

comment:5 Changed 8 years ago by arma

Priority: normalcritical

Once the immediate bug is resolved, the next step is to compare how Weather's set-up to learn descriptors from Tor differs from Torflow's set-up. I think Mike has put a lot of effort into making sure bwauth and related scripts learn about all the descriptors. This effort should be reusable.

comment:6 Changed 8 years ago by kaner

More analysis done:

All reported fingerprints are now in the Weather database. Maybe the restart of the listener process I did yesterday helped.

Anway:

There are 36 router fingerprints that are in the cached-descriptors file, but not in the Weather database.
There are 984 router fingerprints that are in the Weather database, but not in the cached-descriptors file.
The second one can be explained by older routers still in weather. weather keeps routers for 365 days after they were last seen. But what about the 36 routers in the descriptors file?

comment:7 Changed 8 years ago by kaner

All 36 routers that are not in the database, but in the descriptors file can be found in the weather.log file with the similar entries to this:

"ErrorReply: 552 Unrecognized key "ns/id/3EED1D12B12DAB7232EF8D33E9F37426437981F"

Looks like the problem is related to how the Tor control port responds to some control request:

$ telnet localhost 9051
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is ']'.
authenticate
250 OK
GETINFO ns/id/3EED1D12B12DAB7232EF8D33E9F37426437981F9
552 Unrecognized key "ns/id/3EED1D12B12DAB7232EF8D33E9F37426437981F9"
GETINFO desc/id/3EED1D12B12DAB7232EF8D33E9F37426437981F9
250+desc/id/3EED1D12B12DAB7232EF8D33E9F37426437981F9=
router Unnamed 91.67.142.176 443 0 9030
platform Tor 0.2.1.29 (r8e9b25e6c7a2e70c) on Very recent version of Windows [major=6,minor=1] [workstation] {terminal services, single user}
opt protocols Link 1 2 Circuit 1
published 2011-02-02 18:19:21
opt fingerprint 3EED 1D12 B12D AB72 32EF 8D33 E9F3 7426 4379 81F9
uptime 8
bandwidth 5242880 10485760 0
opt extra-info-digest 12E9852AFF0EAD471C699C9E924CF330AE22BAB9
onion-key
.
250 OK

A Tor controller issue?

comment:8 Changed 8 years ago by arma

Does Weather query Tor for the descriptor as soon as the consensus event mentions it? If so, you're not giving Tor time to fetch the descriptor -- Tor learned that there was a new descriptor to fetch at the same time your controller did, so it's no surprise that it doesn't have the descriptor quite yet.

One simple answer would be to wait 5 minutes after your new-consensus event. A better answer would be to learn from Mike what Torflow does to solve exactly this problem.

comment:9 Changed 8 years ago by Sebastian

Another thing to look into would be to not rely on the descriptors for the actual up/down decision, and only fetching them once there is a need to learn contact info (in the case of the first notification of new relays) or bandwidth things (wrt tshirts)

comment:10 Changed 8 years ago by mikeperry

It looks like what kaner described is the opposite problem to what arma mentioned. Kaner's log has the descriptor but not the consensus entry. This could be because the descriptor in question is hibernating (this one in particular has an observed bw of 0, which makes me think it is either hibernating or just finishing hibernating). To solve this problem, you probably need FetchUselessDescriptors to be set, and to work properly. arma and sebastian seem to believe there's a chance it may not, if tor26 goes down (and/or other situations?).

Wrt the issue of not seeing fingerprints that are in the consensus, you probably want to set both FetchDirInfoExtraEarly and FetchDirInfoEarly to ensure you get a consensus every hour. For whatever reason, both of these config options are actually needed to get hourly consensus data. At least that's what it appeared to me while looking at the source.

Wrt to what TorCtl does for the BW auths, I implemented a ConsensusTrackerListener in SQLSupport.py that actually doesn't consider the consensus to be ready until the Tor client goes at least 60 seconds without telling the control port about new descriptors *and* we have 95% of the descriptors from the consensus (this is because there is no actual tor control port event to say that Tor has decided it is done downloading descriptors). You probably don't want/need that SQLSupport code, but maybe a hack like this would help, too?

comment:11 Changed 8 years ago by mikeperry

I'm sorry, my first paragraph there is wrong. Even if FetchUselessDescriptors worked, it still would only get you the descriptor, which you appear to already have in this case. The ns/id query would still fail because hibernating nodes will never be in the consensus..

comment:12 Changed 5 years ago by kaner

According to weasel, tor on the Weather host is running with:

FetchDirInfoEarly 1
FetchUselessDescriptors 1

But not:

FetchDirInfoExtraEarly 1

Should we set the latter?

comment:13 Changed 3 years ago by karsten

Resolution: wontfix
Status: acceptedclosed

Tor Weather has been discontinued as of May 24, 2016: https://lists.torproject.org/pipermail/tor-relays/2016-June/009424.html. Batch-closing all remaining tickets as announced in #19382. A list of these tickets and any other Weather tickets modified after June 26, 2016 will be available here: https://trac.torproject.org/projects/tor/query?changetime=Jun+27%2C+2016..&component=^Metrics%2FTor+Weather

Note: See TracTickets for help on using tickets.