Matt Helps:
> Hello.
>
> The node we run is in our library and we have a raspberry pi SSH'ed into
> the node and an LCD displaying the output from Arm. Arm is bugging out on a
> random basis and appears to be receiving a C keystroke that I believe is
> the clear log command. I ran the pi with no k
torser...@datakanja.de:
> From the information, i can gather on my own personal computer, i can
> see, that almost every operating system sends out greetings to servers
> in akamai's reach, a company that happens to have contracts with
> microsoft and whatnot.
> Reading about their business, i find
Aaron Hopkins:
> I tried configuring this a while ago, but got confused by what
> appeared to be conflicting documentation for IPv6 exit policies. Is
> the ExitPolicy for IPv6 completely separate (only using
> accept6/reject6 lines) or does it also make use of lines like
> "ExitPolicy accept *:80"
blaatenator:
>> * Port 25
>> * Port 194
>> * Port 465
>> * Port 587
>> * Port 994
>> * Port 6657
>> * Ports 6660-6670
>> * Port 6697
>> * Ports 7000-7005
>> * Port 7070
>> * Ports 8000-8004
>> * Port 9000
>> * Port 9001
>> * Port 9998
>> * Port
Were you using the
Just a guess:
iirc, putting an asterisk (*) for ExitPolicies, it's counted as
AF_UNSPEC, thus adding the rule for both ipv6 and ipv4.
Since policy rules are considered in the order they're listed (ie rules
stated first override later rules), the "ExitPolicy reject6 *:*" being
first, counts as rejec
jchase:
> Hello,
> Can anybody help me figure out why my bridge has stopped showing the
> flags fast, running and stable? Especially stable, I would love to get
> that flag back. I run two bridges, on two different Rasp Pi's, the one
> with a globe fingerprint of B08284109C72C81ACF5866A17A4CC64CE3E
If I recall correctly: Policies with '*' for the address count as both
ipv4 and v6 policies, it is possible to use 0.0.0.0 for v4 and [::] (I
think) for v6-specfic policies.
spriver:
> Hi,
>
> I just activated IPv6 support for my two exit relays today, but I do
> not unterstand/misconfigured the
Running a relay and hidden service should also should be considered, as
deanonymizing an HS by correlation to another relay seems more dangerous
than unmasking a client+relay.
As far as I know, tor only does anything about the former if accounting
is also enabled, which will give the following war
tor-server-crea...@use.startmail.com:
> should relays add some lines to torrc like reject *.fingerprint?
The authorities should be rejecting the relays / dropping their traffic
soon, I assume now they're trying to contact the operator before doing that.
On another note, reject allows cidr notatio
Tom van der Woerdt:
> Should they actually be blocked though?
>
> I mean, it's a lot of relays, but they're also contributing actual exit
> bandwidth and it's not like they're spread over hundreds of /16s.
I was just about to write a bit of clarification actually:
They shouldn't be in a position
Markus Koch:
> possible or do I have to ask my hosting company for the install on a
> shared server?
I think it would not be recommended on a shared server for reasons
ranging from less-private privkeys to a company that sells shared
hosting probably wont be letting you run a relay in the first pl
Does this happen to be "your" node?
https://globe.torproject.org/#/relay/4544D4026D447CDA4F8E7F22ED73E8565CCA569E
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
12 matches
Mail list logo
