[Support] binhex - DelugeVPN


Recommended Posts

 

13 minutes ago, PeterB said:

Indeed, not good, then.

 

I see this in your log:


2018-08-16 00:07:57,053 DEBG 'start-script' stdout output:
[warn] PIA endpoint '185.230.125.50' doesn't support port forwarding, DL/UL speeds will be slow
[info] Please consider switching to an endpoint that does support port forwarding, shown below:-

 

So, for whatever reason, it appears that the Swiss server that you are connected to is not able to initiate port forwarding.  Try switching to another end point.

 

I'm using the IP version of the OVPN, that's why this error is shown.

binhex actually made a new image which made it possible to use these files and make the portfowarding possible, even though it still gives an error message in the logs.

As you can see in the quote below.

 

I also double checked if the port was open with the open port check tool + my trackers tag me as connectable.

 

I also tried different regions (Swiss, CZ, France) and all of them cap at 3MBps.

Must be something else :S

 

On 8/15/2018 at 12:12 PM, NGDM said:

Awesome!

Thanks for the quick update.

 

Pulled the latest image and it fixed both problems.

For the icons I had to clear the icons folder under config/, restart the container and clear the website data on my browser.

 

The IP files work as expected too :) port gets forwarded and set in Deluge.

Until the DNS problem gets resolved, I'm happy with this solution.

 

Thanks again ;)

Link to comment
1 minute ago, PeterB said:

 

Have you tried  a Speedtest via Privoxy?

 

Perhaps your ISP is messing with VPN connections?

 

My ISP is not known to partake in traffic shaping. In the past the VPN has always worked well (on other machines: Windows, Mac).

This is the first time I notice slower speeds on PIA.

 

Normal connection on Windows (same network):

7558177326.png

 

VPN (France) on Windows:

7558184826.png

Link to comment

So...I found a comment on reddit:

Followed this guy's explanation and voila:

image.png.bbe7c3ce04546319a0dc6bfae70a2373.png

 

Not sure if this does more bad than good, but it seems to work.

Anyone with experience with this kind of tinkering to libtorrent?

Edited by NGDM
  • Like 1
Link to comment

Str

17 minutes ago, NGDM said:

Followed this guy's explanation and voila

Strange!  I wonder why I can get 5+MBps up and down, on a 50Mbps connection, without any tinkering?

 

I guess it might be to do with the difference between tcp and udp connections.

Edited by PeterB
Link to comment
6 hours ago, glennv said:

In case like me you dont want to or have no time to mess with a previously fine working config and roll back to the last working image , just use this as your repository adress in your docker settings binhex/arch-delugevpn:1.3.15_14_gb8e5ebe82-1-14

  

the syntax is basicaly a colon plus the tag name of the image you want, which you can get from the docker repo website. That way youcan go to any version available.

 

edit: not sure how it can be an endpoint issue suddenly as that would then also not work when i revert to an older version would it ? 

Will try it next week when i have more patience as happy with the previous version ;-) 

Thanks, this worked for me as well. I agree it doesn’t make sense that reverting to an older version fixes the problem.

Link to comment
On 8/8/2018 at 5:15 PM, ecx said:

I've been using this container for at least a year,  without issue. Then my watchtower updated to the most recent build (2 days old)

 

Current build (latest) is giving me DNS errors with PIA servers. I swapped DNS providers (Cloudflare, Google) to no avail. I recreated the container, same problem. I tried current build of arch-rtorrentvpn with the same errors. I changed PIA servers (swiss, montreal, etc). Tried toggling with port forwarding on and off. No difference.

 

I created a new container with the arch-rtorrentvpn container with the previous build (0.9.7-1-07) and it worked*. Just did the same with arch-delugevpn back to 1.3.15_14_gb8e5ebe82-1-11 and it also works. The latest builds seem to be causing DNS errors with Synology DSM docker. I reloaded the old docker settings without issue on the manually specified build, so it doesn't seem to matter if it's from scratch or existing, the old builds work. New ones do not.  ?

 

 


2018-08-07 22:12:57,733 DEBG 'start-script' stdout output:
[info] Adding 1.1.1.1 to /etc/resolv.conf

2018-08-07 22:12:57,741 DEBG 'start-script' stdout output:
[info] Adding 1.0.0.1 to /etc/resolv.conf

2018-08-07 22:12:58,006 DEBG 'start-script' stderr output:
random.c:102: fatal error: RUNTIME_CHECK(ret >= 0) failed

2018-08-07 22:12:58,018 DEBG 'start-script' stdout output:
[crit] swiss.privateinternetaccess.com cannot be resolved, possible DNS issues

2018-08-07 22:12:58,018 DEBG fd 8 closed, stopped monitoring <POutputDispatcher at 140398907495416 for <Subprocess at 140398907496280 with name start-script in state RUNNING> (stdout)>
2018-08-07 22:12:58,019 DEBG fd 10 closed, stopped monitoring <POutputDispatcher at 140398907495056 for <Subprocess at 140398907496280 with name start-script in state RUNNING> (stderr)>
2018-08-07 22:12:58,019 INFO exited: start-script (exit status 1; not expected)
2018-08-07 22:12:58,019 DEBG received SIGCLD indicating a child quit

 

 

 

running this and rtorrent on synology docker, both working fine for many months until last week when i started getting error -
[crit] australia-sydney-ca-version-2.expressnetw.com cannot be resolved, possible DNS issues

 

Same error on both deluge and rtorrent. I have tried differnt VPN servers and receive the same error.

 

NAME_SERVERS addresses from my provider (express) and have always worked. no other addresses. also doesnt work with google or no value.

 

Same issue when changing setting STRICT_PORT_FORWARD to no

 


2018-08-17 03:34:00,352 DEBG 'start-script' stderr output:
random.c:102: fatal error: RUNTIME_CHECK(ret >= 0) failed

2018-08-17 03:34:00,382 DEBG 'start-script' stdout output:
[crit] australia-sydney-ca-version-2.expressnetw.com cannot be resolved, possible DNS issues

2018-08-17 03:34:00,382 DEBG fd 10 closed, stopped monitoring <POutputDispatcher at 140188251156208 for <Subprocess at 140188251155848 with name start-script in state RUNNING> (stderr)>
2018-08-17 03:34:00,383 DEBG fd 8 closed, stopped monitoring <POutputDispatcher at 140188251155920 for <Subprocess at 140188251155848 with name start-script in state RUNNING> (stdout)>
2018-08-17 03:34:00,385 INFO exited: start-script (exit status 1; not expected)
2018-08-17 03:34:00,386 DEBG received SIGCLD indicating a child quit
 

 

supervisord.log

Link to comment
56 minutes ago, Swoodle said:

Can no longer get to the WebUI after updating. .. . . . . I've tried to read through, change the end point to switz no avail. 

 

I had the same problem yesterday after updating the docker.  WebGUI was inaccessible. 

 

I changed the end point to Czech Republic (was on Netherlands), copied in the latest crl.rsa.2048 .pem file from the .zip, deleted supervisord.log, and put the docker into debug mode which restarted the docker.  All was well after that and I have entered and exited the GUI successfully several times since. Since the GUI was accessible after restarting the docker, I took the docker out of debug mode and have had no further issues.

 

I am not saying this is "the solution," just that it seemed to resolve the issue in my case.

Edited by Hoopster
Link to comment
11 hours ago, glennv said:

In case like me you dont want to or have no time to mess with a previously fine working config and roll back to the last working image

 

you do of course realise that you didn't have a fine working config right?, as in port forwarding was not operational, this will result in low dl speeds and inability to seed.

Link to comment
4 hours ago, soupdoup said:

 

running this and rtorrent on synology docker, both working fine for many months until last week when i started getting error -
[crit] australia-sydney-ca-version-2.expressnetw.com cannot be resolved, possible DNS issues

 

Same error on both deluge and rtorrent. I have tried differnt VPN servers and receive the same error.

 

NAME_SERVERS addresses from my provider (express) and have always worked. no other addresses. also doesnt work with google or no value.

 

Same issue when changing setting STRICT_PORT_FORWARD to no

 


2018-08-17 03:34:00,352 DEBG 'start-script' stderr output:
random.c:102: fatal error: RUNTIME_CHECK(ret >= 0) failed

2018-08-17 03:34:00,382 DEBG 'start-script' stdout output:
[crit] australia-sydney-ca-version-2.expressnetw.com cannot be resolved, possible DNS issues

2018-08-17 03:34:00,382 DEBG fd 10 closed, stopped monitoring <POutputDispatcher at 140188251156208 for <Subprocess at 140188251155848 with name start-script in state RUNNING> (stderr)>
2018-08-17 03:34:00,383 DEBG fd 8 closed, stopped monitoring <POutputDispatcher at 140188251155920 for <Subprocess at 140188251155848 with name start-script in state RUNNING> (stdout)>
2018-08-17 03:34:00,385 INFO exited: start-script (exit status 1; not expected)
2018-08-17 03:34:00,386 DEBG received SIGCLD indicating a child quit
 

 

supervisord.log

 

the problem has been discussed (affects synology users only), see here:-

 

https://lime-technology.com/forums/topic/44109-support-binhex-delugevpn/?do=findComment&amp;comment=674580

 

btw reverting to an older version of dig is a no go, so i will need to investigate possible use of drill instead.

 

Link to comment
3 hours ago, Swoodle said:

Can no longer get to the WebUI after updating. .. . . . . I've tried to read through, change the end point to switz no avail. 

 

ok if you have followed these instructions linked below:-

 

https://lime-technology.com/forums/topic/44109-support-binhex-delugevpn/?do=findComment&amp;comment=676124

 

and its still not working then please follow the procedure below:-

 

