1 hour ago, binhex said:

it doesn't matter whatsoever, if you have confirmed the port is open using an external website then thats all the confirmation you should need.

 

having said that i have no issues at all with the built in indicator in rutorrent and it is always green, unless PIA has a wobble, in which case it may go red temporarily before my script kicks it and corrects the issue (restarts openvpn).

it tests the incoming port as defined in rutorrent, it uses an external website (https://portchecker.co) to do the check (web scrape) and if the port is open then it is green, if not then its red, and if it cannot contact the website then it is orange, i use the same website to do my own internal check, and it always reports the correct status to me.

 

Thank you for the explanation. As explained I don't use PIA but another VPN provider so i'm using custom preset. The ovpn file work like a charm, eveyrthing seems ok. Still have the red mark at the bottom, like you told I have confirmation from curl within the docker container the port is open. I have test the op against your website using VPN shared ip i'm assigned to and the port is Open. 

Rtorrent is still red. But I shouldn't care, it's just mental. 
Thank you again for your image, best. 

Hi there.

Sorry if I have missed something really obvious, but I'm trying to use Pyrocore to manage rtorrent so that it only downloads 1 torrent at a time. I followed the config guide to change the torque.ini file, but it isn't having any impact on rtorrent. Is there anything that I need to change in rtorrent.rc or anywhere else so that it is active?

 

Thanks

Is there any recent change regarding auto opening ports with PIA VPN? 

Since I started using PIA the incoming port used on rTorrent was automatically changed after a while on rTorrent to match the port forwarded provided by PIA api.

Since a few days ago I've seen that the red mark is present on all torrent clients and I don't seem to get lots of connections, so it seems that the ports are not being set indeed.

 

Just to clarify: The port used in ruTorrent does not seem to be updated with the forwarded port reported by the rtorrent log when retrieving it from PIA API.

Log trailing with:

 

Quote

2020-08-24 21:50:08,194 DEBG 'watchdog-script' stdout output:
[info] rtorrent incoming port closed, marking for reconfigure
2020-08-24 22:20:21,572 DEBG 'watchdog-script' stdout output:
0
2020-08-24 22:20:25,412 DEBG 'watchdog-script' stdout output:
[info] rtorrent incoming port closed, marking for reconfigure
2020-08-24 22:50:33,843 DEBG 'watchdog-script' stdout output:
0
2020-08-24 22:50:36,721 DEBG 'watchdog-script' stdout output:
[info] rtorrent incoming port closed, marking for reconfigure

 

Edited August 24, 20205 yr by Jeffarese

On 8/2/2020 at 10:56 AM, binhex said:

Change endpoint then, PIA is currently going through a transition to their next-generation network, outages are being experienced.

Sent from my CLT-L09 using Tapatalk
 

Is there any way to get the nextgen port working like with this? https://github.com/thrnz/docker-wireguard-pia/blob/master/extra/pf.sh or just sit tight until we get someting official from PIA.

I can no longer get this docker to run. Getting the following error

 

Wed Aug 26 21:36:02 2020 ERROR: Cannot ioctl TUNSETIFF tun: Operation not permitted (errno=1)

Wed Aug 26 21:36:02 2020 Exiting due to fatal error

 

3 hours ago, jrdnlc said:

I can no longer get this docker to run. Getting the following error

 

Wed Aug 26 21:36:02 2020 ERROR: Cannot ioctl TUNSETIFF tun: Operation not permitted (errno=1)

Wed Aug 26 21:36:02 2020 Exiting due to fatal error

 

tun operation not permitted is normally due to not including the following in 'extra paramers' in the edit screen for the docker container:-

--cap-add=NET_ADMIN

or you do not have 'privileged' set to on.

I seem to be having issues with port forwarding on PIA? Are you able to help @binhex? Log attached.

supervisord.log

@binhex It looks like this is happening again https://github.com/binhex/arch-rtorrentvpn/issues/104

 

2020-08-29 17:10:49,842 DEBG 'start-script' stdout output:
[warn] Cannot determine external IP address, performing tests before setting to '127.0.0.1'...
[info] Show name servers defined for container

 

IP in the rutorrent settings/bittorent shows 127.0.0.1. I am using Airvpn as my vpn provider and the latest docker container available to unraid.

 

You helped fix it before, hopefully an easy fix again.

 

Edited August 31, 20205 yr by lzrdking71

I hate that I can't get this working myself. I've combed the FAQ and can't find anything in this thread that seems to match what's going on.

 

I've had this docker working before, but am only now trying to swap over completely from qbittorrent. I pulled it again and can't seem to get the webui to load.

Tried deleting all the old config and starting again with no luck. Can't seem to see any significant errors in the supervisord log.

 

When I try to go into the web ui it times out persistently. Any thoughts?

 

 

supervisord.log

Edited August 31, 20205 yr by tuna83

On 8/29/2020 at 11:24 PM, lzrdking71 said:

@binhex It looks like this is happening again https://github.com/binhex/arch-rtorrentvpn/issues/104

 

2020-08-29 17:10:49,842 DEBG 'start-script' stdout output:
[warn] Cannot determine external IP address, performing tests before setting to '127.0.0.1'...
[info] Show name servers defined for container

 

IP in the rutorrent settings/bittorent shows 127.0.0.1

You helped fix it before, hopefully an easy fix again.

 

I started seeing this with the most recent version as well.  I'm using AirVPN.  Rolling back to version v3.10-01 fixed the issue.  Looking at Github, the only difference between the two versions is Commit ad060d.  I don't see how change would have any impact, but every time I downgrade the issue goes away. 

 

EDIT: Ahh, I didn't see the comments on the commit. Binhex confirmed the change is not related to this.

Edited August 31, 20205 yr by BiGBaLLA

On 8/29/2020 at 4:18 PM, cheesemarathon said:

I seem to be having issues with port forwarding on PIA? Are you able to help @binhex? Log attached.

supervisord.log 40.37 kB · 2 downloads

switch from france, looks like port forwarding is currently broken there, try ca-montreal

6 hours ago, tuna83 said:

I hate that I can't get this working myself. I've combed the FAQ and can't find anything in this thread that seems to match what's going on.

 

I've had this docker working before, but am only now trying to swap over completely from qbittorrent. I pulled it again and can't seem to get the webui to load.

Tried deleting all the old config and starting again with no luck. Can't seem to see any significant errors in the supervisord log.

 

When I try to go into the web ui it times out persistently. Any thoughts?

 

 

supervisord.log 55.38 kB · 0 downloads

lan network is invalid, from your log:-

 

2020-08-31 22:36:47.204123 [info] LAN_NETWORK defined as '192.168.0.1/24'

see Q4 from the following link for how to calculate it correctly:-

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

5 hours ago, BiGBaLLA said:

I started seeing this with the most recent version as well.  I'm using AirVPN.  Rolling back to version v3.10-01 fixed the issue.  Looking at Github, the only difference between the two versions is Commit ad060d.  I don't see how change would have any impact, but every time I downgrade the issue goes away. 

 

EDIT: Ahh, I didn't see the comments on the commit. Binhex confirmed the change is not related to this.

if you are using AirVPN then i would be interested to see your log, please do the following:-

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

17 hours ago, binhex said:

if you are using AirVPN then i would be interested to see your log, please do the following:-

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

@binhex I am seeing this using AirVPN

 

 

Edited September 1, 20205 yr by lzrdking71

1 hour ago, binhex said:

lan network is invalid, from your log:-

 

2020-08-31 22:36:47.204123 [info] LAN_NETWORK defined as '192.168.0.1/24'

see Q4 from the following link for how to calculate it correctly:-

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

Thank you, of course it worked. I combed that log for about 3 hours trying to see something that would flag the issue. What made you see what the problem was?

 

Like I said I was pretty annoyed I couldn't fix it myself, even more annoyed now it turns out the answer is in the FAQ..

1 hour ago, binhex said:

if you are using AirVPN then i would be interested to see your log, please do the following:-

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

I'm not sure if it's helpful, but I attached the latest one and the 3.10 version. Both the same config / torrents. 3.10 shows the vpn ip to the tracker, and latest is showing 127.0.0.1.

 

Thanks, I really appreciate your work!

supervisord_3_10_01.log supervisord_latest.log

On 8/29/2020 at 7:24 PM, lzrdking71 said:

@binhex It looks like this is happening again https://github.com/binhex/arch-rtorrentvpn/issues/104

 

2020-08-29 17:10:49,842 DEBG 'start-script' stdout output:
[warn] Cannot determine external IP address, performing tests before setting to '127.0.0.1'...
[info] Show name servers defined for container

 

IP in the rutorrent settings/bittorent shows 127.0.0.1. I am using Airvpn as my vpn provider and the latest docker container available to unraid.

 

You helped fix it before, hopefully an easy fix again.

 

I am having the same exact issue above. I am also using AirVPN as my provider and have the latest available container.

10 hours ago, tuna83 said:

What made you see what the problem was?

ive created and supported this image for a LOT of years now, after a while you see the problem quite quickly :-), plus your symptom is classic of misconfigured lan - cannot access the web ui but the container has started successfully.

