I
iDenny
Guest
Kära vänner! Goddag!
I've faced a strange problem with my Transmission which no longer can use peer listening port. For some reason, Transmission can no longer use any port for peer listening. I've been able to use it before, without any deeper configuration (everything seemed to work out-of-the-box). Transmission seemed to work flawlessly with VAN-tunneling (I use PIA for my Transmission jail) which I've used for a while. Transmission have no problems with private trackers either (TD, IPT), but fails with public trackers (1337x, TPB, LIMETOR). I've also been digging into this problem for a couple of days now and can't really find where the problem is. However, I was able to find a couple of interesting things, see below.
Transmission daemon reports following errors:
When scanning jail from my PC, Nmap sees those ports:
This
Contents of
If I get it right, this script is responsible for scheduling inside Transmission. However, some users say that this version have been infected with malware.
Digging even further I found that my home gateway (dd-wrt) have a couple of UPnP entries which match with peer listening ports (looks like Transmission tried to map those ports).
I've also read a couple of threads (thread1, thread2, thread3) where people discuss the same problem. I've also used scripts provided in those threads, without any success. In my case, those scripts gets stuck at
Update 1: After reading this thread I'm considering to destroy this jail and reisntall Transmission.
I've faced a strange problem with my Transmission which no longer can use peer listening port. For some reason, Transmission can no longer use any port for peer listening. I've been able to use it before, without any deeper configuration (everything seemed to work out-of-the-box). Transmission seemed to work flawlessly with VAN-tunneling (I use PIA for my Transmission jail) which I've used for a while. Transmission have no problems with private trackers either (TD, IPT), but fails with public trackers (1337x, TPB, LIMETOR). I've also been digging into this problem for a couple of days now and can't really find where the problem is. However, I was able to find a couple of interesting things, see below.
Transmission daemon reports following errors:
root@transmission:/ # transmission-daemon -f
[2018-01-31 14:53:57.280] UDP Failed to set receive buffer: No buffer space available (tr-udp.c:65)
[2018-01-31 14:53:57.280] UDP Failed to set receive buffer: requested 4194304, got 42080 (tr-udp.c:84)
[2018-01-31 14:55:50.279] RPC Server Unable to bind to 0.0.0.0:9091 after 10 attempts, giving up (rpc-server.c:773)
When scanning jail from my PC, Nmap sees those ports:
9091/tcp open xmltec-xmlmail #WebGUI
12346/tcp open netbus #Something interesting here
64935/tcp open unknown #Peer listening port, changed on startup
This
12346/tcp open netbus
seemed to be suspicious, so I digged further: sockstat -lP tcp
USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
transmission transmissi 49824 11 tcp4 *:9091 *:*
transmission transmissi 49824 12 tcp4 *:64935 *:*
transmission transmissi 49824 13 tcp6 *:64935 *:*
root python2.7 49718 3 tcp4 192.168.0.2:12346 *:*
procstat -c 49718
PID COMM ARGS
49718 python2.7 /usr/pbi/transmission-amd64/bin/python2.7 /usr/pbi/transmission-amd64/control.py start 192.168.0.2 12346
Contents of
/usr/pbi/transmission-amd64/control.py
import os
import sys
import signal
import daemon
from flup.server.fcgi import WSGIServer
HERE = os.path.abspath(os.path.dirname(__file__))
sys.path.insert(0, os.path.join(HERE, "lib/python2.7/site-packages"))
transmission_fcgi_pidfile = "/var/run/transmission_fcgi_server.pid"
def transmission_fcgi_start(args):
if len(args) < 2:
return False
ip = args[0]
port = long(args[1])
os.environ['DJANGO_SETTINGS_MODULE'] = 'transmissionUI.settings'
import django.core.handlers.wsgi
app = django.core.handlers.wsgi.WSGIHandler()
res = False
with open(transmission_fcgi_pidfile, "wb") as fp:
fp.write(str(os.getpid()))
fp.close()
res = WSGIServer(app, bindAddress=(ip, port)).run()
return res
def transmission_fcgi_stop(args):
res = False
if os.access(transmission_fcgi_pidfile, os.F_OK):
with open(transmission_fcgi_pidfile, "r") as fp:
pid = long(fp.read())
fp.close()
os.kill(pid, signal.SIGHUP)
res = True
if os.access(transmission_fcgi_pidfile, os.F_OK):
os.unlink(transmission_fcgi_pidfile)
return res
def transmission_fcgi_status(args):
res = False
if os.access(transmission_fcgi_pidfile, os.F_OK):
with open(transmission_fcgi_pidfile, "r") as fp:
pid = long(fp.read())
fp.close()
res = True
return res
def transmission_fcgi_configure(args):
return True
def main(argc, argv):
if argc < 2:
sys.exit(1)
commands = {
'start': transmission_fcgi_start,
'stop': transmission_fcgi_stop,
'status': transmission_fcgi_status,
'configure': transmission_fcgi_configure
}
with daemon.DaemonContext():
if not commands.has_key(argv[0]):
sys.exit(1)
if not commands[argv[0]](argv[1:]):
sys.exit(1)
sys.exit(0)
if __name__ == '__main__':
main(len(sys.argv), sys.argv[1:])
If I get it right, this script is responsible for scheduling inside Transmission. However, some users say that this version have been infected with malware.
Digging even further I found that my home gateway (dd-wrt) have a couple of UPnP entries which match with peer listening ports (looks like Transmission tried to map those ports).
Description Enabled From (WAN) To (LAN) IP Address Proto
Transmission at 52230 Yes 64935 64935 192.168.0.2 TCP
Transmission at 52230 Yes 64935 64935 192.168.0.2 UDP
...
I've also read a couple of threads (thread1, thread2, thread3) where people discuss the same problem. I've also used scripts provided in those threads, without any success. In my case, those scripts gets stuck at
curl
fetch resulting in endless fetching from PIA servers. Using commands in those scripts manually (generating cliend_id & fetching port number from PIA) results in "Your connection already has port forwarding enabled". Port number is simply not fetched.Update 1: After reading this thread I'm considering to destroy this jail and reisntall Transmission.
Last edited by a moderator: