Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#16445 closed defect (fixed)

STEM: 'RouterStatusEntryV3' object has no attribute 'measured'

Reported by: cypherpunks Owned by: atagar
Priority: Immediate Milestone:
Component: Core Tor/Stem Version:
Severity: Keywords: RouterStatusEntryV3 AttributeError
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

AttributeError: 'RouterStatusEntryV3' object has no attribute 'measured'

More details: http://tor.stackexchange.com/questions/7102/routerstatusentryv3-doesnt-have-members-it-should-have

Child Tickets

Change History (13)

comment:1 Changed 4 years ago by atagar

Interesting. I'm not getting an error when I run that...

% cat scrap.py 
from stem.control import Controller

with Controller.from_port() as controller:
  controller.authenticate()
  print controller.get_network_status('e9c8154418544764619d2ccd0596b355d7dff236').measured

% python scrap.py 
None

What version of Stem are you running? This sounds a bit like #16048, so if it's 1.4.0 rather than 1.4.1 then that might be the issue.

comment:2 Changed 4 years ago by cypherpunks

Damn, indeed. pip installs 1.4.0 for some reason.
Also when I try to download the tarball I get an error now:
https://pypi.python.org/packages/source/s/stem/stem-1.4.1.tar.bz2

<Error>
<Code>NoSuchKey</Code>
<Message>The specified key does not exist.</Message>
<Key>source/s/stem/stem-1.4.1.tar.bz2</Key>
<RequestId>9BF8664AFF649A37</RequestId>
<HostId>
wZ5f1OftcqkmtZHhSivumJS/SVv3vWI/MGP4TL1TgEFMOpOvRxtvRlqRywhAl5OTyXOlFl3DVaQ=
</HostId>
</Error>

comment:3 Changed 4 years ago by atagar

Yup, that one's my bad. I uploaded the wrong commit when making the 1.4.1 release, so had to make 1.4.1b. Try...

https://pypi.python.org/packages/source/s/stem/stem-1.4.1b.tar.bz2

Looks like I forgot to update the 'tarball' link on the download page. I assume that's where you got it?

comment:4 Changed 4 years ago by atagar

comment:5 Changed 4 years ago by cypherpunks

It works now.
Perhaps it is somewhat unrelated but could you tell me why measured is None? Seems like this site has no problem obtaining measured:

https://torstatus.blutmagie.de/router_detail.php?FP=e9c8154418544764619d2ccd0596b355d7dff236

I suspect I missed a sync somewhere?
Thanks.

Edit:

I'm playing around with this:

relays = [x for x in TOR_CONTROLLER.get_network_statuses() if {stem.Flag.GUARD, stem.Flag.VALID, stem.Flag.RUNNING, stem.Flag.FAST, stem.Flag.STABLE} <= set(x.flags) and len(set(x.flags) & {stem.Flag.BADEXIT, stem.Flag.BADDIRECTORY, stem.Flag.AUTHORITY, stem.Flag.EXIT}) is 0 and x.measured > 8192*2]

Last edited 4 years ago by cypherpunks (previous) (diff)

comment:6 Changed 4 years ago by atagar

Resolution: fixed
Status: newclosed

The 'measured' heuristic is only present in votes, and used to determine what the 'bandwidth' is in the consensus. For more information see the spec. Remember, these are just a unitless heuristic (not a measurement of anything in particular).

TorStatus might actually be showing the average_bandwidth of the server descriptors, but just a guess...

https://stem.torproject.org/api/descriptor/server_descriptor.html

Feel free to reopen if you run into any further issues.

comment:7 Changed 4 years ago by cypherpunks

dict((str(x.fingerprint), x) for x in TOR_DOWNLOADER.get_server_descriptors().run())

This seems to produce more relays than are in the network by 1000-2000. Also it appears to not contain certain relays that should be there:

KeyError: '5510FC1736B16D46D3F2DDA5011995C478D42594'

Any idea why?

comment:8 Changed 4 years ago by atagar

By number mismatch do you mean the count in the consensus and server descriptors differ? I'd expect a small difference, but 1-2k doesn't sound right.

comment:9 Changed 4 years ago by cypherpunks

print len(TOR_DOWNLOADER.get_server_descriptors().run()) - len(TOR_DOWNLOADER.get_consensus().run())

824

atm. Also the weird missing relay 5510FC1736B16D46D3F2DDA5011995C478D42594 is no longer missing it seems. Some sort of inconsistency there. I was just about to make a counter to count how many mismatches, guess when they happen you can count them on the fingers of a single hand.

comment:10 Changed 4 years ago by atagar

I'd expect there to be a handful relays that have server descriptors but not be in the consensus due to being new (just started in the last hour or so). That many though is surprising. Not sure offhand what's up.

comment:11 Changed 4 years ago by cypherpunks

You should also look into the missing relay I initially reported, it happened again this time with 01CD89CDAC9FF3266D5CB4A5EF1999641FEE9BBE.

I don't know why something in the consensus would not also have a server descriptor. Might just be a delay bug, or could imply something more serious?

Hmm it's not even a new relay:
Current Uptime: 129 Day(s), 4 Hour(s), 27 Minute(s), 57 Second(s)

Just minutes after me posting this the issue was fixed. Seems like it's some kind of a singular anomaly that strikes a random node occasionally.

Last edited 4 years ago by cypherpunks (previous) (diff)

comment:12 Changed 4 years ago by atagar

Happy to look into Stem issues, but I don't have time on my hands to dig into descriptor oddities. Patches welcome though if you'd care to improve something in this front.

comment:13 Changed 4 years ago by cypherpunks

Alright I will figure my way from here.
Thanks for your help I would of never guessed that Stem version was the problem, I trusted pip :(

Note: See TracTickets for help on using tickets.