FYI list
https: // torstatus DOT blutmagie DOT de
is registering relays running 0.2.7.2 as having zero bandwidth.
I believe this is because the
write-history read-history
lines in
extra-info
have moved from the top down to the middle of the document.
Many super-fast relays running 0.2.7.2 are showing zero bandwidth and have dropped to the bottom of the ranking as a result.
Might be a bug in 'metrics-db' or it might be a bug in a Blutmagie customization. Seems that the code at
https://gitweb.torproject.org/torstatus.git/
retrieves advertised (self-measure) bandwidth rather than consumed bandwidth, so it's hard to say without a deep-dive into the code. I'm going by the fact that the new
https://torstatus.rueckgr.at/index.php?SR=Bandwidth&SO=Desc
shows advertised bandwidth and presumably runs code from the GIT repository.
Sent an e-mail to Olaf Selke advising him of this issue. Not sure if he still maintains it, but the message did not bounce.
Am 02.08.2015 um 17:39 schrieb starlight.2015q2@binnacle.cx:
FYI list
https: // torstatus DOT blutmagie DOT de
is registering relays running 0.2.7.2 as having zero bandwidth.
I believe this is because the
write-history read-historylines in
extra-infohave moved from the top down to the middle of the document.
Hi, it's me!
debugging the old Blutmagie Perl scripts I found all routers like splitDNA running Tor 0.2.7.2 sending two hash values in the extra-info-digest. I suppose this isn't expected by the script parsing the data.
GETINFO desc/name/splitDNA 250+desc/name/splitDNA= router splitDNA 62.210.82.44 21 0 143 [...] extra-info-digest D6F7A98078BDA327D388D918EBA92D0FC9EDC487 nMA7WhPSpQmquUdYpwIdQtdcKvTAcvNDnXleiPBia0U
regards Olaf
Hi Olaf,
The new ed25519 elliptic curve relay identity certificate now occupies the top of the extra-info document. The script should be able to handle the elements appearing in any order. Since the script is written in perl this should be an easy fix to search/match out the read-history and write-history lines. Extra-info should be treated as a large string having newlines in it and matches written with newline anchors, or as an array of strings, one line-per ordinal. Always more than one way with perl. Will help if you like.
Though it should not matter, the new extra-info sequence is
extra-info . . . identity-ed25519 <multi-line certificate> published . . . write-history . . . read-history . . . dirreq-write-history . . . dirreq-read-history . . . . . .
Regards,
At 16:10 8/3/2015 +0200, you wrote:
Am 02.08.2015 um 17:39 schrieb starlight.2015q2@binnacle.cx: Hi, it's me!
debugging the old Blutmagie Perl scripts I found all routers like splitDNA running Tor 0.2.7.2 sending two hash values in the extra-info-digest. I suppose this isn't expected by the script parsing the data.
GETINFO desc/name/splitDNA 250+desc/name/splitDNA= router splitDNA 62.210.82.44 21 0 143 [...] extra-info-digest D6F7A98078BDA327D3. . .
regards Olaf
At 16:10 8/3/2015 +0200, you wrote:
debugging the old Blutmagie Perl scripts I found all routers like splitDNA running Tor 0.2.7.2 sending two hash values in the extra-info-digest.
The second entry is a new 256-bit digest that will eventually replace the current 160-bit digest and can be ignored for now, so
getinfo extra-info/digest/<first digest>
works, but the modified document layout described earlier will appear.
Am 04.08.2015 um 01:23 schrieb starlight.2015q3@binnacle.cx:
At 16:10 8/3/2015 +0200, you wrote:
debugging the old Blutmagie Perl scripts I found all routers like splitDNA running Tor 0.2.7.2 sending two hash values in the extra-info-digest.
The second entry is a new 256-bit digest that will eventually replace the current 160-bit digest and can be ignored for now, so
getinfo extra-info/digest/<first digest>
Perl script filling the database is adjusted accordingly. The modified extra-info sequence should not be a problem. Router splitDNA now shows up in bandwidth top ten again.
by the way... I will probably shut down blutmagie tor network status in September this year cause the data center has terminated the contract housing my servers 10/31/15.
cheers Olaf
Problem wit 0.2.7.2 is fixed. . .thank you Olaf!
tor-relays@lists.torproject.org
-
Olaf Selke -
starlight.2015q2＠binnacle.cx -
starlight.2015q3＠binnacle.cx