[tor-relays] max TCP interruption before Tor circuit teardown?

Gordon Morehouse gordon at morehouse.me
Sun Nov 3 17:41:56 UTC 2013

Hash: SHA512

Dan Staples:
> I am also running on a Pi Model B, 512MB RAM. How are you logging
> SYNs?

Ah yes, that's right.

You will find all the magic (very pre-alpha at the moment - it's
iptables commands in /etc/rc.local) in contrib/90_slowboards as part
of Cipollini:


I wouldn't bother with fail2ban right now, I've turned it off pending
some other experiments with total connection limits on the Pi.  I have
an open story to investigate making it work, right now it's just too
slow on the Pi:


So, try the iptables rules, change the ports to your ORPort (and
DirPort if any).  You'll note that there's a LOG target in there - for
me it appears in kern.log.

- -Gordon M.

> On Sun 03 Nov 2013 11:25:26 AM EST, Gordon Morehouse wrote:
>> ********* *BEGIN ENCRYPTED or SIGNED PART* *********
>> Dan Staples:
>>> This morning I got my first Tor traffic flood since upgrading
>>> to 2.4.x. Logs didn't say anything about not being able to
>>> handle the amount of circuit creation requests, but it showed a
>>> 200x increase in active TAP circuits (~400k/hour) and the
>>> traffic pattern is the same: Advertising 100kb bandwidth, but
>>> slammed with ~2Mb traffic.
>>> When I saw it, I checked my relay's flags, and it has the
>>> stable flag, and has been tagged stable for at least 3 days.
>>> It's been up for 7 days.
>>> I would love to contribute data to help correlate w/ your
>>> findings Gordon. Any metrics or logs that would be particularly
>>> helpful? I currently use NTop to measure traffic, but it's not
>>> very granular.
>> I'm still trying to scratch together enough time to analyze the
>> logs from the two floods I caught as they began in the past 10
>> days or so. One thing I am logging, which you're definitely not,
>> is hosts that send SYNs above the limit on my Raspberry Pi.  Are
>> you running on a slow machine or a VPS or what?  That might not
>> apply to you if you're not running on a slow machine - you may
>> have no need to limit SYNs or anything else, and that's probably
>> the case if your relay did not crash as a result of the flood.
>> During my last two floods, the relay survived the first (poorly,
>> with fail2ban becoming useless and chewing up half the CPU), and
>> was headshotted by the second - crash in less than 5 minutes.
>> I'm looking forward to getting the data together and providing a 
>> report for the community, but time ... my kingdom for the time to
>> do anything beyond work, sleep, eat, sh*t.
>>> I also currently don't use any iptables rules to throttle, but
>>> am happy to experiment with that if you want me to try out any 
>>> particular configurations.
>> Depends on the capacity of your hardware.  All my experimentation
>> has to do with low-end ARM boards, so the logs most useful to the
>> report *I* am planning to prepare on these events are logs of SYN
>> exceeds, and fail2ban logs.
>> Thanks very much for staying up to date and offering to
>> contribute - there is a real problem someplace, but it seems to
>> be mostly a Problem with a capital P for low-end hardware with
>> 512MB physical RAM, since those are the relays likely to actually
>> crash as a result of the floods.
>> Best, -Gordon M.
>>> Dan
>>> On 11/01/2013 05:30 PM, Gordon Morehouse wrote:
>>>> huh, well, near as I can tell, I didn't get Stable for any
>>>> time represented yesterday (2013-10-31) for the node
>>>> VastCatbox.
>>>> So maybe that theory is incorrect.  In that case I don't
>>>> know what would trigger the SYN flood behavior other than
>>>> Roger's idea about becoming an introducer for a popular HS,
>>>> but... eh... seems like a stretch, a node offering 2.5Mbps
>>>> that isn't flagged Stable?
>>>> -Gordon
>>>> On Fri, 1 Nov 2013 13:10:17 +0100, David Serrano 
>>>> <tor at dserrano5.es> wrote:
>>>>> On 2013-10-31 10:04:02 (-0700), Gordon Morehouse wrote:
>>>>>> I can't verify it, but my suspicion is this is happening
>>>>>> when I get my Stable flag (I have no idea if I'd gotten
>>>>>> it back this morning or not) or shortly thereafter.
>>>>> You can use
>>>>> https://metrics.torproject.org/relay-search.html and enter
>>>>> your IP address to figure that out.
>>>>> -- David Serrano GnuPG id: 280A01F9 
>>>>> _______________________________________________ tor-relays 
>>>>> mailing list tor-relays at lists.torproject.org 
>>>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>>> tor-relays mailing list tor-relays at lists.torproject.org 
>>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
********** *END ENCRYPTED or SIGNED PART* **********
>> _______________________________________________ tor-relays
>> mailing list tor-relays at lists.torproject.org 
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> -- http://disman.tl OpenPGP key: http://disman.tl/pgp.asc 
> Fingerprint: 2480 095D 4B16 436F 35AB 7305 F670 74ED BD86 43A9 
> _______________________________________________ tor-relays mailing
> list tor-relays at lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays



More information about the tor-relays mailing list