Register for the iXsystems Community to get an ad-free experience and exclusive discounts in our eBay Store.

Transmission VPN peer listening port problems

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:

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:

Alecmascot

FreeNAS Experienced
Joined
Mar 18, 2014
Messages
234
I think you need to go to the pia forums
 
I

iDenny

Guest
I think you need to go to the pia forums
I'm not being rude, but what has PIA to do with broken/infected Transmission plugin? This post was created mainly for FreeNAS devs and users who faced same/related problem and those who want to spare some time reading and understanding the problem.
 
I

iDenny

Guest
Update 2: Installing qBittorrent solved problem with peer listening & port forwarding. With other words, problem is not at PIA end.
 
Last edited by a moderator:

JoshDW19

Community Moderator
Administrator
Moderator
iXsystems
Joined
May 16, 2016
Messages
451
Once again, I don't understand this negativity. I mean like, you don't know how to solve problem, don't want to discuss it. Then browse on? Who forces you to come here and and leave your useless comments here?



There are no snotty posts here? I'm trying to discuss the problem with infected plugin? What is snotty about it?
I didn't think your posts were snotty at all. I suppose bolding your comment may have triggered someone but I just don't think your intention was to be rude in the least. The offending post has been removed. If you don't have something helpful to say to the op then don't say it. Thank you!
 
I

iDenny

Guest
I didn't think your posts were snotty at all. I suppose bolding your comment may have triggered someone but I just don't think your intention was to be rude in the least. The offending post has been removed. If you don't have something helpful to say to the op then don't say it. Thank you!
Thank you Josh.
 
Top