<p>I'm also having some problems with my rpi node going down every few days due to lack of resouces and needing a reset. Can you mail me with some of the alterations you made which might make it more stable? Thanks. T</p>
<div class="gmail_quote">On Jun 5, 2013 10:42 AM, <<a href="mailto:temp5@tormail.org">temp5@tormail.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I've been seeing these storms as well on my relay. I average something<br>
like 100 connections for weeks and weeks per the tor logs, but then<br>
suddenly it will jump into the thousands and I'll see the "Failed to hand<br>
off onionskin." and "Your computer is too slow to handle this many circuit<br>
creation requests!" messages.<br>
<br>
I wonder if it's some type of DDOS too.<br>
<br>
I thought about using this method<br>
(<a href="http://www.debian-administration.org/articles/187" target="_blank">http://www.debian-administration.org/articles/187</a>) on the relay and dir<br>
ports, but I'm not sure what sort of limits to set. Like does 1 Tor<br>
circuit = 1 iptables connection? Or if a user hits a webpage with 100 ads<br>
on it, maybe it would be 1 Tor circuit = 100 iptables connections?<br>
<br>
That's about as far as I got. I didn't want to break things by trying to<br>
fix another.<br>
<br>
> I did a lot of tuning on the Raspberry Pi and it's now much, much more<br>
> stable as a Tor relay, but just now I had another "circuit creation<br>
> storm." Interestingly, the Pi remained up, and my *router* crashed.<br>
> I've also seen huge bursts of circuit creation on a relay I run on a<br>
> VPS, but as it's a much more powerful box it rarely complains (and thus<br>
> I rarely notice).<br>
><br>
> This many circuits and outbound connections is highly unusual for the<br>
> small relay I'm running on the Pi. And this behavior definitely occurs<br>
> in bursts. Is this an outbound DDOS or an attack on Tor itself? If the<br>
> former (or maybe the latter), is there some way I could perhaps use<br>
> iptables to temporarily "clamp" the ability to open TCP connections when<br>
> Tor (or anything on the Pi) opens a number over some threshold in some<br>
> short period of time?<br>
><br>
> Here's log output (via 'arm') from the relay after my router crashed<br>
> twice, I went to the admin panel and noted hundreds of outbound<br>
> connections from my Tor box. Time is America/Los_Angeles.<br>
><br>
> │ 13:55:00 [ARM_NOTICE] Relay unresponsive (last heartbeat: Sat May<br>
> 4 13:54:14 2013)<br>
> │ 13:52:25 [WARN] Your computer is too slow to handle this many<br>
> circuit<br>
> creation<br>
> │ requests! Please consider using the MaxAdvertisedBandwidth<br>
> config<br>
> option or choosing<br>
> │ a more restricted exit policy. [404 similar message(s)<br>
> suppressed<br>
> in last 60 seconds]<br>
> │ 13:51:07 [WARN] Your computer is too slow to handle this many<br>
> circuit<br>
> creation<br>
> │ requests! Please consider using the MaxAdvertisedBandwidth<br>
> config<br>
> option or choosing<br>
> │ a more restricted exit policy. [75 similar message(s)<br>
> suppressed in<br>
> last 60 seconds]<br>
> │ 13:50:52 [WARN] Your computer is too slow to handle this many<br>
> circuit<br>
> creation<br>
> │ requests! Please consider using the MaxAdvertisedBandwidth<br>
> config<br>
> option or choosing<br>
> │ a more restricted exit policy. [601 similar message(s)<br>
> suppressed<br>
> in last 60 seconds]<br>
> │ 13:48:39 [WARN] Your computer is too slow to handle this many<br>
> circuit<br>
> creation<br>
> │ requests! Please consider using the MaxAdvertisedBandwidth<br>
> config<br>
> option or choosing<br>
> │ a more restricted exit policy. [99 similar message(s)<br>
> suppressed in<br>
> last 60 seconds]<br>
> │ 13:47:34 [WARN] Your computer is too slow to handle this many<br>
> circuit<br>
> creation<br>
> │ requests! Please consider using the MaxAdvertisedBandwidth<br>
> config<br>
> option or choosing<br>
> │ a more restricted exit policy. [22 similar message(s)<br>
> suppressed in<br>
> last 60 seconds]<br>
> │ 13:46:17 [WARN] Your computer is too slow to handle this many<br>
> circuit<br>
> creation<br>
> │ requests! Please consider using the MaxAdvertisedBandwidth<br>
> config<br>
> option or choosing<br>
> │ a more restricted exit policy. [253 similar message(s)<br>
> suppressed<br>
> in last 60 seconds]<br>
> │ 13:43:47 [WARN] Your computer is too slow to handle this many<br>
> circuit<br>
> creation<br>
> │ requests! Please consider using the MaxAdvertisedBandwidth<br>
> config<br>
> option or choosing<br>
> │ a more restricted exit policy. [1396 similar message(s)<br>
> suppressed<br>
> in last 60<br>
> │ seconds]<br>
> │ 13:42:48 [WARN] Your computer is too slow to handle this many<br>
> circuit<br>
> creation<br>
> │ requests! Please consider using the MaxAdvertisedBandwidth<br>
> config<br>
> option or choosing<br>
> │ a more restricted exit policy. [16 similar message(s)<br>
> suppressed in<br>
> last 60 seconds]<br>
><br>
> Here's how it crashed my router (blowing ip_conntrack limits is<br>
> sufficient only to mess up many of my TCP connections, but eventually<br>
> the router runs out of memory and starts killing processes):<br>
><br>
> May 4 13:51:24 dedmaus user.warn kernel: ip_conntrack: table full,<br>
> dropping packet.<br>
> May 4 13:51:24 dedmaus user.warn kernel: ip_conntrack: table full,<br>
> dropping packet.<br>
> May 4 13:51:24 dedmaus user.warn kernel: ip_conntrack: table full,<br>
> dropping packet.<br>
> May 4 13:51:25 dedmaus user.warn kernel: ip_conntrack: table full,<br>
> dropping packet.<br>
> May 4 13:51:29 dedmaus user.warn kernel: NET: 152 messages suppressed.<br>
> May 4 13:51:29 dedmaus user.warn kernel: ip_conntrack: table full,<br>
> dropping packet.<br>
> May 4 13:51:34 dedmaus user.warn kernel: NET: 193 messages suppressed.<br>
> May 4 13:51:34 dedmaus user.warn kernel: ip_conntrack: table full,<br>
> dropping packet.<br>
> May 4 13:51:39 dedmaus user.warn kernel: NET: 227 messages suppressed.<br>
><br>
> ...ad infinitum with the number of messages suppressed per 5 sec<br>
> increasing until the router crashes.<br>
><br>
><br>
><br>
> On Mon, Mar 18, 2013, at 06:18 PM, torsion at <a href="http://ftml.net" target="_blank">ftml.net</a> wrote:<br>
>> I'm also seeing occasional messages like this on the Pi (it never lasts<br>
>> long):<br>
>><br>
>> 18:13:24 [ARM_NOTICE] Relay resumed<br>
>> 18:13:18 [ARM_NOTICE] Relay unresponsive (last heartbeat: Mon Mar 18<br>
>> 18:13:04 2013)<br>
>> 17:28:43 [ARM_NOTICE] Relay resumed<br>
>> 17:28:38 [ARM_NOTICE] Relay unresponsive (last heartbeat: Mon Mar 18<br>
>> 17:28:25 2013)<br>
>> 14:12:26 [ARM_NOTICE] Relay resumed<br>
>> 14:12:20 [ARM_WARN] Deduplication took too long. Its current<br>
>> implementation has difficulty handling large logs so disabling it to<br>
>> keep the interface responsive.<br>
>> 14:12:20 [ARM_NOTICE] Relay unresponsive (last heartbeat: Mon Mar 18<br>
>> 14:12:06 20<br>
>><br>
>> On Mon, Mar 18, 2013, at 01:00 PM, torsion at <a href="http://ftml.net" target="_blank">ftml.net</a> wrote:<br>
>> > Hi there, I just joined the mailing list and apologized if this has<br>
>> been<br>
>> > discussed before. I did find discussion of a similar issue in January<br>
>> > 2013's archive:<br>
>> ><br>
>> > <a href="https://lists.torproject.org/pipermail/tor-relays/2013-January/001809.html" target="_blank">https://lists.torproject.org/pipermail/tor-relays/2013-January/001809.html</a><br>
>> ><br>
>> > It's important to note that I believe I've seen (but didn't save logs)<br>
>> a<br>
>> > couple "circuit creation burst" events on my established relay (about<br>
>> > 5Mbps, stable, guard, non-exit) which was mostly able to handle it<br>
>> > without crashing as it has plenty of RAM and the above-mentioned<br>
>> > messages - "Your computer is too slow to handle this many circuit<br>
>> > creation requests! Please consider using the MaxAdvertisedBandwidth<br>
>> > config option or choosing a m ore restricted exit policy." - appear<br>
>> only<br>
>> > with the relay is under load for other reasons AND a large number of<br>
>> > circuits are being suddenly created.<br>
>> ><br>
>> > I wondered if this was some kind of DOS attempt but didn't think much<br>
>> of<br>
>> > it because my fast relay continued working fine.<br>
>> ><br>
>> > However, I've just set up a Raspberry Pi, the 512MB model, as a relay<br>
>> on<br>
>> > a slower connection. Here are the relevant settings on this relay:<br>
>> ><br>
>> > RelayBandwidthRate 130 KB<br>
>> > RelayBandwidthBurst 340 KB<br>
>> ><br>
>> > The Pi has a fairly slow CPU, so I'd occasionally get messages about<br>
>> log<br>
>> > deduplication being too slow or something, but didn't think much of<br>
>> it.<br>
>> > I finally got the relay up and left it up for over 24 hours. When I<br>
>> > woke up this morning it had crashed. Here are the relevant log<br>
>> messages<br>
>> > - note the huge jump in number of circuits between 22:35 and 04:35<br>
>> > (maybe I got the Stable flag), then the storm of circuit open requests<br>
>> > starting at 05:49. Eventually I believe the Pi ran out of memory and<br>
>> > killed the tor process.<br>
>> ><br>
>> > What's very interesting here is that my fast VPS relay with a<br>
>> > RelayBandwidthRate over 5x faster is almost never handling much more<br>
>> > than 1000 circuits, so why all of a sudden the demand on the Pi that's<br>
>> > advertising a lower bandwidth rate?<br>
>> ><br>
>> > Mar 17 22:35:00.000 [notice] Heartbeat: Tor's uptime is 1 day 0:00<br>
>> > hours, with 26 circuits open. I've sent 974.13 MB and received 969.92<br>
>> > MB.<br>
>> > Mar 18 04:35:00.000 [notice] Heartbeat: Tor's uptime is 1 day 6:00<br>
>> > hours, with 972 circuits open. I've sent 1.61 GB and received 1.59 GB.<br>
>> > Mar 18 05:49:44.000 [warn] Your computer is too slow to handle this<br>
>> many<br>
>> > circuit creation requests! Please consider using the<br>
>> > MaxAdvertisedBandwidth config option or choosing a more restricted<br>
>> exit<br>
>> > policy.<br>
>> > Mar 18 05:49:44.000 [warn] Failed to hand off onionskin. Closing.<br>
>> > Mar 18 05:50:44.000 [warn] Your computer is too slow to handle this<br>
>> many<br>
>> > circuit creation requests! Please consider using the<br>
>> > MaxAdvertisedBandwidth config option or choosing a more restricted<br>
>> exit<br>
>> > policy. [5817 similar message(s) suppressed in last 60 seconds]<br>
>> > Mar 18 05:52:30.000 [warn] Your system clock just jumped 101 seconds<br>
>> > forward; assuming established circuits no longer work.<br>
>> > Mar 18 05:53:51.000 [warn] Your computer is too slow to handle this<br>
>> many<br>
>> > circuit creation requests! Please consider using the<br>
>> > MaxAdvertisedBandwidth config option or choosing a more restricted<br>
>> exit<br>
>> > policy. [1055 similar message(s) suppressed in last 60 seconds]<br>
>> > Mar 18 05:55:14.000 [warn] Your computer is too slow to handle this<br>
>> many<br>
>> > circuit creation requests! Please consider using the<br>
>> > MaxAdvertisedBandwidth config option or choosing a more restricted<br>
>> exit<br>
>> > policy. [329 similar message(s) suppressed in last 60 seconds]<br>
>> ><br>
>> > I'd like to figure out just how much the Raspberry Pi is capable of,<br>
>> > because it could be a cheap way to build out the relay network by<br>
>> people<br>
>> > who want to donate bandwidth - but of course it needs to be stable,<br>
>> and<br>
>> > something about my setup is not.<br>
>> ><br>
>> > Also:<br>
>> ><br>
>> > Mar 16 20:55:33.000 [notice] No AES engine found; using AES_*<br>
>> functions.<br>
>> ><br>
>> > I have no idea if the Broadcom BCM2835 SoC (ARM1176JZF-S CPU) in the<br>
>> Pi<br>
>> > has any AES capability, but it'd be great to find out.<br>
><br>
><br>
><br>
<br>
<br>
_______________________________________________<br>
tor-relays mailing list<br>
<a href="mailto:tor-relays@lists.torproject.org">tor-relays@lists.torproject.org</a><br>
<a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays</a><br>
</blockquote></div>