Re: [tor-relays] Webiron

Hi, you ISP opened that ticket so you answer the ISP. ~Josef Am 29.01.2016 um 03:31 schrieb 12xBTM: > My ISP just sent a ticket to me about the Webiron abuse, should I just > respond to the ISP? Or do I dare actually load that webiron site? > > On 26.1.16 23:10, Nicholas Suan wrote: >> Looks

Re: [tor-relays] tor-arm bandwidth state file -xxxx seconds is missing?

If I've understood your question: press i and select 1 second, then enter. Press h for other keyboard options. On Fri, 29 Jan 2016, at 12:17 AM, SuperSluether wrote: > How would I change the interval? Arm keeps telling me there's no armrc > loaded, and to see the sample file for options, but

Re: [tor-relays] What does this message mean in my tor logs?

> On 28 Jan 2016, at 12:38, Pat Scharmer wrote: > > Hi all, > > I’m running a server with a couple of relays and was getting good overall > performance (120+ Mbps) up until a couple days ago. For the last two days, > the log for one of the two relays is showing thousands

Re: [tor-relays] Should Onionoo consider relays with the same ip# to be part of the same family?

> On 27 Jan 2016, at 18:19, grarpamp wrote: > > On Wed, Jan 27, 2016 at 12:00 AM, Virgil Griffith wrote: >> No wrong answer---just wondering what is the community's vibe on this >> issue. I can go either way. > > Same IP excepting NAT is same box, kind of

Re: [tor-relays] Should Onionoo consider relays with the same ip# to be part of the same family?

> On 29 Jan 2016, at 07:20, Roman Mamedov wrote: > > On Fri, 29 Jan 2016 06:33:51 +1100 > Tim Wilson-Brown - teor wrote: > >> Tor already considers relays in the same IPv4 /16 to be in the same family. > > Maybe a step further in this would be to

Re: [tor-relays] Should Onionoo consider relays with the same ip# to be part of the same family?

On Fri, 29 Jan 2016 06:33:51 +1100 Tim Wilson-Brown - teor wrote: > Tor already considers relays in the same IPv4 /16 to be in the same family. Maybe a step further in this would be to autoextend manually declared families with all relays running on the same IPs of any

Re: [tor-relays] tor-arm bandwidth state file -xxxx seconds is missing?

Not hurting anything and in general if you see a message that's 'notice' that means 'this is fine, just for your information'. If it was a problem it would way it was a warning or error. On Thu, Jan 28, 2016 at 10:29 AM, SuperSluether wrote: > Ok, so just wait for arm to

Re: [tor-relays] tor-arm bandwidth state file -xxxx seconds is missing?

When arm starts it attempts to read tor's state file to get past bandwidth information. That is a notice level message, not an error, and it's simply telling you that it wasn't able to prepopulate all the data. Tor has changed its state file format which actually breaks that feature entirely. The

[tor-relays] tor-arm bandwidth state file -xxxx seconds is missing?

Found this error when checking my relay today: ARM_NOTICE Read the last day of bandwidth history from the state file (- seconds is missing) Every time I start arm, the -xxx seconds missing is different. The bandwidth graph is also stuck, but real-time data is still shown. Is this a

Re: [tor-relays] tor-arm bandwidth state file -xxxx seconds is missing?

Ok, so just wait for arm to get updated then? I guess as long as it's not hurting anything, it doesn't matter too much. On 01/28/2016 12:06 PM, Damian Johnson wrote: When arm starts it attempts to read tor's state file to get past bandwidth information. That is a notice level message, not an

Re: [tor-relays] Webiron

My ISP just sent a ticket to me about the Webiron abuse, should I just respond to the ISP? Or do I dare actually load that webiron site? On 26.1.16 23:10, Nicholas Suan wrote: Looks like Webiron is spamming again, and this time they're including a web bug in the mail to see if you've opened

Re: [tor-relays] What does this message mean in my tor logs?

Thanks Tim. Yes, I’m running unbound on the server configured to cache directly from the root DNS servers. It’s worked without issue until just a few days ago. I’ve refreshed the root hints file and restarted the service. It seems better at the moment… and throughput seems to have improved as