Damian Johnson wrote on 14.12.2011:
> Hi Stephan. This is the first that I've heard of connection panel
> issues related to upgrading. Here's some things to check...
> - When connection resolution fails several times arm falls back to
> another connection resolver, logging a notice as it does so.
> Lastly, get to know and love using Tor bridges:
Bridges are not intended for use by the general population, but by
people who truly need them and/or cannot reach Tor any other way.
Also, AFAIK, the directory fingerprints in the source code more
directly address the 'non-genuine Tor net' thing.
_
> [1] OB: bt traffic hurts the tor network. You should not use bt with tor.
All traffic 'hurts' the Tor network. You should not use your computer with Tor.
Oh, wait, yeah, that'll never works :)
I think it's time to stops negging BT. There are other equally bulk uses.
And they'll all appear in ti
wakeupneo...@safe-mail.net wrote:
What began as a simple reply to a Tor user on the subject of
downloading PDF files through Tor, turned into a wealth of
information on Tor OPSEC. I am adding this post to the list
because others might find it as useful as I have. Cheers.
Origin of discussion:
ht
On 2011-12-14, John Case wrote:
>
> Let's say I run an exit node, and I have a 10 Mb/s connection.
>
> I join up, run for a while, get qualified as a good exit, speed checks out
> at 10, and so on. All is well.
>
> But then let's say that, at the OS level, I rate limit one of the TCP
> ports I al
> I am not interested in reopening the debate, but now that some time has
> passed, I *would* like to find out if this policy was ever codified and
> enacted ?
Yes, though neither of the relays that were flagged for that reason
are still around.
https://trac.torproject.org/projects/tor/wiki/doc/ba
Let's say I run an exit node, and I have a 10 Mb/s connection.
I join up, run for a while, get qualified as a good exit, speed checks out
at 10, and so on. All is well.
But then let's say that, at the OS level, I rate limit one of the TCP
ports I allow to exitto a much lower level - let's s
A year or so ago we had a fairly rough thread here wherein it was proposed
that certain combinations of open ports would be labeled as "bad exits",
regardless of actual behavior. For example, it was proposed that running
only TCP 21,23,80 (for instance) would be considered "bad".
I am not i
On Wed, 7 Dec 2011, grarpamp wrote:
HS (server) and client (user) can share an access key. Yada.
But some HS want to enforce user is running non-exit relay.
So relay must somehow sig client, or the reverse, and
publish to DHT for query by HS before grant access.
Yet broker so relay IP in DB !=
> For what it's worth, I don't think this is actually related to the arm
> upgrade, I would guess that Stephan may have also recently updated to
> Tor 0.2.3.9; when I upgraded a node to 0.2.3.9 I also found that the
> connections panel behavior changed
Hmm, I wouldn't expect that. I'll try running
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/14/2011 12:58 PM, Damian Johnson wrote:
> Hi Stephan. This is the first that I've heard of connection panel
> issues related to upgrading. Here's some things to check... - When
> connection resolution fails several times arm falls back to anothe
Hi Stephan. This is the first that I've heard of connection panel
issues related to upgrading. Here's some things to check...
- When connection resolution fails several times arm falls back to
another connection resolver, logging a notice as it does so. Do you
have any connection related log messag
Hi!
Today my Debian/stable box got a new arm version (tor-arm
1.4.2.4-1~bpo60+1 -> 1.4.4.1-1~squeeze).
But now the second page with the connections is empty while netstat is
showing connections. I restarted tor and switched from control port to
control socket, but nothing changes.
Does anyon
13 matches
Mail list logo