@lzrdking71 @theGrok i have identified the issue, not exactly sure how it was related to my previous change but it has caused a race condition, i have now corrected this and the image is building, please pull it down in around 1 hour from now.

2 hours ago, binhex said:

@lzrdking71 @theGrok i have identified the issue, not exactly sure how it was related to my previous change but it has caused a race condition, i have now corrected this and the image is building, please pull it down in around 1 hour from now.

This did it for me! I updated all my instances and all are working correctly again, thank you for fixing this so quickly!

3 hours ago, binhex said:

@lzrdking71 @theGrok i have identified the issue, not exactly sure how it was related to my previous change but it has caused a race condition, i have now corrected this and the image is building, please pull it down in around 1 hour from now.

I pulled the update and all seems to working great. Thx @binhex for this great container and for your work!

5 hours ago, binhex said:

@lzrdking71 @theGrok i have identified the issue, not exactly sure how it was related to my previous change but it has caused a race condition, i have now corrected this and the image is building, please pull it down in around 1 hour from now.

@binhex, all is working again after the update. You are awesome, thanks for all your hard work!

@binhex

 

Would it be possible to have the script run through a list of .ovpn files after failing to port forward with one? Use case would be, CA-Montreal is having port-forward API issues right now, and as it is the first in the list alphabetically (I assume), the script only chooses it to retry with. Could it instead take a list of all .ovpn files in the config/openvpn directory and try them each in succession until a successful API call is made?

 