https://lime-technology.com/topic/44108-support-binhex-general/?do=findComment&amp;comment=435831

 

Link to comment
11 hours ago, Hoopster said:

 

I had the same problem yesterday after updating the docker.  WebGUI was inaccessible. 

 

I changed the end point to Czech Republic (was on Netherlands), copied in the latest crl.rsa.2048 .pem file from the .zip, deleted supervisord.log, and put the docker into debug mode which restarted the docker.  All was well after that and I have entered and exited the GUI successfully several times since. Since the GUI was accessible after restarting the docker, I took the docker out of debug mode and have had no further issues.

 

I am not saying this is "the solution," just that it seemed to resolve the issue in my case.

 

I have the 4096 cert file presumably because strong certs was enabled.  I don't remember why I enabled this in the first place so dropping back to the 2048 version shouldn't be an issue?  It doesn't look like my strong cert files are being updated when I pull a new version of the docker (i.e. files are from 2017).

 

EDIT: I was able to get this docker working again by doing a clean install and then copying the correct cert files in the openvpn directory.

Edited by betaman
Link to comment

why all of a sudden is the docker not working? this is a real big hassle. Im not that good with linux based OSs and Im finding this extremely difficult to understand. Ive read that previous versions work fine? why cant the current version just work? now a big reason why I use this OS no longer works without completely restructuring the configuration. Now Im totally messed it up and am at my wits end. Please help.972129547_pic1.thumb.jpg.1bd77c3e62e21b6595b9d5f1b046c077.jpg

pic 2.jpg

Link to comment
1 hour ago, XxjonnyxX said:

why all of a sudden is the docker not working? this is a real big hassle. Im not that good with linux based OSs and Im finding this extremely difficult to understand. Ive read that previous versions work fine? why cant the current version just work? now a big reason why I use this OS no longer works without completely restructuring the configuration. Now Im totally messed it up and am at my wits end. Please help.

Edit: Without more info from you it's going to be hard for anyone to determine the problem with your system. See this post for what is needed.

Edited by wgstarks
confusion on my part :D
Link to comment
  you do of course realise that you didn't have a fine working config right?, as in port forwarding was not operational, this will result in low dl speeds and inability to seed.

 

Yeah i realise looking at the logs but i prefer slow vs suddenly NOT working if you get my point. This sort of thing should never ever suddenly lead to the whole docker not working but rather just warn or at least the gui should work with then a warning to the user to correct any issues. Reminds me of my windows days before i moved to osx where at any day you could come in and find stuff not working due to a busted auto update. I hear its still the case with windows 10.

 

My internet business line is so fat(500MBytes/s) i did not even notice it was slow as slow was still fast enough .

Will switch endpoint at some time in the future the proper way as you suggested.

 

Link to comment

I'm having some issues setting up DelugeVPN as the download client in Sonarr (Also Radarr). Whenever I go to test the connection it comes back with:

 

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

 

If I try to use normal Deluge (Not VPN) then it works without issue. I've tried to do some research on the error but I've been unable to figure it out and I'm not sure if the issue is with DelugeVPN or Sonarr at this point. Or if the issue is me being a complete tool. Its a 33 split right now!

 

I've attached an image of my Sonarr download client config and a copy of the log in trace mode. I was going to attach a copy of the supervisord.log but upon inspection there appears to be zero information in it relating to this at all, it just doesn't record any information about the incident. The only log that responds is Sonarr. If you wish I can post a copy of this log also.

sonarr config.png

Sonarr-DelugeVPN-error.txt

Link to comment

Hi.  I installed the docker container and was able to login with the default password and change it.  I was enabled the blocklist plugin, put the URL in it, it grabbed the data and imported the list, then pressed apply and OK.  If I stop and restart the container, the preferences don't save.  I've looked at the core.conf file and did a chmod 666 to it as someone else said in the forums here, but that didn't change anything.  Thoughts?  Thanks for any input.

Link to comment

Thanks for the reply, but the point is, that the preferences are not saving for me, and I'd like to fix that.  Do you have any suggestions for that?

 

Edit: I've tried multiple plugins and none of them are saving, it's not just the blocklist plugin.

 

Edit 2 (Solved):  I've solved my issue.  The problem is that an extension in Chrome is causing the preferences not to be saved.  I tried in firefox and it's working fine.  Thanks.

Edited by zenmak
Solved
Link to comment

<rant> Feels frustrating when the docker just stops working and you realize a week later something isnt working and dont have time for another week to sit in front of the computer to pull up and try to diagnose what's working. I guess getting old means we need 'stuff' to work, there are times when we have ability and interest to spend tinkering but not always. <end rant>

 

I stopped my deluge container until I can get some time to sit and figure out what's wrong. Would be nice to see in bold letters, change xx variable to yy to get things working to minimize effort in diagnosis. Appreciate the effort by binhex and team, guess the pains of growing up.

Edited by htpcnewbie
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.