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

Gordon Morehouse gordon at morehouse.me
Sun Nov 3 16:25:26 UTC 2013

Hash: SHA512

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.

- -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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x1EEFFBA3.asc
Type: application/pgp-keys
Size: 1749 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20131103/6de42c54/attachment.key>

More information about the tor-relays mailing list