<div dir="ltr"><span style="font-family:arial,sans-serif;font-size:13px">Hi torsion,</span><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">I'm also running a tor relay on a raspberry pi and keep getting these storm creation events which crash the box. You said you made some adjustments to the configs to get a more stable system? Can you please email me copies of the configs or maybe list the changes you made? </div>
<div style="font-family:arial,sans-serif;font-size:13px">I'm trying to get my pi stable and then perhaps role out a few more relay nodes to friends and colleagues.</div><div style="font-family:arial,sans-serif;font-size:13px">
Thanks,</div><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">T</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 4 May 2013 22:07,  <span dir="ltr"><<a href="mailto:torsion@ftml.net" target="_blank">torsion@ftml.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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  4 13:54:14 2013)<br>
 │ 13:52:25 [WARN] Your computer is too slow to handle this many circuit<br>
<div class="im"> creation<br>
 │   requests! Please consider using the MaxAdvertisedBandwidth config<br>
 option or choosing<br>
</div> │   a more restricted exit policy. [404 similar message(s) suppressed<br>
 in last 60 seconds]<br>
 │ 13:51:07 [WARN] Your computer is too slow to handle this many circuit<br>
<div class="im"> creation<br>
 │   requests! Please consider using the MaxAdvertisedBandwidth config<br>
 option or choosing<br>
</div> │   a more restricted exit policy. [75 similar message(s) suppressed in<br>
 last 60 seconds]<br>
 │ 13:50:52 [WARN] Your computer is too slow to handle this many circuit<br>
<div class="im"> creation<br>
 │   requests! Please consider using the MaxAdvertisedBandwidth config<br>
 option or choosing<br>
</div> │   a more restricted exit policy. [601 similar message(s) suppressed<br>
 in last 60 seconds]<br>
 │ 13:48:39 [WARN] Your computer is too slow to handle this many circuit<br>
<div class="im"> creation<br>
 │   requests! Please consider using the MaxAdvertisedBandwidth config<br>
 option or choosing<br>
</div> │   a more restricted exit policy. [99 similar message(s) suppressed in<br>
 last 60 seconds]<br>
 │ 13:47:34 [WARN] Your computer is too slow to handle this many circuit<br>
<div class="im"> creation<br>
 │   requests! Please consider using the MaxAdvertisedBandwidth config<br>
 option or choosing<br>
</div> │   a more restricted exit policy. [22 similar message(s) suppressed in<br>
 last 60 seconds]<br>
 │ 13:46:17 [WARN] Your computer is too slow to handle this many circuit<br>
<div class="im"> creation<br>
 │   requests! Please consider using the MaxAdvertisedBandwidth config<br>
 option or choosing<br>
</div> │   a more restricted exit policy. [253 similar message(s) suppressed<br>
 in last 60 seconds]<br>
 │ 13:43:47 [WARN] Your computer is too slow to handle this many circuit<br>
<div class="im"> creation<br>
 │   requests! Please consider using the MaxAdvertisedBandwidth config<br>
 option or choosing<br>
</div> │   a more restricted exit policy. [1396 similar message(s) suppressed<br>
 in last 60<br>
 │   seconds]<br>
 │ 13:42:48 [WARN] Your computer is too slow to handle this many circuit<br>
<div class="im"> creation<br>
 │   requests! Please consider using the MaxAdvertisedBandwidth config<br>
 option or choosing<br>
</div> │   a more restricted exit policy. [16 similar message(s) 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>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On Mon, Mar 18, 2013, at 06:18 PM, <a href="mailto:torsion@ftml.net">torsion@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, <a href="mailto:torsion@ftml.net">torsion@ftml.net</a> wrote:<br>
> > Hi there, I just joined the mailing list and apologized if this has 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) 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 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 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 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 log<br>
> > deduplication being too slow or something, but didn't think much of 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 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 many<br>
> > circuit creation requests! Please consider using the<br>
> > MaxAdvertisedBandwidth config option or choosing a more restricted 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 many<br>
> > circuit creation requests! Please consider using the<br>
> > MaxAdvertisedBandwidth config option or choosing a more restricted 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 many<br>
> > circuit creation requests! Please consider using the<br>
> > MaxAdvertisedBandwidth config option or choosing a more restricted 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 many<br>
> > circuit creation requests! Please consider using the<br>
> > MaxAdvertisedBandwidth config option or choosing a more restricted 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 people<br>
> > who want to donate bandwidth - but of course it needs to be stable, 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_* functions.<br>
> ><br>
> > I have no idea if the Broadcom BCM2835 SoC (ARM1176JZF-S CPU) in the Pi<br>
> > has any AES capability, but it'd be great to find out.<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>
_______________________________________________<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>
</div></div></blockquote></div><br></div>