Re: [tor-dev] tor 0.2.9.9 gcc 4.2.1

2017-01-29 Thread grarpamp
It was a test compile on a very old 8.x i386 box, warnings would be no surprise there, hardly worth addressing unless exposed a bug, since 11.x runs on most all hw 8.x does. gcc version 4.2.1 20070831 patched [FreeBSD] ___ tor-dev mailing list tor-dev@lis

Re: [tor-dev] tor 0.2.9.9 gcc 4.2.1

2017-01-29 Thread teor
> On 28 Jan 2017, at 14:45, grarpamp wrote: > > Ancient gcc says Thanks for this bug report. Which platform(s) do these warnings occur on? I tested on macOS 10.12 with gcc 4.9 and Linux 4.4 with gcc 4.7, and neither were affected by these errors, so it does appear to be an ancient compiler is

Re: [tor-dev] [RFC] Proposal for the encoding of prop224 onion addresses

2017-01-29 Thread grarpamp
Skimming thread... Version or not is fine, provided if you want versions you know you must store the bits somewhere, or ensure regex parser rules to recognize and match an intrinsic version represented by entire address format specification itself. Note onion search spiders rely on such address r

Re: [tor-dev] ExitPortStatistics interpretation

2017-01-29 Thread nusenu
Karsten Loesing: >> Oh thanks, so it is not possible to find out which is the most frequent >> exit port by number of streams opened, that's a pity. > Well, that one is easy: port 80. :) Ok, maybe I should have said that differently: "so it is not possible to find out which are the top 10 (or N

Re: [tor-dev] ExitPortStatistics interpretation

2017-01-29 Thread Karsten Loesing
On 29/01/17 17:12, nusenu wrote: > Karsten Loesing: >> Those are the 10 ports with the highest number of (written and read) >> bytes, unrelated to the number of stream. And all lines below report >> statistics for these 10 ports plus "other". > > Oh thanks, so it is not possible to find out which

Re: [tor-dev] ExitPortStatistics interpretation

2017-01-29 Thread nusenu
Karsten Loesing: > Those are the 10 ports with the highest number of (written and read) > bytes, unrelated to the number of stream. And all lines below report > statistics for these 10 ports plus "other". Oh thanks, so it is not possible to find out which is the most frequent exit port by numbe

Re: [tor-dev] ExitPortStatistics interpretation

2017-01-29 Thread Karsten Loesing
On 29/01/17 13:56, nusenu wrote: > Hi, Hi nusenu, > I'm looking at ExitPortStatistics. Since the spec [1] is not very > specific, I wanted to confirm that my assumption is correct: > > The current tor implementation includes the 10 most relevant ports, > correct? (highest number of bytes or stre

Re: [tor-dev] onionoo: understanding 'exit_policy_v6_summary'

2017-01-29 Thread nusenu
Karsten Loesing: > Not much we can do in Onionoo here, I'm afraid. I agree that is what I meant with: > Since none of the microdescriptors of that relay in Jan 2017 contained a > "p6" line onionoo works as expected. sorry to bother you. signature.asc Description: OpenPGP digital signature _

Re: [tor-dev] onionoo: understanding 'exit_policy_v6_summary'

2017-01-29 Thread Karsten Loesing
On 28/01/17 00:07, nusenu wrote: > Hi Karsten, Hi nusenu, > given this torrc configuration and exit policy: > https://lists.torproject.org/pipermail/tor-relays/2017-January/011806.html > > would you expect onionoo's 'exit_policy_v6_summary' to be not set? [1] > > https://onionoo.torproject.org

[tor-dev] ExitPortStatistics interpretation

2017-01-29 Thread nusenu
Hi, I'm looking at ExitPortStatistics. Since the spec [1] is not very specific, I wanted to confirm that my assumption is correct: The current tor implementation includes the 10 most relevant ports, correct? (highest number of bytes or stream) example: exit-streams-opened 80=5178868,182=1092,443

Re: [tor-dev] onionoo.tpo stuck at 2017-01-27 13:00

2017-01-29 Thread Karsten Loesing
On 28/01/17 10:23, Karsten Loesing wrote: > On 28/01/17 10:06, nusenu wrote: >> >> >> Karsten Loesing: >>> If you notice similar problems in the future, be sure to let us know! >>> We do have a few checks in place, but this issue slipped through >>> somehow. >> >> >> I assume you are already aware