CAn anyone tell me why Deluge´s Download speed is so slow? it is not limited and on Rutorrent the speed is 10 times higher

Hi all,

I downloaded https://www.privateinternetaccess.com/openvpn/openvpn.zip
and it got 2 openvpn files for say berlin and I tried both and getting this still:

 

 

2020-12-17 14:03:51,409 DEBG 'start-script' stdout output:
[warn] PIA endpoint 'de-berlin.privacy.network' is not in the list of endpoints that support port forwarding, DL/UL speeds maybe slow
[info] Please consider switching to one of the endpoints shown below

2020-12-17 14:03:51,410 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

any ideas?

it was working a few months back then suddenly wasn't working so I tied to D/L the openvpn files again thinking it was updated....

3 hours ago, aerosmith9110 said:

Hi all,

I downloaded https://www.privateinternetaccess.com/openvpn/openvpn.zip
and it got 2 openvpn files for say berlin and I tried both and getting this still:

 

 

2020-12-17 14:03:51,409 DEBG 'start-script' stdout output:
[warn] PIA endpoint 'de-berlin.privacy.network' is not in the list of endpoints that support port forwarding, DL/UL speeds maybe slow
[info] Please consider switching to one of the endpoints shown below

2020-12-17 14:03:51,410 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

any ideas?

it was working a few months back then suddenly wasn't working so I tied to D/L the openvpn files again thinking it was updated....

whilst you have correctly updated your openvpn ocnfig files, you are still using an old tagged image, remove the tag and pull down latest.

Hi binhex,

and thank you for your work ! Everything work just fine.

But I'm trying to set SWAG with deluge.

 

But I've an 502 error.

 

Did someone in here know where the problem come from ?

 

Thanks

 

2 hours ago, binhex said:

whilst you have correctly updated your openvpn ocnfig files, you are still using an old tagged image, remove the tag and pull down latest.

Thanks for responding.. can you elaborate more on " remove the tag and pull down latest. " what does tag means?

31 minutes ago, aerosmith9110 said:

Thanks for responding.. can you elaborate more on " remove the tag and pull down latest. " what does tag means?

see here:- https://forums.unraid.net/topic/44109-support-binhex-delugevpn/?do=findComment&comment=919094

 

 

1 minute ago, binhex said:

see here:- https://forums.unraid.net/topic/44109-support-binhex-delugevpn/?do=findComment&comment=919094

 

 

wow tnx!

 

I'm still getting "the remote line is referencing PIA legacy network which is now shutdown" error, even though I've downloaded the newest openvpn.zip file from PIA, and am using the latest (and tried the test) branch of binhex-delugevpn. I've also tried another ovpn file (usually using CA\ Montreal.ovpn, tried CA\ Toronto.ovpn), and get the same error. What am I doing wrong?

2020-12-17 11:34:30.164925 [info] PUID defined as '99'
2020-12-17 11:34:30.189888 [info] PGID defined as '100'
2020-12-17 11:34:30.871321 [info] UMASK defined as '000'
2020-12-17 11:34:30.894360 [info] Permissions already set for volume mappings
2020-12-17 11:34:30.918113 [info] Deleting files in /tmp (non recursive)...
2020-12-17 11:34:30.945285 [info] VPN_ENABLED defined as 'yes'
2020-12-17 11:34:30.969321 [warn] VPN_CLIENT not defined (via -e VPN_CLIENT), defaulting to 'openvpn'
2020-12-17 11:34:30.992415 [info] VPN_PROV defined as 'pia'
2020-12-17 11:34:31.608775 [info] OpenVPN config file (ovpn extension) is located at /config/openvpn/CA Toronto.ovpn
2020-12-17 11:34:31.646677 [crit] VPN configuration file '/config/openvpn/CA Toronto.ovpn' 'remote' line is referencing PIA legacy network which is now shutdown, see Q19. from the following link on how to switch to PIA 'next-gen':- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md exiting script...

client
dev tun
proto udp
remote ca-montreal.privateinternetaccess.com 1198
resolv-retry infinite
nobind
persist-key
persist-tun
cipher aes-128-cbc
auth sha1
tls-client
remote-cert-tls server

auth-user-pass
compress
verb 1
reneg-sec 0
<crl-verify>
-----BEGIN X509 CRL-----
...
-----END X509 CRL-----
</crl-verify>

<ca>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</ca>

 

manderso@Tower:/mnt/user/appdata/binhex-delugevpn$ ls -al openvpn/
total 16
drwxrwxr-x 1 nobody users  124 Dec 17 11:34 ./
drwxrwxr-x 1 nobody users  486 Nov  8 14:40 ../
-rwxrwxr-x 1 nobody users 3180 Dec 17 11:34 CA\ Toronto.ovpn*
-rwxrwxr-x 1 nobody users 2025 Dec 17 11:03 ca.rsa.2048.crt*
-rwxrwxr-x 1 nobody users   20 Nov 11 08:26 credentials.conf*
-rwxrwxr-x 1 nobody users  869 Dec 17 11:03 crl.rsa.2048.pem*

Thanks for your help.

Edited December 17, 20205 yr by manderso

1 minute ago, manderso said:

[crit] VPN configuration file '/config/openvpn/CA Toronto.ovpn' 'remote' line is referencing PIA legacy network which is now shutdown, see Q19. from the following link on how to switch to PIA 'next-gen':- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md exiting script...

it looks like you switched back to the older ovpn file, please do as instructed in the log shown above.

After updates to my binhex dockers i get [54da0c7] Unknown exception in url **api Error: Not supported proxy scheme in medusa. is this a proxy or a medusa problem?

 

edit: solved my self. seems the new version of medusa needs http:// in front of ip adress of the proxy. Was not needed until this release.

Edited December 17, 20205 yr by orlando500
solved it

 

3 hours ago, binhex said:

it looks like you switched back to the older ovpn file, please do as instructed in the log shown above.

Yep. Thought I had copied over the new file, guess I didn't. Sorry to bother you. Thanks for the help.

Hi, so a few months ago my Torrents stopped downloading. When I try to add a torrent it starts like it's going to begin downloading, but then eventually trickles down in speed and stops all together. I'm on Version 6.8.3 and before that it was working great. At first I didn't think anything of it while going away for a couple months visiting family up north. Then I get back and try to solve the problem. I restarted, stopped and updated qbittorrentvpn docker I was using at the time. No dice there. Restarted the computer and that didn't make a difference. I eventually decided to uninstall qbittorrentvpn, and setup binhex-delugevpn (I think) and same experience here. I tried updating the PIA OpenVPN files, but that didn't do anything. If I turn the VPN off, same experience. I've attached my logs for you guys to look at, hopefully one of you can spot something there. Should I update to 6.9.0-rc1? I see 6.8.3 is the most recent. Sorry for the long rant, but hopefully you guys can get me back on track here. 

tower-syslog-20201216-2349.zip

On 12/10/2020 at 12:24 AM, redpathx said:

Hi All,

 

Hoping for another tip here. Running with PIA & openvpn, I am able to connect to the webui, but am unable to connect to any seeders. This has happened on and off for the past week or so, has mysteriously fixed itself a couple times without me intervening then reverted to this problem. Not sure if its an AUTH problem, but I don't see anything in the logs to point that way. Log attached.

 

Thanks!

supervisord.log 2.16 MB · 4 downloads

Hi All,

 

Been continuing to battle this. It is randomly cycling, some days torrents will download, other days will not connect to any seeders (these are generally just public trackers, RARBG etc.). The only thing I can point to is the listening port that randomizes.

For example, it wasn't working when set as follows. 

Quote

2020-12-18 10:16:27,295 DEBG 'start-script' stdout output:
[info] Successfully assigned and bound incoming port '24937'

 

I then restarted the container, and it started working again, and the listening port was defined as follows

Quote

2020-12-18 19:10:38,397 DEBG 'start-script' stdout output:
[info] Successfully assigned and bound incoming port '41687'

I don't know/understand enough about these ports to know what makes one work vs another. Any tips on how I could fix this in settings to it is no longer seemingly rolling a dice?

 

Thanks!

I don't know/understand enough about these ports to know what makes one work vs another. Any tips on how I could fix this in settings to it is no longer seemingly rolling a dice?
 
Thanks!

I don’t think you can, sorry.
The port is randomly given out by PIA from its pool for the particular server you are connecting to.
The container uses a script that asks for a new (random) port on each reconnection to the VPN server.


Sent from my iPhone using Tapatalk

Think I'm experiencing the same thing that redpathx is or at least something similar. Think it's something with the PIA OpenVPN files and I should try another server? Only weird thing is when I "turn it off" I still get the same experience and nothing downloads. 

36 minutes ago, yanksno1 said:

Think I'm experiencing the same thing that redpathx is or at least something similar. Think it's something with the PIA OpenVPN files and I should try another server? Only weird thing is when I "turn it off" I still get the same experience and nothing downloads. 

Ah interesting. I switched to wireguard and it didn’t make a difference, but I haven’t tried different servers. (I’m using CA Toronto)

47 minutes ago, redpathx said:

Ah interesting. I switched to wireguard and it didn’t make a difference, but I haven’t tried different servers. (I’m using CA Toronto)

Didn't try that either (or wireguard). I just tried setting up qbittorrentvpn using the new Netherlands OpenVPN files again and it does seem to be working there. Every one so far has completed downloading. I can't seem to get Sonarr working with it again, but that's another story. Then copied those same files to this docker folder and still not working for me. So no idea what it is. But it does sound like we're experiencing the same thing. Are you on version 6.8.3 too? 

2 hours ago, Jorgen said:

I don’t think you can, sorry.
The port is randomly given out by PIA from its pool for the particular server you are connecting to.
The container uses a script that asks for a new (random) port on each reconnection to the VPN server.


Sent from my iPhone using Tapatalk

Would that mean these ports are likely blocked on the tracker end?

Would that mean these ports are likely blocked on the tracker end?

Possibly, not sure how you would find out though. Can you ask the tracker?


Sent from my iPhone using Tapatalk

Hi,

 

I'm using PIA and I understand somethings have changed now. I am unable to log into delugevpn unless I disable VPN.

I am on an older version (arch-delugevpn:1.3.15_18_ge050905b2-1-04) because before the PIA issues started I was experiencing the same issue as allot of other people on the latest version of delugeVPN where the speeds dropped.

 

Is there a fix to this issue using PIA?

 

Many thanks.

 

Neil

 

2 minutes ago, Lien1454 said:

Hi,

 

I'm using PIA and I understand somethings have changed now. I am unable to log into delugevpn unless I disable VPN.

I am on an older version (arch-delugevpn:1.3.15_18_ge050905b2-1-04) because before the PIA issues started I was experiencing the same issue as allot of other people on the latest version of delugeVPN where the speeds dropped.

 

Is there a fix to this issue using PIA?

 

Many thanks.

 

Neil

 

You can switch to PIA’s next-gen servers to correct your connection issues but this will also require upgrading the docker container (and the Deluge app) to the latest version. You will likely see the original issues with Deluge return since it’s probably still the same version you originally had issues with. I switched docker containers instead. I’m now using binhex-qbittorrentvpn docker with the PIA next-gen servers until Deluge releases an update that hopefully fixes some of their bugs.

12 hours ago, yanksno1 said:

Didn't try that either (or wireguard). I just tried setting up qbittorrentvpn using the new Netherlands OpenVPN files again and it does seem to be working there. Every one so far has completed downloading. I can't seem to get Sonarr working with it again, but that's another story. Then copied those same files to this docker folder and still not working for me. So no idea what it is. But it does sound like we're experiencing the same thing. Are you on version 6.8.3 too? 

yeah also on 6.8.3. i'll give other endpoints and maybe qbittorrentvpn a shot too

Hi there,

this might be strange, but yesterday I installed the qbittorrent VPN and everything seemed fine. However, now I cannot access the deluge webUI anymore as the password "deluge" does not work.

What can I do?

 

Edit: It turned out there is no password set at all. Just hit enter and it worked. 

Edited December 22, 20205 yr by TombRaider
evidence surfaced

NEVERMIND FIXED: After discovering there were no config files for deluge-vpn I disabled and re-enabled docker. Config files showed up, copied openvpn files as per usual and I'm back up and running. Leaving this post for others. 

 

Had some kind of event at 3am that killed my dockers. Could have been a power outage I guess, I have a UPS but it has never worked very well with unraid. I'm not even sure that was it as the server was powered on and it shouldn't have been if there was an outage. 

UPDATE: 3am on Sunday is when my dockers auto-update. 

Regardless, all of my dockers came back up except binhex deluge-vpn. When I try to start it I get Execution Error Server Error window. When I check the server logs the only thing that shows up is BELOW. I have had my server set up for IPV4 only in network settings for years. Supervisord.log hasn't been touched since 3am. 

 

UPDATE: I got impatient and deleted the docker and re-installed. On startup I got;

/usr/bin/docker: Error response from daemon: driver failed programming external connectivity on endpoint binhex-delugevpn (af91521bd4e05570c2288cc4ccc838cbe668d260d8971415f2e7ecf929226404): Bind for 0.0.0.0:58946 failed: port is already allocated.

 

The port is not allocated to any other docker though. 

 

UPDATE: Now there are no config files written at all. 

 

 

 

Dec 21 09:23:33 tmedia kernel: IPv6: ADDRCONF(NETDEV_UP): veth37e079a: link is not ready
Dec 21 09:23:33 tmedia kernel: docker0: port 8(veth37e079a) entered blocking state
Dec 21 09:23:33 tmedia kernel: docker0: port 8(veth37e079a) entered forwarding state
Dec 21 09:23:33 tmedia kernel: docker0: port 8(veth37e079a) entered disabled state
Dec 21 09:23:33 tmedia kernel: docker0: port 8(veth37e079a) entered disabled state
Dec 21 09:23:33 tmedia kernel: device veth37e079a left promiscuous mode
Dec 21 09:23:33 tmedia kernel: docker0: port 8(veth37e079a) entered disabled state
Dec 21 09:29:18 tmedia kernel: docker0: port 8(vethd741bb1) entered blocking state
Dec 21 09:29:18 tmedia kernel: docker0: port 8(vethd741bb1) entered disabled state
Dec 21 09:29:18 tmedia kernel: device vethd741bb1 entered promiscuous mode
Dec 21 09:29:18 tmedia kernel: IPv6: ADDRCONF(NETDEV_UP): vethd741bb1: link is not ready
Dec 21 09:29:18 tmedia kernel: docker0: port 8(vethd741bb1) entered blocking state
Dec 21 09:29:18 tmedia kernel: docker0: port 8(vethd741bb1) entered forwarding state
Dec 21 09:29:18 tmedia kernel: docker0: port 8(vethd741bb1) entered disabled state
Dec 21 09:29:18 tmedia kernel: docker0: port 8(vethd741bb1) entered disabled state
Dec 21 09:29:18 tmedia kernel: device vethd741bb1 left promiscuous mode
Dec 21 09:29:18 tmedia kernel: docker0: port 8(vethd741bb1) entered disabled state
Dec 21 09:32:30 tmedia kernel: docker0: port 8(veth63d7cc7) entered blocking state
Dec 21 09:32:30 tmedia kernel: docker0: port 8(veth63d7cc7) entered disabled state
Dec 21 09:32:30 tmedia kernel: device veth63d7cc7 entered promiscuous mode
Dec 21 09:32:30 tmedia kernel: IPv6: ADDRCONF(NETDEV_UP): veth63d7cc7: link is not ready
Dec 21 09:32:30 tmedia kernel: docker0: port 8(veth63d7cc7) entered blocking state
Dec 21 09:32:30 tmedia kernel: docker0: port 8(veth63d7cc7) entered forwarding state
Dec 21 09:32:30 tmedia kernel: docker0: port 8(veth63d7cc7) entered disabled state
Dec 21 09:32:30 tmedia kernel: docker0: port 8(veth63d7cc7) entered disabled state
Dec 21 09:32:30 tmedia kernel: device veth63d7cc7 left promiscuous mode
Dec 21 09:32:30 tmedia kernel: docker0: port 8(veth63d7cc7) entered disabled state
Dec 21 09:37:49 tmedia kernel: docker0: port 8(vethdc3cb46) entered blocking state
Dec 21 09:37:49 tmedia kernel: docker0: port 8(vethdc3cb46) entered disabled state
Dec 21 09:37:49 tmedia kernel: device vethdc3cb46 entered promiscuous mode
Dec 21 09:37:49 tmedia kernel: IPv6: ADDRCONF(NETDEV_UP): vethdc3cb46: link is not ready
Dec 21 09:37:49 tmedia kernel: docker0: port 8(vethdc3cb46) entered blocking state
Dec 21 09:37:49 tmedia kernel: docker0: port 8(vethdc3cb46) entered forwarding state
Dec 21 09:37:49 tmedia kernel: docker0: port 8(vethdc3cb46) entered disabled state
Dec 21 09:37:50 tmedia kernel: docker0: port 8(vethdc3cb46) entered disabled state
Dec 21 09:37:50 tmedia kernel: device vethdc3cb46 left promiscuous mode
Dec 21 09:37:50 tmedia kernel: docker0: port 8(vethdc3cb46) entered disabled state

 

 

Edited December 21, 20205 yr by sol

For a while now, whenever the container is updated it completely empties my queue and I have to go back and re-add everything. What's up with that? 

 

Let me know where to have a look.

THANKS!