[Support] binhex - rTorrentVPN


Recommended Posts

3 hours ago, td00 said:

My assumption is that the VPN times out due to inactivity (in my case PIA) and the the container then fires a script to try and reconnect again but can't due to this error: "rtorrent: Error in option file: ~/.rtorrent.rc:134: Could not prepare socket for listening: Address already in use"

can you attach /config/rtorrent/config/rtorrent.rc here please.

Link to comment
23 minutes ago, td00 said:

Yes sir it's right here: https://paste.ee/p/URgBB

Thanks much for the help!

ok i dont see anything wrong there, so i can only assume the code i have in place to wait for the process to not exist is too efficient and i need further checks to make sure the port is also closed before starting rtorrent again, i will take a look at the code and let you know once a fix is in place.

Link to comment
4 hours ago, binhex said:

ok i dont see anything wrong there, so i can only assume the code i have in place to wait for the process to not exist is too efficient and i need further checks to make sure the port is also closed before starting rtorrent again, i will take a look at the code and let you know once a fix is in place.

Thanks binhex! Glad to know its not me :) Keep up the great work!

Link to comment
15 hours ago, binhex said:

inactivity timeout is a fact of life and isnt an issue by itself, this just indicates that openvpn has detected a ping timeout with the remote ip address, thus the tunnel is down, this can be caused by your isp and/or your vpn provider and can happen at any time and is completely normal. what isnt normal is having repeated timeouts which can indicate either an inability to create the vpn tunnel or an issue with your isp connection stability or vpn provider stability.

Understood. What is the timeout value? Can it be configured? and if not, can that be an enhancement?

Link to comment
5 hours ago, noski said:

Understood. What is the timeout value? Can it be configured? and if not, can that be an enhancement?

the default inactivity timeout is 0, which means do not timeout on inactivity, i believe what you are seeing is part of the --keepalive option, which can be tuned but really shouldnt need to be (works for everybody else), its currently set to ping every 10 secs, and if no response within 60 seconds then restart.

 

one thing i have noticed is that you are using a non standard port, and also using TCP, any particular reason for this?, it could be leading to the disconnections, taken from your log:-

remote ca-toronto.privateinternetaccess.com 1197

