Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
Re: Looking for tor users experiencing crashes
From: Robert Watson (rwatsonFreeBSD.org)
Date: Thu May 04 2006 - 11:19:22 CDT
On Mon, 1 May 2006, Robert Watson wrote:
> On Mon, 1 May 2006, Peter Thoenen wrote:
>> Its a regression.
>> See: http://www.freebsd.org/cgi/query-pr.cgi?pr=95180
>> I am the tor-devel maintainer and not only do I get private emails about
>> this at least once a week, I am expereincing it myself and also hear about
>> it on both the OFTC and Freenode tor channels usually every couple days.
>> Enough folk have brought it up that Arma (lead tor developer) is
>> considering NOT recommended FBSD 6 as a server platform for tor in server
> It's a pity this wasn't brought to my attention sooner, or there might have
> been a chance to work on it for 6.1-RELEASE, especially given that it sounds
> like it has been a moderately long-standing problem. The first I heard
> about it was a few days ago from someone else at cam.ac.uk, and since then
> I've been trying to find information. Among other things, I attempted to
> contact you by private e-mail but didn't hear anything back.
I'd like to work with you to track this down, but am leaving on travel on
Monday for a week to attend the FreeBSD Developer Summit, BSDCan, etc, in
Ottawa, Canada, so won't be available online much during that period. Getting
some basic information now would be helpful.
Robert N M Watson
> Up front, it sounds like we need to do a bit of fact gathering, and if
> possible, a bit of simplication of the configuration to try and isolate the
> Specifically, it sounds like the software configuration on your system is
> complex, and it would help to be able to narrow things down a bit. For
> example, you mention pf being configured on the box. A first step would be
> if you could include in the PR a copy of the dmesg output of your box (is it
> SMP?), as well as the kernel configuration file, rc.conf, loader.conf, etc.
> It also sounds like significant load is involved in triggering the bug. As
> someone who hasn't used Tor, and without significant bandwidth resources
> available to test it, a bit of quantification of the type of load would be
> very helpful. For example, if I were running in your configuration, would I
> expect to see 128kbps, 1mbps, 10mbps, 100mbps, 1gbps traffic, etc. Would it
> primarily be via the TCP protocol, or other protocols? Are we talking about
> a few very busy connections, or tens of thousands of less busy connections?
> Does the system generate much DNS traffic? Is the application a
> multi-process application, a multi-threaded application? If you run netstat
> and netstat -na at any given moment, how many open sockets might I see?
> Could you send me typical output from top -S, netstat -m, systat -vmstat 1?
> If hardware resources are available, it would be good to try running with a
> simplified configuration, in order to determine that we're not looking at a
> more complex feature interaction. For example, if you run on a vanilla
> kernel, without pf, etc, compiled in or loaded, does the reboot still occur,
> or does it, for example, require that pf also be loaded?
> Do you have a serial console attached to the system? When the reboot occurs,
> is there any interesting (or even boring) output on the serial console -- for
> example, warnings about load, fault messages, etc? If you are using a serial
> console but there is no output at all (you immediately see the beginning of
> the bios or OS boot loader after legitimate looking earlier console output),
> that's also extremely useful to know.
> Are you currently compiling any debugging features in? Could you try
> compiling in INVARIANTS? FWIW, spontaneous hardware poweroff and reboot can
> be tricky to track down, but we can see what we can do.
> I don't have the resources or setup to run Tor in server mode, and can't
> easily arrange for them. As such, I need to rely on you (or someone else) to
> work with me in detail to get this sorted out, so I will be unable to
> reproduce it directly.
> Robert N M Watson
freebsd-securityfreebsd.org mailing list
To unsubscribe, send any mail to "freebsd-security-unsubscribefreebsd.org"