headers
Peter Palfrader | 1 Apr 2005 02:24

Re: Can't start Tor under Debian

On Tue, 29 Mar 2005, Matthias Fischmann wrote:

> 
> > Since my initla email I have done "dpkg purge tor" followed by "apt-
> > get install tor" however the issue remains the same with error 
> > messages identical to my first post.
> > 
> >  /var/lib/tor is not owned by this UID 
> > > (113). You must fix this to proceed.
> > Couldn't access/create private data directory /var/lib/tor
> > Acting on config options left us in a broken state. Dying.
> 
> debian tends to be a little sloppy about removing directories.  as the
> error message is quite clear, why don't you simply

Debian is not sloppy about removing directories.  My package does it
perfectly right.  Maybe you just need to learn how to use dpkg.

--

-- 
 PGP signed and encrypted  |  .''`.  ** Debian GNU/Linux **
    messages preferred.    | : :' :      The  universal
                           | `. `'      Operating System
 http://www.palfrader.org/ |   `-    http://www.debian.org/
Permalink | Reply | 0 comments |
headers
Roger Dingledine | 1 Apr 2005 19:24
Picon
Favicon

Tor 0.1.0.2-rc is out

This is the second release candidate for the 0.1.0.x series. It makes
reachability detection work better. (A lot of people upgraded their
servers, but the servers thought they were unreachable so didn't publish
their descriptors -- oops.)

Please report any bugs, either in the installers or in Tor operation, so
we can get it perfect for an actual release: http://bugs.noreply.org/tor

http://tor.eff.org/download.html

  o Bugfixes on 0.1.0.1-rc:
    - Fixes on reachability detection:
      - Don't check for reachability while hibernating.
      - If ORPort is reachable but DirPort isn't, still publish the
        descriptor, but zero out DirPort until it's found reachable.
      - When building testing circs for ORPort testing, use only
        high-bandwidth nodes, so fewer circuits fail.
      - Complain about unreachable ORPort separately from unreachable
        DirPort, so the user knows what's going on.
      - Make sure we only conclude ORPort reachability if we didn't
        initiate the conn. Otherwise we could falsely conclude that
        we're reachable just because we connected to the guy earlier
        and he used that same pipe to extend to us.
      - Authdirservers shouldn't do ORPort reachability detection,
        since they're in clique mode, so it will be rare to find a
        server not already connected to them.
      - When building testing circuits, always pick middle hops running
        Tor 0.0.9.7, so we avoid the "can't extend to unknown routers"
        bug. (This is a kludge; it will go away when 0.0.9.x becomes
        obsolete.)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Menno Jonkers | 4 Apr 2005 10:02

NewsForge: Securing your online privacy with Tor

FYI: there's an introduction article on Tor at NewsForge:

 
http://business.newsforge.com/article.pl?sid=05/03/23/1552221&tid=19&tid=78

Cheers,

Menno
Permalink | Reply | 0 comments |
headers
Gene ENonymous | 4 Apr 2005 16:04
Picon
Favicon

4/4 CVS Build - Huge Jump in Responsiveness - Just ME?

Hey tor dev's,