As always, thanks for your work!

Edited September 6, 20205 yr by omninewb

On 9/6/2020 at 6:33 PM, omninewb said:

@binhex

 

Would it be possible to have the script run through a list of .ovpn files after failing to port forward with one? Use case would be, CA-Montreal is having port-forward API issues right now, and as it is the first in the list alphabetically (I assume), the script only chooses it to retry with. Could it instead take a list of all .ovpn files in the config/openvpn directory and try them each in succession until a successful API call is made?

 

As always, thanks for your work!

While we wait for binhex, I built a docker on top of his to randomly pick an .ovpn file from a folder on docker start/restart. Sort of a quick fix for now.

1. Create a folder called 'openvpn_files' under your rtorrentvpn appdata folder (e.g. mkdir /mnt/user/appdata/rtorrentvpn/openvpn_files)
2. Extract / copy the (PIA) .ovpn files to the above openvpn_files folder.
3. Edit your docker template and change Repository to 'testdasi/rutorrentvpn-plus-plus' and Docker Hub URL to 'https://registry.hub.docker.com/r/testdasi/rutorrentvpn-plus-plus/'
4. Apply and check log. If doesn't work then restart the docker and it will pick a random one from the openvpn_files.

 

 

To revert back to binhex's one, edit the docker template and change Repository to 'binhex/arch-rtorrentvpn' and Docker Hub URL to 'https://registry.hub.docker.com/r/binhex/arch-rtorrentvpn/'

 

 

 

So I've tried every endpoint in the PIA list and all throw this:
 

2020-09-09 10:39:03,388 DEBG 'start-script' stdout output:
[info] List of PIA endpoints that support port forwarding:-
[info] ca-toronto.privateinternetaccess.com
[info] ca-montreal.privateinternetaccess.com
[info] ca-vancouver.privateinternetaccess.com
[info] de-berlin.privateinternetaccess.com
[info] de-frankfurt.privateinternetaccess.com
[info] france.privateinternetaccess.com
[info] czech.privateinternetaccess.com
[info] spain.privateinternetaccess.com
[info] ro.privateinternetaccess.com
[info] israel.privateinternetaccess.com
[info] Attempting to get dynamically assigned port...

2020-09-09 10:39:24,196 DEBG 'start-script' stdout output:
[warn] Exit code '52' from curl != 0 or no response body received
[info] 12 retries left
[info] Retrying in 10 secs...

2020-09-09 10:39:24,196 DEBG 'start-script' stdout output:
[warn] Exit code '52' from curl != 0 or no response body received
[info] 12 retries left
[info] Retrying in 10 secs...

 

 

Is PIA removing port forwarding ability completely?

 

If so, is there a different VPN that supports port forwarding that anyone would recommend?

 

 

EDIT, saw this on the PIA website:
* The information contained within this article will only work with our Current/Previous Generation servers. Our Next Generation servers do not currently offer port-forwarding outside of the application. *

 

So I guess as they upgrade their servers this will stop working.  Back to my other question then, can anyone recommend a different VPN that will work well with this docker?

Edited September 9, 20205 yr by dvd.collector