any middlemen seeing DoS currently?

[Geoff Down]

Crashed again after only 2 hours:
This was about 20 minutes beforehand,
%CPU %MEM      VSZ    RSS  TT  STAT STARTED      TIME
0.0  1.6    39784  10400  ??  S     4:03AM   1:32.40

Nov 11 04:03:06.129 [Notice] Tor v0.2.0.31 (r16744). This is 
experimental software. Do not rely on it for strong anonymity. (Running 
on Darwin Power Macintosh)
Nov 11 04:03:06.177 [Notice] Initialized libevent version 1.4.7-stable 
using method kqueue. Good.
Nov 11 04:03:06.198 [Notice] Opening OR listener on 0.0.0.0:9001
Nov 11 04:03:06.219 [Notice] Opening Socks listener on 127.0.0.1:9050
Nov 11 04:03:06.299 [Notice] Opening Control listener on 127.0.0.1:9051
Nov 11 04:04:23.566 [Notice] Self-testing indicates your ORPort is 
reachable from the outside. Excellent. Publishing server descriptor.
Nov 11 04:04:53.299 [Notice] Performing bandwidth self-test...done.
Nov 11 06:05:20.894 [Notice] We tried for 15 seconds to connect to 
'[scrubbed]' using exit 'johndoe'. Retrying on a new circuit.

Should I be logging at info level? It's a lot of data...

GD
On 10 Nov 2008, at 03:19, Nick Mathewson wrote:

> On Fri, Nov 07, 2008 at 01:38:28PM +0100, Eugen Leitl wrote:
>>
>> I've seen continuous table state increase since about >3.5 hours.
>> It went up from 1 k baseline to 5 k.
>>
>> Anyone else seeing this? Any alternative explanation to DoS? (ISP
>> throttling?).
>
>
> Judging by the timing, I'd think it might be related to a bug we only
> uncovered on Friday.  Why Friday?  That was the first time that a
> directory authority's certificate expired before it could be replaced.
> The bug was that clients repeatedly asked directory caches for a new
> certificate over and over, without noticing that they were getting
> something expired and deciding to wait for a while.
>
> That bug should be fixed in newer versions of Tor.  Also, all the
> authority operators should (if we can make them) get way more careful
> about checking certificate expiry times.
>
> -- 
> Nick