This is off-topic, but isn't UDP making data retention more difficult
than TCP/IP.
No.
2008/12/19 Eugen Leitl eu...@leitl.org
This is off-topic, but isn't UDP making data retention more difficult
than TCP/IP.
On Fri, Dec 19, 2008 at 12:23:25PM +0100, slush wrote:
No.
This monosyllabic answer no doubt comes from in-depth knowledge
of legal requirements in regards to data retention for ISPs in Germany?
2008/12/19 Eugen Leitl [1]eu...@leitl.org
This is off-topic, but isn't UDP making
On Fri, Dec 19, 2008 at 01:00:36PM +0100, Eugen Leitl wrote:
On Fri, Dec 19, 2008 at 12:23:25PM +0100, slush wrote:
No.
This monosyllabic answer no doubt comes from in-depth knowledge
of legal requirements in regards to data retention for ISPs in Germany?
Yes.
2008/12/19
On Fri, Dec 19, 2008 at 11:24:01AM +0100, eu...@leitl.org wrote 0.1K bytes in 3
lines about:
:
: This is off-topic, but isn't UDP making data retention more difficult
: than TCP/IP.
How would UDP make data retention more difficult?
--
Andrew
Am 19.12.2008 um 11:24 schrieb Eugen Leitl:
This is off-topic, but isn't UDP making data retention more difficult
than TCP/IP.
Since you seem to talk about Germany: Again, data retention does and
will not happen on a per-packet basis and especially not on the
transport layer (TCP/UDP)
On Fri, Dec 19, 2008 at 08:23:40AM -0500, pho...@rootme.org wrote:
On Fri, Dec 19, 2008 at 11:24:01AM +0100, eu...@leitl.org wrote 0.1K bytes in
3 lines about:
:
: This is off-topic, but isn't UDP making data retention more difficult
: than TCP/IP.
How would UDP make data retention more
On Fri, Dec 19, 2008 at 02:32:57PM +0100, Sven Anderson wrote:
Since you seem to talk about Germany: Again, data retention does and
will not happen on a per-packet basis and especially not on the
transport layer (TCP/UDP) with the current law. There will only be
Thanks for the pointer.
Am 19.12.2008 um 14:32 schrieb Sven Anderson:
Am 19.12.2008 um 11:24 schrieb Eugen Leitl:
This is off-topic, but isn't UDP making data retention more difficult
than TCP/IP.
Since you seem to talk about Germany: Again, data retention does and
will not happen on a per-packet basis and
On 12/19/08, coderman coder...@gmail.com wrote:
there are actually two issues (or more?) for non-server Windows
running Tor. the usual problem Tor encounters is not related to the
number of concurrent attempts but to kernel non-paged memory resources
consumed to exhaustion when lots of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eugen Leitl wrote:
On Fri, Dec 19, 2008 at 08:23:40AM -0500, pho...@rootme.org wrote:
On Fri, Dec 19, 2008 at 11:24:01AM +0100, eu...@leitl.org wrote 0.1K bytes
in 3 lines about:
:
: This is off-topic, but isn't UDP making data retention more
This is off-topic, but isn't UDP making data retention more difficult
than TCP/IP.
I don't see how ..
tcpdump -s 1514 -w evidence.pcap ip proto \\udp
is any harder than ..
tcpdump -s 1514 -w evidence.pcap ip proto \\tcp
Now I guess you could rig a communications network that dealt
On Fri, Dec 19, 2008 at 7:54 AM, Lee ler...@gmail.com wrote:
...
Manipulating
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\GlobalMaxTcpWindowSize
and TcpWindowSize to 0xfaf00 (1027840) seemed to increase the time to
failure when running Tor and BitTorrent.
seems
On Tue, 16 Dec 2008 18:44:58 -0500 Roger Dingledine a...@mit.edu
wrote:
On Wed, Dec 17, 2008 at 12:28:37AM +0100, Mitar wrote:
From time to time I am getting this warning:
Failed to hand off onionskin. Closing.
Your computer is too slow to handle this many circuit creation
requests!
Hi!
On Sat, Dec 20, 2008 at 12:45 AM, Scott Bennett benn...@cs.niu.edu wrote:
That is odd. In my experience, tor has 4 + NumCPUs threads, except
right after a SIGHUP or during initialization. I normally only see two
threads do any work, and most of it is done by one of those two. Although
looking for advice -
I'm a member of one of those local organizations that regularly presents
information related to security, technology, etc to each other. I'm
wondering if there are suggestions for local advocacy and training
guidelines so not to mis-represent Tor (although it would be
Hallo,
I've been running a Tor exit node on one of my machines (Intel Dual
E2160 (1.8GHz), 2GB RAM, Xen domU for Tor, encrypted HDD) for some
months. It is on a shared 100MBit/s line (500GB in/out daily). I
have not configured any bandwidth limits within Tor.
Most of the time, the Tor process
On Fri, Dec 19, 2008 at 08:25:49PM -0600, onionrou...@gmail.com wrote 1.6K
bytes in 28 lines about:
: I'm a member of one of those local organizations that regularly presents
: information related to security, technology, etc to each other. I'm
: wondering if there are suggestions for local
On Sat, Dec 20, 2008 at 03:13:00AM -, 6cnf6c...@sneakemail.com wrote 1.1K
bytes in 26 lines about:
: Most of the time, the Tor process maxes out the CPU (85-100%),
: while memory consumption stays at ~10%; until today, this didn't
: pose much of a problem as log files show no errors and the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
pho...@rootme.org wrote:
On Fri, Dec 19, 2008 at 08:25:49PM -0600, onionrou...@gmail.com wrote 1.6K
bytes in 28 lines about:
: I'm a member of one of those local organizations that regularly presents
: information related to security, technology,
20 matches
Mail list logo
