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

[Gordon Morehouse]

-----BEGIN PGP SIGNED MESSAGE-----
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.

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

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJSdnj0AAoJED/jpRoe7/uj/H4H/3XYsVHbX9eYXAR/iEXAeSa4
NeBTSeD4oevmHjPeaoNUrbVsT0Da62KYSxaZUg2BOv1GCfNGXps1+uyYhsOOYXwf
QpoF0DR1aDImC2rT7EZ8N26CuOFOw8tGHjBAhXb0Is7RYSzcHPTknCGumNPJjurX
fzMMAioZXl6GjM8m3l3Bclf05duM0rgvpau3JUKI/AaPVedy1jnrPSZatWjQk2F3
GxkpfPxxvh801ye6nOqOMS3SqDpgtepUo4HGjYt5HRPR1EgYnxJQ1tlVmJzz6pLt
QgBh46afQFr7KFKdgiohj3mXa8MyX48jPqFk8scaWCLl4DslBU9/iZHvf9B/alg=
=sYUu
-----END PGP SIGNATURE-----
-------------- 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>