DavidAUK

I got the rclone gui working via the official docker container. Details here. I thought some people on this thread might find it useful.

I got it working and made a guide here.

I set VPN_INCOMING_PORT=XXXXX as an environment variable for the rtorrentvpn container and it worked! XXXXX is my listening port as set in the network.port_range.set = XXXXX-XXXXX setting in rtorrent.rc. Thank you so much for digging into that one. I have a feeling the same thing is happening with DelugeVPN.

Thanks @Cat_Seeder. Genuinely appreciate the help. Those lines are correct in my rtorrent.rc file. I just pulled a fresh rc file from the git repo and only changed the network.port_range.set line and it still didn't work. I don't use DHT so I think it's safe to rule that out. The clues, as I see them, are the fact that the port is open and listening for a few minutes when it starts but then stops listening as it finishes initialising. I can fix it by setting it manually in the container. Also, there are lines in the log that say: WARNING Not a valid number: '-' (invalid literal for int() with base 10: '-') INFO: Bad data packets written to '/tmp/xmlrpc2scgi-1000.xml' ERROR While calling network.bind_address.set('', '10.35.0.101'): <Fault -503: 'Invalid port_range argument.' Here's a pastebin of my rc. STRICT_PORT_FORWARD was set to yes, but setting to no hasn't fixed the problem. VPN_INCOMING_PORT isn't a environment variable for this container, is it?

Hey @Cat_Seeder, @binhex. Sorry to bug but if you have any pointers for the above then I'd love to hear it. I can fix it if I change those settings manually from within the Docker but I'd prefer it to work without an intervention. @nota seems to have the same problem.

Yes, I think you're right. The listening socket is not set when I use rtxmlrpc network.port_range to check it. It's listening as it starts, but then when rtorrent tries to connect to the web interface (if I'm understanding it right) it reconfigures and sets the listening port to null. [info] rTorrent listening interface IP 0.0.0.0 and VPN provider IP 10.35.0.101 different, marking for reconfigure Here's a log, which shows more. 2020-01-25 21:25:59,063 DEBG 'watchdog-script' stdout output: [info] rTorrent listening interface IP 0.0.0.0 and VPN provider IP 10.35.0.101 different, marking for reconfigure 2020-01-25 21:26:20,367 DEBG 'watchdog-script' stdout output: WARNING Not a valid number: '-' (invalid literal for int() with base 10: '-') 2020-01-25 21:26:20,369 DEBG 'watchdog-script' stdout output: - 2020-01-25 21:26:25,509 DEBG 'watchdog-script' stderr output: INFO: Bad data packets written to '/tmp/xmlrpc2scgi-1000.xml' 2020-01-25 21:26:25,510 DEBG 'watchdog-script' stdout output: ERROR While calling network.bind_address.set('', '10.35.0.101'): <Fault -503: 'Invalid port_range argument.' The relevant lines in my rtorrent.conf look like this. # SCGI Connectivity (for alternative rtorrent interfaces, XMLRPC) # # Use a IP socket with scgi_port, or a Unix socket with scgi_local. # schedule can be used to set permissions on the unix socket. # scgi_port = 0.0.0.0:5000 #scgi_local = /home/user/rtorrent/rpc.socket #schedule = scgi_permission,0,0,"execute.nothrow=chmod,\"g+w,o=\",/home/user/rtorrent/rpc.socket" Is that scgi_port setting incorrect? Thank you for your help! I feel like I'm getting closer.

This worked for me. Thank you. How do I avoid doing this manually though? For anyone who wants to try this for themselves, go to the shell in the container. To find out which ports are listening use netstat -plnt If the port is not listening then you can dynamically set the port as Cat_Seeder describes by issuing the following commands. rtxmlrpc network.port_range.set '' "XXXXX-XXXXX" rtxmlrpc dht.port.set '' "XXXXX" Where XXXXX is the rtorrent listening port. Then type the following command. rtxmlrpc network.bind_address.set '' "The VPN assigned IP" I found the VPN assigned IP in the following line of rtorrentvpn container log where I've marked XX.XX.X.XX Sat Jan 25 03:07:45 2020 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS zz.z.z.z,dhcp-option DNS zz.z.z.z,sndbuf 524288,rcvbuf 524288,route zz.zz.z.z,topology net30,ping 5,ping-restart 30,compress,ifconfig XX.XX.X.XX zz.zz.z.zz,peer-id 0' Then issue the following command. rtxmlrpc network.local_address.set '' "The External IP" I found the External IP in the following line of the rtorrentvpn. [info] Successfully retrieved external IP address XX.XXX.XXX.XXX After I'd sent those four commands the netstat -plnt showed the port as listening, as did the rutorrent web interface.

Thanks for the ideas. Do these lines go in rtorrent.conf or somewhere else?

No, that doesn't work. Shows as closed. Does it matter if I connect to the VPN in UDP or TCP protocol?

Yes. That seems to be set up correctly in rtorrent.tc and is shown in the GUI.

I'm having a problem with the listening port. It's correctly forwarded at the VPN provider and has worked in the past. The port I've set is 60210 and that's the port that the GUI says it's listening on. The status bar says it's closed. Here's the results of the netstat from the docker container. [root@50c27a10609f /]# netstat -lntu Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 127.0.0.11:44369 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:9080 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:7777 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:9443 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:5000 0.0.0.0:* LISTEN udp 0 0 127.0.0.11:54700 0.0.0.0:* [root@50c27a10609f /]# I would expect 60210 to show up there, so maybe it's related to that? Help appreciated.

Rutorrent keeps forgetting my password. In my YAML file I have - WEBUI_USER=jdoe - WEBUI_PASS=password123 And on first run that works, but after a while it defaults to admin/rutorrent. Does anyone have any idea why that would happen?

It could be something related to CloudFlare, which I understand iptorrents recently added. I don't know too much about how CloudFlare works but it sometimes initiates a DDOS prevention page before sending you to the actual page. It looks like this. I believe Jackett is set up to handle them but perhaps there's an issue with CloudFlare in combination with a proxy? Since CloudFlare DDOS page happens intermittently perhaps that's what's creating intermittent results. But I'm just guessing.

I am able to access those sites using a browser and the same proxy, so I don't think that's it. My hunch that it's an issue related to Jackett + proxy + CloudFlare.

I use a proxy with Jackett and have had problems adding trackers that are blocked by my ISP. Can you add any trackers?