Re: [tor-relays] Blutmagie does not see 0.2.7.2 bandwidth
> On 5 Aug 2015, at 05:52 , starlight.201...@binnacle.cx wrote: > >> At Tue Aug 4 11:22:22 UTC 2015 by Olaf Selke olaf DOT selke at blutmagie DOT >> de >> >> 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. > > Could you make your modified Torstatus code > available on https://gitweb.torproject.org/torstatus > so that someone else can set up another like it? It may be easier to use GitHub. > Blutmagie appears to have significant > and desirable enhancements to the code > presently in the GIT repository. > > I might contribute a new Torstatus, > but if not me someone surely will. > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Tim Wilson-Brown (teor) teor2345 at gmail dot com pgp ABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7 signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Blutmagie does not see 0.2.7.2 bandwidth
>At Tue Aug 4 11:22:22 UTC 2015 by Olaf Selke olaf DOT selke at blutmagie DOT de > >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. Could you make your modified Torstatus code available on https://gitweb.torproject.org/torstatus so that someone else can set up another like it? Blutmagie appears to have significant and desirable enhancements to the code presently in the GIT repository. I might contribute a new Torstatus, but if not me someone surely will. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Blutmagie does not see 0.2.7.2 bandwidth
Problem wit 0.2.7.2 is fixed. . .thank you Olaf! ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Blutmagie does not see 0.2.7.2 bandwidth
Am 04.08.2015 um 01:23 schrieb starlight.201...@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/ 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 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Blutmagie does not see 0.2.7.2 bandwidth
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/ works, but the modified document layout described earlier will appear. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Blutmagie does not see 0.2.7.2 bandwidth
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 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.201...@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 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Blutmagie does not see 0.2.7.2 bandwidth
> 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 It shouldn't be expected by the script: https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt -- "extra-info-digest" digest NL [At most once] "Digest" is a hex-encoded digest (using upper-case characters) of the router's extra-info document, as signed in the router's extra-info (that is, not including the signature). (If this field is absent, the router is not uploading a corresponding extra-info document.) --- Fetching descriptors via: http:///tor/server/all has 2 values for extra-info-digest as well. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Blutmagie does not see 0.2.7.2 bandwidth
Am 02.08.2015 um 17:39 schrieb starlight.201...@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-history lines in extra-info have 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 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Blutmagie does not see 0.2.7.2 bandwidth
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. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