I just updated my install of cvs (which seemed to be pretty broken since
Friday btw... and I have noticed a HUGE jump in responsiveness. For the
first time since I have been using tor, my tor proxied web browsing seems
almost unproxied speed. Is it just me or did you folks find something?

Anyway, COOOL!
Permalink | Reply | 11 comments |
headers
Roger Dingledine | 4 Apr 2005 21:39
Picon
Favicon

Re: 4/4 CVS Build - Huge Jump in Responsiveness - Just ME?

On Mon, Apr 04, 2005 at 09:04:43AM -0500, Gene ENonymous wrote:
> I just updated my install of cvs (which seemed to be pretty broken since
> Friday btw... and I have noticed a HUGE jump in responsiveness. For the
> first time since I have been using tor, my tor proxied web browsing seems
> almost unproxied speed. Is it just me or did you folks find something?

I hate to ask this, but are you sure you're using Tor? :) That's the
first thing that comes to mind when people say "wow, cool, Tor is just
as fast as my normal connection."

We have been making some improvements to speed and reliability, but not
that you describe above, I think.

It's also hard to get a consistent feel for performance changes in the
code, since the network itself varies so much in how hosed it is.

--Roger
Permalink | Reply | 10 comments |
headers
Gene ENonymous | 4 Apr 2005 22:10
Picon
Favicon

Re: 4/4 CVS Build - Huge Jump in Responsiveness - Just ME?

Yeah, I'm using it on my server clarity that's been running
for a while now. I sync to CVS once or twice per day and rebuild
- I "make install" if there are changes that are picked up by make.

Apparently this AM's build, while fast is unstable. I received the
following backtrace from a crash about 4 hours after build/launch this AM:
#0  0x48221feb in kill () from /usr/lib/libc.so.12
#1  0x48296a3f in abort () from /usr/lib/libc.so.12
#2  0x0806be65 in connection_dns_process_inbuf (conn=0x81d7d00) at dns.c:664
#3  0x0805ad3c in connection_handle_read (conn=0x81d7d00) at connection.c:954
#4  0x08071556 in conn_read_callback (fd=66, event=2, _conn=0x81d7d00)
    at main.c:358
#5  0x481f2a8c in event_process_active () from /usr/lib/libevent.so.0
#6  0x481f2c35 in event_loop () from /usr/lib/libevent.so.0
#7  0x481f2ab6 in event_dispatch () from /usr/lib/libevent.so.0
#8  0x08071f5d in do_main_loop () at main.c:949
#9  0x080714fd in tor_main (argc=6, argv=0xbfbffba4) at main.c:1588
#10 0x0808325b in main (argc=6, argv=0xbfbffba4) at tor_main.c:19
#11 0x0804bb22 in ___start ()

Also had the following error log...

Error Messages:
Apr 04 08:34:53.583 [warn] purge_expired_resolves(): Bug: Expiring a dns
resolve that's still pending. Forgot to cull it?
Apr 04 08:34:53.584 [warn] purge_expired_resolves(): Bug: Expiring a dns
resolve that's still pending. Forgot to cull it?
Apr 04 09:19:13.740 [warn] purge_expired_resolves(): Bug: Expiring a dns
resolve that's still pending. Forgot to cull it?
Apr 04 09:19:13.740 [warn] purge_expired_resolves(): Bug: Expiring a dns
(Continue reading)

Permalink | Reply | 8 comments |
headers
Zinco | 4 Apr 2005 22:21
Picon

RE: 4/4 CVS Build - Huge Jump in Responsiveness - Just ME?


On Monday, April 04, 2005 12:39 PM Roger wrote:

>I hate to ask this, but are you sure you're using Tor? :) That's the
>first thing that comes to mind when people say "wow, cool, Tor is just
>as fast as my normal connection."

>We have been making some improvements to speed and reliability, but not
>that you describe above, I think.

>It's also hard to get a consistent feel for performance changes in the
>code, since the network itself varies so much in how hosed it is.

The few times that I have used tor client recently I noticed that it was
very fast as compared to before.

I also tried running tor server 0.1.0.1 on windows xp sp2 again and the
trouble I have been having seemed to be worse.  The behavior makes me think
it is a conflict with explorer.exe (not to be confused with internet
explorer).

Zinco
Permalink | Reply | 0 comments |
headers
Roger Dingledine | 4 Apr 2005 22:42
Picon
Favicon

Re: Tor 0.1.0.1-rc is out

On Wed, Mar 30, 2005 at 02:32:30AM -0600, Mike Perry wrote:
> Awesome. Hidden services are a *LOT* quicker. At least for web.

Great.

> Though, as an aside, what is the potential weakness for them that was
> mentioned offhand in your latest draft paper? Is this
> exacerbated/lessened/unchanged by the changes?

Well, there are a number of problems. One of the biggest is that if the
adversary owns a few Tor servers, then over time as the hidden service
makes rendezvous circuits, the adversary's server is likely to end up
as the first hop on the path. What makes it especially bad is that the
adversary can *induce* rendezvous circuits by accessing the hidden service
as normal. If the hidden service is not a Tor server, then it's quickly
clear from timing that the guy who just launched the circuit is probably
the operator of the hidden service. And if he is a Tor server, then basic
predecessor attacks (http://freehaven.net/anonbib/author.html#wright02,
http://freehaven.net/anonbib/author.html#wright03) probably work well.

> Also, got a few other random questions:
> 
> >     - Better handling for heterogeneous / unreliable nodes:
> >       - Annotate circuits w/ whether they aim to contain high uptime nodes
> >         and/or high capacity nodes. When building circuits, choose
> >         appropriate nodes.
> 
> Are there any plans to use the ReadHistory/WriteHistory fields in the
> directory servers to also guide circuit creation? Like choosing nodes
> whose bandwidth history is less than their average?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Roger Dingledine | 4 Apr 2005 23:29
Picon
Favicon

Re: 4/4 CVS Build - Huge Jump in Responsiveness - Just ME?

On Mon, Apr 04, 2005 at 03:10:27PM -0500, Gene ENonymous wrote:
> Apr 04 08:34:53.583 [warn] purge_expired_resolves(): Bug: Expiring a dns
> resolve that's still pending. Forgot to cull it?

Hi Gene,

This is an interesting bug. Has anybody else been seeing it?

I'm not sure what it is, yet. It looks like it's happening pretty
often, though? Did you get this warn message previously, or is today
the first day?

One possibility is that it could be pthread bugs on netbsd. Could you
comment out the "#define HAVE_PTHREAD_CREATE 1" line in orconfig.h,
recompile, and see whether it continues to happen?

Thanks,
--Roger
Permalink | Reply | 7 comments |
headers
Gene ENonymous | 4 Apr 2005 23:56
Picon
Favicon

Re: 4/4 CVS Build - Huge Jump in Responsiveness - Just ME?

Hey Roger,
I did not start seeing this error in my logs (now that I look back) until
April 3, 9AM EST CVS Build. Before that, the log file is pretty clean
although CVS builds from 3/30 to 4/3 were unstable at best.

I've recompiled and launched...I'm on my way home and will
be back online in a couple hours or so...will report back
if the pthread hack below produces less "Bug:" messages.

Thanks,
gene

On Mon, April 4, 2005 4:29 pm, Roger Dingledine said:
> On Mon, Apr 04, 2005 at 03:10:27PM -0500, Gene ENonymous wrote:
>> Apr 04 08:34:53.583 [warn] purge_expired_resolves(): Bug: Expiring a dns
>> resolve that's still pending. Forgot to cull it?
>
> Hi Gene,
>
> This is an interesting bug. Has anybody else been seeing it?
>
> I'm not sure what it is, yet. It looks like it's happening pretty
> often, though? Did you get this warn message previously, or is today
> the first day?
>
> One possibility is that it could be pthread bugs on netbsd. Could you
> comment out the "#define HAVE_PTHREAD_CREATE 1" line in orconfig.h,
> recompile, and see whether it continues to happen?
(Continue reading)

Permalink | Reply | 0 comments |

Gmane