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

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

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

added AttributeError RouterStatusEntryV3 component::archived/stem owner::atagar priority::immediate resolution::fixed status::closed type::defect labels

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 (closed), so if it's 1.4.0 rather than 1.4.1 then that might be the issue.

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

NoSuchKey The specified key does not exist. source/s/stem/stem-1.4.1.tar.bz2 9BF8664AFF649A37 wZ5f1OftcqkmtZHhSivumJS/SVv3vWI/MGP4TL1TgEFMOpOvRxtvRlqRywhAl5OTyXOlFl3DVaQ=

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?

Link fixed.

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]

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.

Trac:
Status: new to closed
Resolution: N/A to fixed

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?

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.

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.

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.

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.

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.

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 :(

closed