4 hours ago, Burizado said:

Yes.  I am using CA Toronto.  It is one of the locations mentioned in the my legacy log.  It doesn't get that far in the nextgen log, but I am assuming it works based on a previous post someone stating it works with nextgen.

 

Thanks for the follow-up question.  I forgot to mention what location I am testing.

Just wanted to join in that I am having the same exact issues Burizado.  I did try with other Port Forwarding ovpn's to no avail.  Its like my credentials are not being passed correctly or are bad (but PIA works fine from desktop).  I am using the PPTP/SOCKS credentials.

Edited October 3, 20205 yr by viciouscircle
clarification

welp that settles it...

 

i only changed from qbittorrent because i was too dumb to realize i needed the nextget vpn files and not the old files

so i tried deluge and got like 8 megaBytes per second

 

went back to qbittorrent and downloaded 4 Ubuntu ISO's and got to 32 megaBytes without breaking a sweat

 

its absolutely possible different times of the day may of caused this bottle neck but w/e i like the interface of qbittorrent better anways 

 

Thanks binhex for great work!

I can confirm I am seeing slower speeds with the nextgen servers. Apparently qbittorrent is pulling data down faster even with nextgen servers. Is there something we can change to increase our speed to what it should be for deluge? 

Hi, since about a week ago my deluge docker has stopped working and I'm not sure how to fix it. When I start the docker, the logs have these errors:

