Hi,
last night the log of one of my nodes showed within 2 minutes about 160 of
these messages. Traffic stats show that the incoming bandwidth increased from
the average of 300 Mbit/s to more than 400 Mbit/s, where at the same time
outgoing traffic dropped. From the peak I see, the requests must
Sebastian Hahn wrote on 13.01.2012:
> Yes, until a few days ago ides was - when it was online - voting along
> with the other dirauths. Now that the other dirauths upgraded, ides is
> left out and the warning happens. We might want to silence the warning,
> as we don't warn when a dirauth is total
Sebastian Hahn wrote on 13.01.2012:
>
> Ah, I see. ides not having a current consensus is different from ides
> being down. Ides still is running the stable Tor version and needs to be
> upgraded to 0.2.3.x to be allowed to vote along with the other dirauths,
> so it doesn't immediately know abo
Sebastian Hahn wrote on 13.01.2012:
>
> We've had quite a bit of trouble making a consensus in the past few
> days, tho these issues have been resolved as of two days ago or so.
> There were quite a few maintenance issues with the dirauths, and not all
> have been resolved yet, but a large enough
Hi,
just because I am curious: can someone from the tor authority
operators please explain what is going on the last days with
tor authorities. This morning (europe) ides is not available.
Thanks,
Klaus
signature.asc
Description: This is a digitally signed message part.
___
Sebastian Hahn wrote on 09.01.2012:
> Looks like dizum is fixed. Some overzealous firewall issue. Thanks for
> reporting it here!
Thanks for your quick reply.
Klaus
signature.asc
Description: This is a digitally signed message part.
___
tor-relays mai
Hi,
my relays are getting 500 error while fetching data from authority dizum.
Can someone explain what is happening with this tor authority?
Regards,
Klaus
14:25:51 [WARN] Received http status code 500 ("Internal Server Error") from
server '194.109.206.212:80' while fetching
"/tor/server/d/C
Just received another one. Is someone doing a widespread brute force?
Hope my ISP keeps cool.
Regards,
Klaus
signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://list
Hi,
within two days I received abuse complaints from my ISP that someone used my
exit node to brute force ssh accounts of two different ISP. Unfortunately I am
forced to block port 22 to avoid shutdown. Anyone else who suffered from such
attacks these days?
Regards,
Klaus
signature.asc
Desc
Damian Johnson wrote on 20.12.2011:
> Hi Klaus. The client count dialog works as follows:
>
> - If we are running as a bridge we prepopulate the number of clients
> we've seen per locale by calling "GETINFO status/clients-seen". If we
> aren't then we don't start with any results.
>
> - Whenever
Hi,
I am using arm to monitor 3 tor nodes running on the same box. On the
connection page I get very different results when pressing "c" to get the
client locale stats:
Node A - nothing happens
Node B - the window with the client locale stats is displayed
Node C - a message "Usage stats aren't
Thanks for the explanation. You are right. I mixed up socks port 9050 and
control port 9051.
Thanks,
Klaus
Damian Johnson wrote on 10.12.2011:
> Hi Klaus. This is the first I've seen that particular error. What's
> happening is that...
> - arm has configured TorCtl to listen to the control po
"Steve Snyder" wrote on 10.12.2011:
>
> Yes, I also have a local caching nameserver, pointed to by the "nameserver
>127.0.0.1" entry in /etc/resolve.conf. Also, it seems that Tor/libevent is
>smart enough to filter out duplicate DNS servers as 3 copies of "nameserver
>127.0.0.1" doesn't give
Andy Isaacson wrote on 10.12.2011:
> If it's a decent NIC (Intel or Broadcom) then I'd agree with you. If
> it's a RTL or other sub-par vendor / driver, then you're overly
> optimistic.
lspci shows:
01:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network
Connection
02:00.0 Ethernet
Hi,
I am no longer able to connect with ARM to one of my relays. ARM crashes with
the following error:
debian-tor@host:/home/user$ arm -i 127.0.0.1:4711
Traceback (most recent call last):
File "/usr/share/arm/TorCtl/TorCtl.py", line 710, in _loop
isEvent, reply = self._read_reply()
File
Sebastian Urbach wrote on 09.12.2011:
> I could imagine that this behavior has something to do with the
> current changes / test which are still ongoing. I requested a statement
> from Mike just a short while ago. Stay tuned ...
Thank you for pointing me to that posting. I read it but did not rea
Hi,
I am running two relays with the fingerprints
D223399907113A1F216AAA64997BC1D4CFA8E1AC and
945CBBA599808018749DDC4EBB592168F2858C1B. For the first relay I am observing a
significant usage drop down during the last 12 hours. The second runs as usual
with a high throughput. I am wondering wh
Andy Isaacson wrote on 03.12.2011:
> Since DNS is the most frequent UDP traffic you'll see on a Tor node,
> perhaps this is simply a symptom of high packet loss on your NIC.
It's a gigabit link, with at the moment only 30% load. I don't expect
significant packet loss.
> You could consider runnin
Moritz Bartl wrote on 03.12.2011:
> Yes, I see them, and grown accustomed to them. Not that often though.
Thanks. That makes it easier to ignore them :-)
signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
t
Hi,
my logs are full of these messages:
05:54:07 [NOTICE] eventdns: Nameserver 127.0.0.1 is back up
05:54:07 [WARN] eventdns: All nameservers have failed
At first I thought that the DNS of my ISP sucks, so I changed to Google Public
DNS. But the warnings are still there.
Google shows some old
After upgrading to 0.2.3.8 and setting NumCpus to 2 the messages are gone.
Regards,
Klaus
Klaus Layer wrote on 30.11.2011:
> Hi,
>
> I am getting many messages of this type on a node with 0.2.3.7-alpha:
>
> [NOTICE] We stalled too much while trying to write 192 bytes to addre
Hi,
I am getting many messages of this type on a node with 0.2.3.7-alpha:
[NOTICE] We stalled too much while trying to write 192 bytes to address
[scrubbed]. If this happens a lot, either something is wrong with your
network connection, or something is wrong with theirs. (fd 1304, type
Direct
Hi,
since 0.2.3.6-alpha the logs of my instances are full of these messages:
14:56:23 [WARN] (certificate lifetime runs from Nov 3 16:15:34 2011 GMT
through Nov 2 16:15:34 2012 GMT. Your time is Nov 03 13:56:23 2011 GMT.)
14:56:23 [WARN] Certificate not yet valid: is your system clock set
inc
Damian Johnson wrote on 21.10.2011:
> It's showing you the number of client connections that have used you
> per locale. On reflection I should be showing the number of _unique_
> clients instead - filed a ticket against myself for that:
> https://trac.torproject.org/projects/tor/ticket/4281
>
>
Hi,
I recently found the "Client locales" function on the connection page of ARM.
What exactly is the number behind the country code:
ir 223334 (%13)
us 188412 (%11) │
Hi,
My relays suddenly show the following warnings:
"Tried to establish rendezvous on non-OR or non-edge circuit."
Is this something I should worry about?
I am wondering why several of my relays shows that at nearly the same time.
Thanks,
Klaus
signature.asc
Description: This is a digitally
for PID file with
parameter PidFile or authentication cookie file with parameter CookieAuthFile?
Thanks,
Klaus
--
Klaus Layer
Walldorf, Germany
GPG Fingerprint: 466D 12F8 28A3 D137 A77E FC3B 271C 2D79 6F5E 94C9
signature.asc
Description: This is a digitally signed message part
27 matches
Mail list logo
