Hello!
I'm in the process of re-writing Shadow's traffic generation tool called tgen
[0], which now depends on shutdown() for two communicating tgen nodes to inform
each other that they have no more to send (i.e. to perform graceful connection
shutdowns). The shutdown() functionality is useful
> On Mar 28, 2018, at 12:23 PM, David Fifield wrote:
>
> On Wed, Mar 28, 2018 at 10:57:13AM -0400, Rob Jansen wrote:
>> In a recent connectivity test to the default obfs4 bridges [0], we found
>> that we are unable to connect to 10 or so of them (from open network
Hi,
In a recent connectivity test to the default obfs4 bridges [0], we found that
we are unable to connect to 10 or so of them (from open networks, i.e., no
local filtering).
Is this a feature, like some of them only respond to users in certain parts of
the world? Or is this a bug, like the de
Thanks for the detailed write-up Mike! Theoretically, moving to QUIC seems
great; it seems to solve a lot of problems and has enough advantages that we
could just run with it.
I'll reiterate some of my primary concerns that I gave in Rome:
- I think it would be a mistake to push forward with s
> On Mar 25, 2018, at 12:13 PM, Sebastian Hahn wrote:
>
>
>> On 24. Mar 2018, at 13:50, Rob Jansen wrote:
>>> I think moria1 runs its own, and Faravahar runs its own. I've lost track
>>> of the others, but I'd guess that bastet also runs its own,
> On Mar 23, 2018, at 8:21 PM, Roger Dingledine wrote:
>
> I believe there are no scanners that supply answers to multiple directory
> authorities.
>
Great! IIRC, at one point in the distant past this was not the case.
> You could in theory check whether this is true in practice by seeing if
Hi,
I understand that the current bandwidth measurement system is far from ideal,
but I am wondering about how the current system works. Does each bandwidth
authority also run a bandwidth scanner? Or is it possible that the results from
a bandwidth scanner is supplied to multiple authorities?
> On Mar 7, 2018, at 12:34 PM, Rob Jansen wrote:
>
> Hi Florentin,
>
> I've added some comments below.
(I just found out that Aaron responded to your reply this morning, but I didn't
get that email (it probably got stuck somewhere in the NRL email filters).
Sorry
Hi Florentin,
I've added some comments below.
Overall, I think a useful discussion for the community to have is to discuss
whether or not we think Waterfilling is even a good idea in the first place,
before you go ahead and do a bunch of work writing and fixing a proposal that
may just end up
> On Aug 26, 2016, at 2:15 AM, grarpamp wrote:
>
>> On Fri, Aug 26, 2016 at 01:42:38AM +, Liu, Zhuotao wrote:
>>> We hope to have an estimate about computation capacity of Tor relays. For
>>> instance, how many circuits a relay can maintain when its CPU is driven to
>>> about 100%? On averag
> On Mar 28, 2016, at 5:04 AM, Karsten Loesing wrote:
>
> Signed PGP part
> On 25/03/16 16:24, Rob Jansen wrote:
> >
> >> On Feb 11, 2016, at 2:51 PM, Rob Jansen
> >> wrote:
> >>
> >>> These statistics are being collected for years now,
> On Feb 11, 2016, at 2:51 PM, Rob Jansen wrote:
>
>> These statistics are being collected for years now, and it might take
>> another year or so for relays to upgrade to stop collecting them. So
>> what's another month.
>>
>
> Agreed.
Hi Karsten,
> On Jan 19, 2016, at 3:45 AM, Karsten Loesing wrote:
>
> Signed PGP part
> On 15/01/16 23:00, Rob Jansen wrote:
> > Hello,
>
> Hi Rob,
>
> I'm moving this discussion from metrics-team@ to tor-dev@, because I
> think it's relevant for little-t-tor de
Hello,
Shadow versions 1.11.0 and 1.11.1 are now released!
https://github.com/shadow/shadow/releases/tag/v1.11.0
https://github.com/shadow/shadow/releases/tag/v1.11.1
These versions represent a huge engineering effort to provide transparent
support for plug-ins that use pthreads and that make bl
long term. So
far I have Shadow's built-in traffic generator running correctly with
the new approach, and am now working on Tor. None of this code is
public yet, but if you are interested in an example of how this would
work or want some early access to the code, drop me a message off-list.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I like the term "onion service" to refer to a service that requires
the use of Tor to access.
For onion services whose operators do not want their identities
discovered, I suggest renaming "hidden service" to "anonymous onion
service".
For onion se
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Ian,
Thanks for the link, and for working on the survey - this was long
overdue. I especially enjoy the mind map (Figure 5) which gives a quick
view of all of the work over the years. The community has been busy!
On the incentives front, I believ
Hi all,
In case anyone missed it, I released a new version of Shadow last week.
Download links and the release notes are available on the release page here:
https://github.com/shadow/shadow/releases/tag/v1.10.1
I've also copied them below in markdown for your convenience.
All the best,
Rob
===
> On Feb 16, 2015, at 5:43 AM, Florian Rüchel
> wrote:
>
>>> It would also help me a lot if you can direct me to papers or articles
>>> that have shown specific attacks that are known to work on the current
>>> network.
You might want to look into the Sniper Attack as an example of how to eval
Thanks for getting this started, Nick! I’ve added some comments and changes to
the trac ticket #12890.
All the best,
Rob
> On Dec 20, 2014, at 12:51 PM, Nick Mathewson wrote:
>
> Hi!
>
> So, Rob came up with this clever way to use help from an OS kernel to
> improve Tor's performance:
>
> ht
> On Nov 21, 2014, at 1:06 PM, David Goulet wrote:
>
> On 21 Nov (12:59:43), Rob Jansen wrote:
>>
>>> On Nov 21, 2014, at 10:40 AM, David Goulet wrote:
>>>
>>> Please see https://trac.torproject.org/projects/tor/ticket/13802 about
>>> the
> On Nov 21, 2014, at 10:40 AM, David Goulet wrote:
>
> Please see https://trac.torproject.org/projects/tor/ticket/13802 about
> the instrumentation part. We'll definitely have to talk more on the
> integration of Shadow and a userspace tracer but of what I got from
> Nick, it sounds totally doa
> On Nov 21, 2014, at 9:39 AM, George Kadianakis wrote:
>
> I also believe that some of these extra stats (e.g. "How many
> failures/anomalies do we observe?") should first be done on a privnet
> instead of the real network. That can give us some preliminary
> results, and then we can consider d
> On Nov 20, 2014, at 4:59 PM, David Goulet wrote:
>
> On 20 Nov (14:45:12), Rob Jansen wrote:
>>
>> Are there other HS performance improvements that we think may be ready by
>> January?
>
> On my part, I have a chutney network with an HS and clients that
Hi David, Roger,
I think it would be great if we could show off some HS performance improvements
at the next Sponsor R PI meeting in January, both as a way to show that we are
making progress on the performance front and also to help demonstrate our
agility and how quickly we can get results on
Let me try again more concisely:
Whats the most minimal (fastest) way to generate ‘orconfig.h' and 'or_sha1.i’
from a clean git clone of Tor master? Is there a make target for this?
-Rob
On Jul 11, 2014, at 5:17 PM, Rob Jansen wrote:
> Hi,
>
> Shadow uses CMake and a cust
Hi,
Shadow uses CMake and a custom build process to build the Tor source files into
a shadow-plugin (using Clang/LLVM and a custom pass). However, because my CMake
build file is not smart enough to know how to turn orconfig.h.in into
orconfig.h, I still have to run Tor through autotools first (
On Jun 24, 2014, at 7:59 AM, Karsten Loesing wrote:
> On 24/06/14 12:55, Soroosh Sardari wrote:
>> I want to run a small tor network with only 3 node, entry, router, and exit
>> node.
>> Also I want to set this three nodes in the client node without using
>> directory server.
>
> https://www.to
On Dec 21, 2013, at 4:13 AM, Karsten Loesing wrote:
> On 12/18/13 2:03 PM, Rob Jansen wrote:
>> On Dec 18, 2013, at 4:51 AM, Karsten Loesing wrote:
>>> I also
>>> aggregated observations similar to Torperf measurements, by plotting
>>> only median and int
On Dec 18, 2013, at 4:51 AM, Karsten Loesing wrote:
> Hi Rob, Florian,
>
> thanks for your replies! If you say these statistics may still be
> useful, then let's leave them in!
>
Great!
> I just worked on a slightly better visualization of the available data.
> The idea is that the most inte
> Date: Thu, 26 Jan 2012 16:39:34 +
> From: Steven Murdoch
> To: tor-dev@lists.torproject.org
> Subject: Re: [tor-dev] Simulating a slow connection
> Message-ID:
> Content-Type: text/plain; charset=us-ascii
>
> Hi Adam,
>
> On 20 Jan 2012, at 10:55, Adam Katz wrote:
>
>> Well, I myself did
- is there a shadow-dev in addition to shadow-support?:)
Not yet. Since you asked, it will be up in a few days:)
Join the shadow dev list at
https://wwws.cs.umn.edu/mm-cs/listinfo/shadow-dev
or send mail to shadow-...@cs.umn.edu
Thanks,
Rob
___
On 10/14/2011 08:00 AM, tor-dev-requ...@lists.torproject.org wrote:
On Tue, Sep 27, 2011 at 4:20 PM, Rob Jansen wrote:
> If you have the need to run Tor experiments, or are just interested in the
> Software, please try it out. We would love any feedback or comments or
> suggestio
Hello,
We've been exploring dynamic algorithms for throttling Tor clients.
We've come up with three algorithms that are easier to maintain than
static throttling (i.e. don't need to be reconfigured often), and
produce significant performance benefits for web clients at the expense
of bulk cli
Hello,
For the unaware, we have been working on the design and development of
Shadow, a simulator capable of running real binaries over a simulated
network, and a plug-in that runs real Tor. Shadow can simulate roughly
1000 Tor nodes in 10 GB of RAM and is easy to setup and use (no root
requi
35 matches
Mail list logo
