[Tor-BSD] Recognizing Randomness Exhaustion

[Richard Johnson]

On 2014-12-31 11:21, Libertas wrote:
> For those not familiar, a Tor relay will eventually have an open TCP
> connection for each of the other >6,000 active relays, and (if it allows
> exit traffic) must make outside TCP connections for the user's requests,
> so it's pretty file-hungry and crypto-intensive.

It can also be pf-state-hungry. Further, each upstream peer Tor node, and each 
client on a Tor entry node, will probably be a pf src.

Packets being dropped and circuits failing when the pf default limits topped 
out would naturally present to the tor bandwidth authorities as network 
congestion.

In my case, I'm now fairly certain my relays usage grew to the point where 
they were allocation-bound in pf. The host was still using the pf defaults 
until recently.

Since increasing the pf limits, I'm seeing better throughput. The "current 
entries" from pfctl -si currently reach 35k instead of hitting the default 
limit of 10k. Also, state inserts and removals are up to 50/s from 29/s, and 
matches are topping 56/s instead of 30/s. As well, the pfctl -si "memory could 
not be allocated" counter remains a reassuring 0 instead of increasing at 
0.9/s. Additionally, netstat -m counters for pf* have a reassuring 0 in the 
failure column of the memory resource pool stats. Finally, Tor network traffic 
seems to have started climbing.

I increased the limits thusly, since the host does nothing but Tor and unbound 
for Tor DNS.

| # don't choke on lots of circuits (default is states 10000,
| # src-nodes 10000, frags 1536)
| set limit { states 100000, src-nodes 100000, frags 8000, \

> One possible explanation is that its randomness store gets exhausted. I
> once saw errors like this in my Tor logs, but I don't know how to test
> if it's a chronic problem. I also couldn't find anything online. Is
> there any easy way to test if this is the bottleneck?

I suspect Tor won't exhaust randomness; random(4) shouldn't block. (From a 
cursory look at the source, Tor references /dev/urandom, and doesn't use 
arc4random.)


Richard