2020-10-03 13:44:13,427 DEBG 'start-script' stderr output:
/root/openvpn.sh: eval: line 73: unexpected EOF while looking for matching `''
/root/openvpn.sh: eval: line 74: syntax error: unexpected end of file

 

After a minute the docker seems to be using 100% of my CPU and RAM, other dockers start crashing and the Unraid web-ui goes non-responsive.

 

I have tried removing the docker (and also removing the image) and reinstalling. I also tried rolling back to an older version from 2 months ago which gave me a different error:

 

2020-10-03 14:03:00,929 DEBG 'start-script' stdout output:
[warn] Exit code '52' from curl != 0 or no response body received
[info] 7 retries left
[info] Retrying in 10 secs...

 

I also followed the instructions to upgrade to PIA Nextgen thinking that might be the problem, but no change.

 

Does anybody know what the problem is and how I can fix it? Thanks in advance

Since switching over to next gen PIA servers I have been seeing very slow website DNS resolves when using my browser that has its proxy settings pointed to the Deluge privoxy port. After some trouble shooting I decided to remove all the prefilled PIA DNS addresses from Name_Servers in the Deluge templet and only use the Cloudflare addressed. Doing this resolved me slow resolve issue.

 

Turns out that PIA next gen has a new set of server addresses for it as well, link to them below.

https://www.privateinternetaccess.com/helpdesk/kb/articles/next-generation-dns-custom-configuration

I added the new PIA DNS addresses to Name_Servers and everything is working normally again.

 

Not sure if I missed this in binhex's instructions somewhere but I suggest that everyone who has moving over to PIA next gen also update the Name_Servers from PIA legacy to PIA nextgen addresses.

 

Still not sure why I get slow resolves when the I have PIA DSN addresses listed in Name_Servers. Dose anyone else have a browser pointed at the privoxy port and seeing very slow site resolves?

Edited October 3, 20205 yr by TrueImpulse

10 hours ago, viciouscircle said:

Just wanted to join in that I am having the same exact issues Burizado.  I did try with other Port Forwarding ovpn's to no avail.  Its like my credentials are not being passed correctly or are bad (but PIA works fine from desktop).  I am using the PPTP/SOCKS credentials.

It's not the socks credentials you need, it's your main username (pXXXXXXX) & password for PIA.

4 hours ago, xxDeadbolt said:

It's not the socks credentials you need, it's your main username (pXXXXXXX) & password for PIA.

Awesome!  I changed my credentials in the docker setup and it came up perfectly!  Thank you for this information!

8 hours ago, TrueImpulse said:

Turns out that PIA next gen has a new set of server addresses for it as well, link to them below.

https://www.privateinternetaccess.com/helpdesk/kb/articles/next-generation-dns-custom-configuration

I added the new PIA DNS addresses to Name_Servers and everything is working normally again.

 

This doesn't seem to work for me.  My DelugeVPN docker is currently configured with Google name servers.  If I change the Key9 setting to two of the 10.0.0.? addresses, the vpn tunnel fails to come up.  Have I misunderstood?

 

10.0.0.0/8 are private addresses so can't possibly work before the tunnel is up.

 

Edit:

Yep, I've just read again - those DNS addresses are for use within the PIA applications, and are set automatically.

Edited October 3, 20205 yr by PeterB

2 hours ago, PeterB said:

This doesn't seem to work for me.  My DelugeVPN docker is currently configured with Google name servers.  If I change the Key9 setting to two of the 10.0.0.? addresses, the vpn tunnel fails to come up.  Have I misunderstood?

 

10.0.0.0/8 are private addresses so can't possibly work before the tunnel is up.

 

Edit:

Yep, I've just read again - those DNS addresses are for use within the PIA applications, and are set automatically.

I'm sure your right. I know that 10.0.0* address are for private network IP schemes, I was kind of tired last night and I just went with it, sorry.

 

This must mean that the container is disregarding all the 10.0.0.* addresses and using the Cloudflare 1.1.1.1 I have in there. Still doesn't explain why its so slow resolving when I have the PIA addresses in there. I suppose the PIA DNS is having issue but I never had this problem on legacy.

 

Dose anyone else have a browser pointed at their privoxy port and noticing very slow site resolves when using the default Name_Servers for a PIA setup?

 

Edited October 3, 20205 yr by TrueImpulse

Hello;

I updated my delugevpn after a month and am unable to connect to the web browser.  As soon as I disable VPN, it works.

  I am a slick VPN user, not PIA, and have been having issues.

 

I have confirmed using my local pc that slickvpn works, and works with a torrent client.  When I check the supervisord.log I do get the weird restart issue:
 

Quote

 

Sat Oct  3 18:24:11 2020 /usr/bin/ip addr add dev tun0 local 10.10.8.26 peer 10.10.8.25

2020-10-03 18:24:11,195 DEBG 'start-script' stdout output:
Sat Oct  3 18:24:11 2020 /root/openvpnup.sh tun0 1500 1557 10.10.8.26 10.10.8.25 init

2020-10-03 18:24:11,203 DEBG 'start-script' stdout output:
[debug] Waiting for valid local and gateway IP addresses from tunnel...

 

I have tried different slickVPN locations, have messed around with the slickVPN cert as well, all to no avail.  Checked my network, no changes on port forwarding or anything like that.

Just wondering if anyone can point me in the right direction?  

delugevpnlogs.txt

1 hour ago, Exmond said:

Just wondering if anyone can point me in the right direction?  

from your log:-

 

2020-10-03 18:23:45,030 DEBG 'start-script' stdout output:
Sat Oct  3 18:23:45 2020 [VPN] Inactivity timeout (--ping-restart), restarting

see Q17 from the following link:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

On 9/20/2020 at 2:21 PM, Ranzingabon Hagglesmith said:

I've noticed some strange problems over the past few weeks-- mostly torrent time-out errors, and now I'm getting the "Error: end of file" on random files from one particular tracker. I thought it might be a problem with the particular AirVPN server I was using, so I restarted the container a few days ago, but the errors just creeped back. Any idea what might  be going wrong? My fear is that might be because of the number of torrents I have (~2500 unpaused). I have the ltConfig plugin set up and adjusted, and that fixed errors that arose when I hit around 2,000 torrents, so I'm hoping it's something that can be fixed by playing around with those settings. Strange that rebooting the Deluge docker fixes the timeout errors for a few days.

 

Actually, it seems the "Error: end of file" error I'm receiving from torrents for one particular tracker is not fixed by rebooting the container, so I have no clue what's going on there.

 

I'm running the latest version of the Binhex DockerDelugeVPN via AirVPN.

 

e: rechecking the torrents does not seem to fix the "Error: end of file" problem

Hi folks, any thoughts?

 

Now I'm getting errors "Error: unexpected end of file in bencoded string" and  "Error: No route to host"

 

11 hours ago, binhex said:

from your log:-

 

2020-10-03 18:23:45,030 DEBG 'start-script' stdout output:
Sat Oct  3 18:23:45 2020 [VPN] Inactivity timeout (--ping-restart), restarting

see Q17 from the following link:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

So, the issue I am having is, openvpn works on the docker host:

 

Quote

[root@docker02v openvpn]# openvpn --config /u01/deluge/openvpn/slick_seattle.ovpn
Sun Oct  4 03:04:13 2020 WARNING: file 'credentials.conf' is group or others accessible
Sun Oct  4 03:04:13 2020 OpenVPN 2.4.9 x86_64-redhat-linux-gnu [Fedora EPEL patched] [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 24 2020
Sun Oct  4 03:04:13 2020 library versions: OpenSSL 1.0.2k-fips  26 Jan 2017, LZO 2.06
Sun Oct  4 03:04:13 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]50.22.146.42:443
Sun Oct  4 03:04:13 2020 UDP link local: (not bound)
Sun Oct  4 03:04:13 2020 UDP link remote: [AF_INET]50.22.146.42:443
Sun Oct  4 03:04:13 2020 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Sun Oct  4 03:04:13 2020 [VPN] Peer Connection Initiated with [AF_INET]50.22.146.42:443
Sun Oct  4 03:04:15 2020 TUN/TAP device tun0 opened
Sun Oct  4 03:04:15 2020 /sbin/ip link set dev tun0 up mtu 1500
Sun Oct  4 03:04:15 2020 /sbin/ip addr add dev tun0 local 10.10.8.6 peer 10.10.8.5
Sun Oct  4 03:04:15 2020 Initialization Sequence Completed

So I am connected, when I do a curl to http://whatismyip.host

 

Quote

[root@mikedocker02v ~]# curl http://whatismyip.host | grep ipaddress
            <p class="ipaddress">50.22.146.42</p>
 

 

So outside docker container, and on the same host, it works.  I'll try and do the same test on the docker container itself

One of the reasons I have stuck with the 1.3.15 version of deluge is its ability to use the thin client, which I far prefer over the web client. But progress moves on, and I far prefer having the port forwarding OpenVPN with PIA, so a small price to pay. (And the legacy servers are retiring at the end of the month!)

 

I do have a question, however. I force upgraded the newest binhex image, set it up, everything works pretty spontaneously. Thanks for all the quick, hard work, binhex!! The connection to CA Toronto resulted in a port forward connection. I can see this through one of my torrent providers that reports back if your seed is port forwarded. On the thin client, I could press a button on the Network tab of Preferences to "Check Port", which would always show a green ball if the port was forwarded or a yellow triangle/exclamation if not. Since there is no thin client in this version of deluge, and the web client on Network tab of Preferences does not have this, just a filled in port number, my question is this: Is there a way to determine if port forward is active on the connection? Can I inspect either supervisord or through the console window for the docker to easily confirm port forwarding is active for the torrents in the client?

1 hour ago, terag1e said:

One of the reasons I have stuck with the 1.3.15 version of deluge is its ability to use the thin client, which I far prefer over the web client. But progress moves on, and I far prefer having the port forwarding OpenVPN with PIA, so a small price to pay. (And the legacy servers are retiring at the end of the month!)

Thin client works fine - your problem is Microsoft or Apple!

 

Just thinking obliquely - if you were to set up a VM running Linux, could run the thin client on it with a remote desktop.

Edited October 4, 20205 yr by PeterB

11 minutes ago, PeterB said:

Thin client works fine - your problem is Microsoft or Apple!

 

Just thinking obliquely - if you were to set up a VM running Linux, could run the thin client on it with a remote desktop.

And I may yet! I have quite a few VMs throughout the network, but right now it's a problem for days in the future (thin client)!!

1 hour ago, PeterB said:

Thin client works fine - your problem is Microsoft or Apple!

Actually, there is a macOS app- https://www.dropbox.com/s/c51t7y5kh7za2kl/Deluge.app.7z?dl=1

Was a little buggy in my testing though. Had a tendency to crash.

On 10/3/2020 at 3:46 AM, xxDeadbolt said:

It's not the socks credentials you need, it's your main username (pXXXXXXX) & password for PIA.

xxDeadbolt, thanks for this I have been struggling for awhile now.  Under the old PIA server I used the socks user and password. I have been reading this thread and never saw that.  I'm up and running now.

Anyone have a recommended solution?

 

I've had to restart my container 5 times today and it finally connected with berlin.   I'm not married to PIA, but do need a VPN where I can torrent without worry.  I do need deluge as it fits my needs for automations.   (Can't find another container that can unrar/move files upon download)

 

 

Why did you have to restart it, what's happening (logs?) ? 

On 3/23/2020 at 4:05 AM, tehtide said:

I've got both networks in there. I'm able to ping the deluge docker VPN from both networks, but radarr/sonarr won't connect to the json feed if they are on the same network.

Unknown exception: The operation has timed out.: 'http://10.10.50.22:8112/json'

 

@tehtid, did you ever fix this or anyone else know how to get it working? I'm having the exact same issue.

Something stranger is that the VPN port (8118) works but the Deluge port (8112) doesn't work. I'm testing by telnet'ing to the port from the Sonarr docker. Telnet was installed by issuing `pacman -S inetutils` after connecting to the Docker's console.

 

I tested the other port (58846) and that one connects. For some reason 8112 won't connect.

 

 

Connects fine from other networks (eg: my laptop)

 

 

If I set vpn to off in delugevpn, the Sonarr docker can now reach 8112/tcp on delvugevpn. My laptop can still connect to delugevpn on 8112/tcp.

 

Edited October 5, 20205 yr by MrLinux
Clarified which docker I was trying to telnet from to test the port

7 hours ago, xxDeadbolt said:

Why did you have to restart it, what's happening (logs?) ? 

I was away for the weekend and come home and Deluge wasn't gui wasn't loading, showed it was trying to connect over and over.  

 

Logs show now "Incoming port site 'https://portchecker.co/' failed to web scrape, marking as failed"

 

Edited October 5, 20205 yr by djgizmo

17 hours ago, djgizmo said:

I was away for the weekend and come home and Deluge wasn't gui wasn't loading, showed it was trying to connect over and over.  

 

Logs show now "Incoming port site 'https://portchecker.co/' failed to web scrape, marking as failed"

 

I think there may have been an issue with that before but, if memory serves, Binhex said it was fixed. You definitely on the latest container version? Using legacy or nextgen servers for PIA?

17 hours ago, djgizmo said:

I was away for the weekend and come home and Deluge wasn't gui wasn't loading, showed it was trying to connect over and over.  

 

Logs show now "Incoming port site 'https://portchecker.co/' failed to web scrape, marking as failed"

 

yeah thats something for me to look at as it looks like something has changed on the remote site, however it will fall back to the next website to check for incoming port so that is not the issue, most probably you havent switch to next-gen and thus you are seeing the crumbling legacy-gen network issues.

On 9/29/2020 at 8:11 AM, Geran said:

Thank you. That's what I originally did after removing the test tag but I just did it again and it is working now.

 

On 9/29/2020 at 8:11 AM, Geran said:

Thank you. That's what I originally did after removing the test tag but I just did it again and it is working now.

Can someone explain how to do a 'force update'?   I'm having the same issue that my OpenVPN won't connect with Port Forwarding....   Thanks