try changing the /config/openvpn/*.ovpn file 'remote' line to:-

 

remote ca-toronto.privateinternetaccess.com 1198 udp

save and then restart the container, see how you get on with that.

Link to comment
23 hours ago, binhex said:

the default inactivity timeout is 0, which means do not timeout on inactivity, i believe what you are seeing is part of the --keepalive option, which can be tuned but really shouldnt need to be (works for everybody else), its currently set to ping every 10 secs, and if no response within 60 seconds then restart.

 

one thing i have noticed is that you are using a non standard port, and also using TCP, any particular reason for this?, it could be leading to the disconnections, taken from your log:-


remote ca-toronto.privateinternetaccess.com 1197

try changing the /config/openvpn/*.ovpn file 'remote' line to:-

 


remote ca-toronto.privateinternetaccess.com 1198 udp

save and then restart the container, see how you get on with that.

Hey binhex,

 

OK I've pulled down your latest. However, this second tip here I went and looked in and found that the settings in my *.ovpn file seem to be indicating that it is in fact connecting with port 1198/udp: https://imgur.com/ge8Edhv

 

I will keep an eye on it though and report back if I find anything. Thanks again for all the help!

Link to comment

 

On 5/11/2019 at 10:18 PM, markomax said:

Privoxy has stopped working for me after pulling the latest version of this. I usually use Privoxy with Sonarr/Radarr/Lidarr/Jackett but they no longer work when I use hostname: localhost and port: 8118. I noticed that there were some new settings for RPC2 and RPC2_AUTH.  Is there some sort of username and password required for Privoxy too now?

 

On 5/12/2019 at 6:10 AM, binhex said:

Delete /config/privoxy/ folder and restart container

Sent from my EML-L29 using Tapatalk
 

When I delete the /config/privoxy folder, it does not re-create a new Privoxy folder when I relaunch rtorrent. I have Privoxy enabled in my run command. This is the only line related to privoxy in the log file when I launch: "[info] Privoxy not running".

 

If I move/delete all of my config folders except for openvpn and run it again, it will connect to privoxy only that one time. Once I move my (rather large) session folder and the rtorrent.rc file back over, Privoxy no longer works. Any ideas?

Privoxy will not start any other time.rtf Privoxy launched successfully.rtf

Link to comment
On 9/17/2019 at 2:22 AM, binhex said:

the default inactivity timeout is 0, which means do not timeout on inactivity, i believe what you are seeing is part of the --keepalive option, which can be tuned but really shouldnt need to be (works for everybody else), its currently set to ping every 10 secs, and if no response within 60 seconds then restart.

Thanks for that. I will play with the VPN_OPTIONS.

 

Quote

one thing i have noticed is that you are using a non standard port, and also using TCP, any particular reason for this?

I was using the 'STRONG' PIA config files which use port 1197 (https://www.privateinternetaccess.com/helpdesk/kb/articles/where-can-i-find-your-ovpn-files). I used the files directly from PIA without modification. I will try different ones to see if it helps.

Link to comment

Hey binhex,

 

So everything is running now but it seems now I'm getting Tracker: [Failed binding local connection end] on all my torrents after it refreshes the connection to VPN? I've pasted the log file here at the time it reconnected: https://paste.ee/p/yB9Yr

 

I was searching around Google to see if I could figure it out myself but to no avail lol. The only thing I found that came close had to do with Transmission and how it used (or didn't use) IPv6 bindings in its curl scripts. Doubt it will help but just in case: https://github.com/transmission/transmission/issues/88

 

 

Link to comment

Hey binhex,

 

One more question. It appears that your image comes coupled with rtcontrol which is great. I'm trying to run the following,

rtcontrol is_complete=yes is_open=yes seedtime=+3d

and it should return like 2000 results but I instead get:

 

INFO     Dumped 0 out of 2001 torrents.
INFO     Total time: 0.073 seconds.

 

Just wondering if you're using some special version or something or if I'm getting this code wrong?

 

Link to comment
On 9/18/2019 at 3:08 PM, td00 said:

So everything is running now but it seems now I'm getting Tracker: [Failed binding local connection end] on all my torrents after it refreshes the connection to VPN?

so this should be automatically sorted for you, there is a delay of up to 30 seconds and a restart of rtorrent is required to re-configure, but this should be then re-defining the bind ip  for rtorrent to the newly allocated vpn ip, in my experience this works for me, can you attach your supervisord.log file, see here for instructions:-

https://github.com/binhex/documentation/blob/master/docker/faq/help.md

 

Link to comment
15 hours ago, binhex said:

so this should be automatically sorted for you, there is a delay of up to 30 seconds and a restart of rtorrent is required to re-configure, but this should be then re-defining the bind ip  for rtorrent to the newly allocated vpn ip, in my experience this works for me, can you attach your supervisord.log file, see here for instructions:-

https://github.com/binhex/documentation/blob/master/docker/faq/help.md

 

Hey binhex,

 

Ok I followed the directions and have my supervisord.log file for your review here: https://paste.ee/p/hegZp

The only issue is that in following those directions, I had to restart the container in order to turn on the DEBUG mode per your request. Normally not a big deal however, restarting the container always fixes the Tracker: [Failed binding local connection end] error so I'm afraid you're most likely going to see a normal looking supervisord.log file. This seems to happen sporadically (usually after several hours of being up but typically within the 24-48hr range) where I'll check the web ui and notice all my torrents in red with this message for each of them. It isn't until I restart the container that it comes back working perfectly fine.

Link to comment
Hey binhex,
 
Ok I followed the directions and have my supervisord.log file for your review here: https://paste.ee/p/hegZp
The only issue is that in following those directions, I had to restart the container in order to turn on the DEBUG mode per your request. Normally not a big deal however, restarting the container always fixes the Tracker: [Failed binding local connection end] error so I'm afraid you're most likely going to see a normal looking supervisord.log file. This seems to happen sporadically (usually after several hours of being up but typically within the 24-48hr range) where I'll check the web ui and notice all my torrents in red with this message for each of them. It isn't until I restart the container that it comes back working perfectly fine.
Ok I understand, well now debug is on we can wait for it to happen again, when it does please attach the current supervisord.log, hopefully they will tell me what's going on.

Sent from my CLT-L09 using Tapatalk

Link to comment

Hey binhex,

 

Ok, it's been a few days and unfortunately I've been away for a few days so I cannot tell you exactly what day it might have happened - but it did happen again ( Tracker: [Failed binding local connection end] error) and I've captured the logs starting from the day after the previous log post here: https://paste.ee/p/hpBU4

 

Here's hoping you can see what's up in these logs... keep up the great work and let me know if you need anything else from me.

Link to comment
On 9/18/2019 at 12:01 AM, markomax said:

 

 

When I delete the /config/privoxy folder, it does not re-create a new Privoxy folder when I relaunch rtorrent. I have Privoxy enabled in my run command. This is the only line related to privoxy in the log file when I launch: "[info] Privoxy not running".

 

If I move/delete all of my config folders except for openvpn and run it again, it will connect to privoxy only that one time. Once I move my (rather large) session folder and the rtorrent.rc file back over, Privoxy no longer works. Any ideas?

Privoxy will not start any other time.rtf 17.36 kB · 2 downloads Privoxy launched successfully.rtf 20.31 kB · 1 download

I still cannot get Privoxy working. Any ideas?

Link to comment
On 9/30/2019 at 5:28 AM, binhex said:

are you sure your lan network is configured correctly?, from your log it is currently set to:-


LAN_NETWORK defined as '192.168.1.0/24'

if you arent sure how to set it then see Q4 from the following link:-

https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

Yes my LAN matches exactly with what is shown in the example. Privoxy will load up and connect if I launch the container with an empty session folder under /config/rtorrent/session, but as soon as I move all of the .rtorrent files etc back to the session folder and relaunch, it doesn't work. There are close to 4000 torrents total.. maybe that is just too many?

Link to comment
15 hours ago, markomax said:

Yes my LAN matches exactly with what is shown in the example. Privoxy will load up and connect if I launch the container with an empty session folder under /config/rtorrent/session, but as soon as I move all of the .rtorrent files etc back to the session folder and relaunch, it doesn't work. There are close to 4000 torrents total.. maybe that is just too many?

due to the fact you are not seeing the /config/privoxy folder being re-created it could be permissions, can you check that the following uid and gid have sufficient permissions to wherever you have defined /config on the host, taken from your log:-

 

2019-09-17 23:35:27.568036 [info] PUID defined as '1026'
2019-09-17 23:35:27.636838 [info] PGID defined as '101'

i have just done some basic tests here and found no issue whatsoever with privoxy when running using this image, i have deleted the config files and they get re-created, i have stopped and started the container multiple times and each time privoxy comes up ok, if i delete the /config/privoxy folder it gets re-created, so its got to be a bad config somewhere.

 

one other thing to note is that your umask is set to 002, now this SHOULD be ok, but you could try setting it to 000 to see if this makes a difference (if its not a uid/gid issue)

Link to comment
  • 2 weeks later...
On 10/3/2019 at 12:54 PM, binhex said:

due to the fact you are not seeing the /config/privoxy folder being re-created it could be permissions, can you check that the following uid and gid have sufficient permissions to wherever you have defined /config on the host, taken from your log:-

 


2019-09-17 23:35:27.568036 [info] PUID defined as '1026'
2019-09-17 23:35:27.636838 [info] PGID defined as '101'

i have just done some basic tests here and found no issue whatsoever with privoxy when running using this image, i have deleted the config files and they get re-created, i have stopped and started the container multiple times and each time privoxy comes up ok, if i delete the /config/privoxy folder it gets re-created, so its got to be a bad config somewhere.

 

one other thing to note is that your umask is set to 002, now this SHOULD be ok, but you could try setting it to 000 to see if this makes a difference (if its not a uid/gid issue)

I had Privoxy working for about a week by launching fresh without any files in the session folder, then loading (and rechecking) all of the torrents from a watched directory.  For some reason, the Privoxy folder is only created the first time I launch with no other files in the config folder except those created by running the image. As soon as I restarted it, I see no other message in the log except for "[info] Privoxy not running" exactly like the second log I uploaded.

 

I agree it is likely a permissions thing that I don't understand how to fix. The permissions seem correct when I look at users, groups and the shared folder on my Synology DSM. If I am to troubleshoot this by trying a run command with a different umask, user, or group, do I need to delete the "perms.txt" file in the config folder before running everything again?

Link to comment
  • binhex locked this topic
Guest
This topic is now closed to further replies.