Hi Alex,
We are very sorry to hear about the problems our measurements caused. Up
until yesterday, we had received no reports of them triggering these kinds
of responses from providers. However, yesterday we heard a very similar
story from another relay operator using Hetzner.
Thanks for sharing
>> On Tue, Jan 14, 2014 at 2:14 PM, gwen hastings wrote:
>>> ...
>>> I am looking at resurrecting
>>>
>>> mixmaster, mixminion and nym.alias.net nymserver designs from the
>>> various code wastebaskets and retrofit them with some newer encryption
>>> technology based on curve25519 and poly-1305 li
Moritz and Jeroen,
Thank you both.
I tried both your ideas but the system is set to prevent the time being changed
as you thought.
Another plea to the VPS controllers and it was corrected. So the lesson there
is presume it is the VPS set-up first and foremost.
You both should know that the conc
Hello there,
We're running a Tor relay (not exit) on a virtual private server at
Hetzner for about a year. On Wednesday January 8th, we decided to take
part in the "Trying Trusted Tor Traceroutes" [1] research experiment.
There have been various calls for participation on public mailing lists
[2]
Hi,
if the time difference is too big, NTP will refuse to touch the clock
altogether. You can force an update by the '-g' option. However,
the adjustment might still be slow. I'd do the following (as root):
# hwclock --set --utc --date="2014-01-14 22:05:35"
# ntpd -qg
The first comman
On 2014-01-14 21:05, I wrote:
> Jeroen,
>
> Thank you. It did that but I can't see a change.
NTP adjusts slowly, as your clock is 6+ hours off, you should force the
timesync first, eg with with rdate (apt-get install rdate):
rdate -v ntp.xs4all.nl
should do the trick. Then after that make sure
Jeroen,
Thank you. It did that but I can't see a change.
The VPS person said it is set to UTC. Previously on another VPS it was another
relay in the ?circuit which had the time difference.
Now I see this:-
Our clock is 6 hours, 25 minutes behind the time published in the consensus
network stat
Hello all,
on 14.01.2014 01:17, Drake Wilson wrote:
> Since UDP is a connectionless datagram protocol, there is no
> distinguished "listening" state. It seems more likely that those are
> sockets for outgoing DNS requests. Have you monitored the traffic on
> those ports to see what it is?
Than
Complementing:
tcpdump -w "$udpport".cap port "$udpport"
On Mon, Jan 13, 2014 at 9:17 PM, Drake Wilson wrote:
> Quoth Wollomatic , on 2014-01-14 00:29:39 +0100:
> > Since I thought Tor only uses TCP may this be a security problem with my
> > server?
>
> Since UDP is a connectionless datagram
On 2014-01-14 12:38, I wrote:
> Does anyone know how to get past this to get the exit running on Debian
> 6, please?
>
> Our clock is 6 hours, 48 minutes behind the time published in the
> consensus network status document (2014-01-14 11:00:00 UTC).
apt-get install ntp
would be a good start.
G
* I schrieb am 2014-01-14 um 12:38 Uhr:
> Our clock is 6 hours, 48 minutes behind the time published in the
> consensus network status document (2014-01-14 11:00:00 UTC). Tor needs
> Does anyone know how to get past this to get the exit running on Debian 6,
> please?
Do you use a VPS? You basica
Does anyone know how to get past this to get the exit running on Debian 6, please? Our clock is 6 hours, 48 minutes behind the time published in the consensus network status document (2014-01-14 11:00:00 UTC). Tor needs an$Jan 13 23:11:25.000 [notice] I learned some more directory information,
Hi Thomas,
> However, something seems to have changed recently, since right now I'm
> blasting
> through about double my usual bandwidth (~25 MB/s) with the two tor jobs at
> only ~60% CPU usage each while previously it was always CPU limited.
Maybe your are running on a VPS and the dynamically
13 matches
Mail list logo
