2

I've tried running both transmission and deluge on my raspberry pi. Both times fresh install.

I can get it up and running fine, but then after about 1-2 minutes the web server stops responding and I can't access it unless i restart. I know it's not the whole pi crashing as I can still access pyLoad which is also running along with OpenVPN.

I first thought it was the problem of the applications. But now both are having the same problems I feel it is definitely not the application and rather the OS/hardware.

Has anyone had similar and found a fix?


UPDATE I ran netstat -ano|grep 9091 and got:

Proto Recv-Q  Send-Q  Local Address        Foreign Address                 State

tcp      0      0    0.0.0.0:9091         0.0.0.0:*            LISTEN off (0.00/0/0)
tcp      0      0    192.168.0.11:9091    192.168.0.80:52774   ESTABLISHED keepalive (6879.20/0/0)
tcp      0      0    192.168.0.11:9091    192.168.0.80:52794   ESTABLISHED keepalive (6879.20/0/0)
tcp      0      0    192.168.0.11:9091    192.168.0.80:52776   ESTABLISHED keepalive (6879.20/0/0)
tcp     1123    0    192.168.0.11:9091    192.168.0.80:52888   ESTABLISHED keepalive (6940.61/0/0)
tcp     707     0    192.168.0.11:9091    192.168.0.80:52789   ESTABLISHED keepalive (6879.17/0/0)
tcp      0      0    192.168.0.11:9091    192.168.0.80:52790   ESTABLISHED keepalive (6879.17/0/0)
tcp      0      0    192.168.0.11:9091    192.168.0.80:53184   ESTABLISHED keepalive (7104.42/0/0)
tcp      0      0    192.168.0.11:9091    192.168.0.80:52775   ESTABLISHED keepalive (6879.14/0/0)
tcp      0      0    192.168.0.11:9091    192.168.0.80:53193   ESTABLISHED keepalive (7124.90/0/0)
tcp      0      0    192.168.0.11:9091    192.168.0.80:52784   ESTABLISHED keepalive (6879.14/0/0)
tcp      0      0    192.168.0.11:9091    192.168.0.80:52791   ESTABLISHED keepalive (6879.14/0/0)
tcp      0      0    192.168.0.11:9091    192.168.0.80:52783   ESTABLISHED keepalive (6879.12/0/0)
tcp      0      0    192.168.0.11:9091    192.168.0.80:52785   ESTABLISHED keepalive (6879.12/0/0)

UPDATE 2 Right I think I've found the issue. It is to do with the openvpn. Once connected for some reason the port is open for a few minutes to LAN traffic before being closed. This however doesn't seem to be the case for pyload which is also running (port 8000)

I think what I need to do is ensure that all outbound traffic (to the WAN) is going over vpn (i.e. tun) but all LAN traffic is not routed through the vpn. To be honest I'm not sure how to do this. I've done a bit of research and came across these iptable rules (Linky), however I'm not sure if they're working and I still can't access port 9091.

iptables --append OUTPUT --destination 10.10.0.102 --protocol tcp --dport 1723 --jump ACCEPT
iptables --append OUTPUT --destination 10.10.0.102 --protocol gre --jump ACCEPT

My understanding of this is this forces all of the WAN traffic over my tun connection and allows port 1723 for the vpn tracker. However, I might be wrong in this. Can anyone help?

  • 1
    Does the server have a log that might provide some clues? Is the process still running and just unresponsive, or has it disappeared? If you understand a little about packets and protocols, you might try looking at what's happening with a tool like wireshark. You don't need to use the pi for that, just another system on the same LAN; if the LAN is busy you'll have to do some filtering...so a bit of learning curve but getting comfortable with a packet sniffer can come in useful for a lot of things. – goldilocks Dec 3 '14 at 22:24
  • Thanks! It might do, but I'm not sure how to access it. I've downloaded wireshark, and there is a lot of stuff flying past! Any clues as to what I'm looking for? – Tom Dec 3 '14 at 23:28
  • Here's a possible entry to the wireshark docs. I'm not a torrent user so I don't know the port number used by the server, but if you use tcp.port eq ___ or udp.port eq ___ as the filter, where ___ is the port number, you'll limit the output to stuff coming to or from the server. If you do that, start it, and watch until it fails, there might be a clue. – goldilocks Dec 4 '14 at 0:03
  • It came back blank. I also tried using a filter on the source and destination of the servers ip and it came back with only MDNS entries and no TCP (not sure what that means exactly) – Tom Dec 4 '14 at 0:10
  • If it's blank while you are able to witness the server definitively responding from another point, then you've done something wrong -- the packets are there. I was thinking in regards to the 1-2 minutes you mention before it stops. You should be able to witness that happen. E.g., if the application has failed, the OS will respond with an ICMP message (so whoops, that filter should have been something more like icmp or tcp.port eq 9091), unless you've customized an iptables set up otherwise... – goldilocks Dec 4 '14 at 2:32
1

The USB driver allocates memory from the kernel, and when traffic is very high (e.g. when using torrents/newsgroup downloads) this memory can be exhausted causing crashes/hangs.

in /etc/sysctl.conf where it says "vm.min_free_kbytes = 8192" Try increasing that number to 16384.

If that doesn't work, try adding to /boot/cmdline.txt "smsc95xx.turbo_mode=N"

The latter worked for me and i stopped having trouble in transmission.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.