On 2018-02-08 19:48, to...@protonmail.com wrote:
> Whatever you decide, I think you should have this mentioned in the setup docs
> for bridges.
We have the following explanation in the manual:
"Administrative contact information for this relay or bridge. This line
can be used to contact you if y
On 2018-02-11 00:43, nusenu wrote:
>> Possible advantages are:
>> - Relay Search would support searching for bridges by contact information.
>> - People who keep a watching eye on the Tor network could reach out to
>> bridge operators to inform them that they're running an outdated tor/PT
>> vers
On 2018-02-11 00:43, nusenu wrote:
- we could tell operators that running obfs3 and obfs4 is a bad idea
Are you saying obfs3 and obfs4 shouldn't run simultaneously on the same
bridge? That would be good to know indeed.
- we could tell operator that exposing their vanilla ORPort is a bad
id
Once the decision has been made to publish contactInfo, people with
access to the current contactInfo (bridgeDB, isis?) should sent current bridge
operators
a pre-notice about the upcoming change so they have a chance to react to it.
I assume you will not implement this change retroactively (only
On 2018-02-12 11:39, nusenu wrote:
> Once the decision has been made to publish contactInfo, people with
> access to the current contactInfo (bridgeDB, isis?) should sent current
> bridge operators
> a pre-notice about the upcoming change so they have a chance to react to it.
>
> I assume you wil
On 2018-02-12 11:19, Alexander Dietrich wrote:
> On 2018-02-11 00:43, nusenu wrote:
>
>> - we could tell operators that running obfs3 and obfs4 is a bad idea
>
> Are you saying obfs3 and obfs4 shouldn't run simultaneously on the same
> bridge? That would be good to know indeed.
Citing from the I
>> If you block the ORPort, won't the reachability check fail?
>
> Fine question. At least this has been the case in the past, though I
> know there was discussion and maybe development to overcome this
> weakness. But even if it's not possible yet, having bridge contact
> information would allow
Am Montag, 12. Februar 2018 um 12:33 schrieb nusenu
:
If you block the ORPort, won't the reachability check fail?
Fine question. At least this has been the case in the past, though I
know there was discussion and maybe development to overcome this
weakness. But even if it's not possible ye
Hi all,
So in general 0.3.3.1-alpha-dev and 0.3.3.2-alpha running on two nodes
without any connection limits on the iptables firewall seems to be a lot
more robust against the recent increase in clients (or possible [D]DoS).
But tonight for a short period of time one of the relays was running
I see this occasionally. It's not specific to 0.3.3.x. I reported it back in
October 2017:
https://lists.torproject.org/pipermail/tor-relays/2017-October/013328.html
Roger replied here:
https://lists.torproject.org/pipermail/tor-relays/2017-October/013334.html
MaxMemInQueues is set to 1.5 GB b
On 12 Feb (20:09:35), Stijn Jonker wrote:
> Hi all,
>
> So in general 0.3.3.1-alpha-dev and 0.3.3.2-alpha running on two nodes
> without any connection limits on the iptables firewall seems to be a lot
> more robust against the recent increase in clients (or possible [D]DoS). But
> tonight for a s
Hi Tor & Others,
On 12 Feb 2018, at 20:29, tor wrote:
I see this occasionally. It's not specific to 0.3.3.x. I reported it
back in October 2017:
Thx, I more or less added the version in the subject to clearly indicate
it was on an alpha release
https://lists.torproject.org/pipermail/tor-r
Hi David,
On 12 Feb 2018, at 20:44, David Goulet wrote:
> On 12 Feb (20:09:35), Stijn Jonker wrote:
>> Hi all,
>>
>> So in general 0.3.3.1-alpha-dev and 0.3.3.2-alpha running on two nodes
>> without any connection limits on the iptables firewall seems to be a lot
>> more robust against the recent
On 12 Feb (21:14:14), Stijn Jonker wrote:
> Hi David,
>
> On 12 Feb 2018, at 20:44, David Goulet wrote:
>
> > On 12 Feb (20:09:35), Stijn Jonker wrote:
> >> Hi all,
> >>
> >> So in general 0.3.3.1-alpha-dev and 0.3.3.2-alpha running on two nodes
> >> without any connection limits on the iptables
On 12 Feb (19:44:02 UTC), David Goulet wrote:
>Wow... 1599323088 bytes is insane. This should _not_ happen for only 1
>circuit. We actually have checks in place to avoid this but it seems they
>either totally failed or we have a edge case.
>
>Can you tell me what scheduler were you using (look for
15 matches
Mail list logo
