Opened 7 months ago

Last modified 7 months ago

#33663 new task

Check checktest.py related errors shown by our network-health scanners

Reported by: gk Owned by: metrics-team
Priority: Medium Milestone:
Component: Metrics/Exit Scanner Version:
Severity: Normal Keywords: network-health, network-health-roadmap-2020Q1, GeorgKoppen202003
Cc: metrics-team Actual Points: 0.5
Parent ID: Points: 0.5
Reviewer: Sponsor:

Description

I often see something like

2020-03-17 21:03:56,973 modules.checktest [ERROR] Check thinks <https://metrics.torproject.org/rs.html#details/296B2178FD742AB35AB20C9ADF04D5DFD3D407EB> isn't Tor.  Desc addr is 206.55.74.0 and check addr is 206.55.74.0.

. We should figure out a) what's up with that and b) whether we actually still need that test to be running.

Child Tickets

Change History (11)

comment:1 Changed 7 months ago by gk

The exit policy of that relay is sufficiently broken that it should not be used as exit (I pinged the operator and will badexit the relay early next week if I don't hear back), however it's not clear yet why check actually thinks it's not an exit.

`checktest.py` is pretty close to what exitscanner is using. However, as the error message in the description clearly shows the exit *is* able to resolve check.torproject.org (thus, the exit policy is acceptable for that particular test at least. Or maybe that's only holding for most of the cases when check.torproject.org resolves to 116.202.120.181?). Thus, it is not obvious where the "IsTor":false is coming from.

Last edited 7 months ago by gk (previous) (diff)

comment:2 Changed 7 months ago by irl

The issue is not whether the exit is able to resolve it, but whether the exit is able to exit to it. Exits need to be able to make exit connections to 116.202.120.181:443. This is a fundamental limitation of the current exit scanner and would need redesign to do differently.

comment:3 in reply to:  2 Changed 7 months ago by gk

Replying to irl:

The issue is not whether the exit is able to resolve it, but whether the exit is able to exit to it. Exits need to be able to make exit connections to 116.202.120.181:443. This is a fundamental limitation of the current exit scanner and would need redesign to do differently.

Thanks, yes, being able to resolve check.torproject.org is just a necessary requirement but not sufficient. I should have been clearer, sorry for that. So, the node can make an exit connection to check.torproject.org as it gets JSON back and complaining afterwards that it got "IsTor":false. Now, there are cases where this can happen, e.g. as the exitscanner might have a different consensus containing relays the check test script does not have once it is run and vice versa but that's usually not causing a permanent failure as in this case.

comment:4 Changed 7 months ago by gk

Component: Metrics/Consensus HealthMetrics/Exit Scanner

If I look at the exit-lists data, say, from 3/23/2020 I can see something like:

2020-03-23-04-02-00:ExitNode 296B2178FD742AB35AB20C9ADF04D5DFD3D407EB
2020-03-23-04-02-00-Published 2020-03-22 21:30:04
2020-03-23-04-02-00-LastStatus 2020-03-23 02:00:00
2020-03-23-04-02-00-ExitAddress 206.55.74.0 2020-03-23 02:32:12

That holds for all the 24 measurements on that day. So, it seems the exit scanner thinks on one hand that this relay is indeed an exit but when asked via exitmap's checktest module (that is querying https://check.torproject.org/api/ip) one gets an "IsTor":false back. Sounds like a check bug worth investigating.

comment:5 Changed 7 months ago by arma

Note that that relay (soltor0)'s exit policy rejects most /8's. So I wouldn't be surprised if there are differences of opinion between tools on whether it "works" for exiting.

comment:6 in reply to:  5 Changed 7 months ago by gk

Replying to arma:

Note that that relay (soltor0)'s exit policy rejects most /8's. So I wouldn't be surprised if there are differences of opinion between tools on whether it "works" for exiting.

Yes, but we use(d) essentially the same tools. :)

comment:7 Changed 7 months ago by gk

Parent ID: #33180

comment:8 Changed 7 months ago by gk

Actual Points: 0.5

comment:9 Changed 7 months ago by gk

Status: assignednew

comment:10 Changed 7 months ago by gk

Owner: changed from gk to metrics-team
Status: newassigned

comment:11 Changed 7 months ago by gk

Status: assignednew
Note: See TracTickets for help on using tickets.