49 minutes ago, orlando500 said:

Just the latest update broke it.

you know the last update happened 3 1/2 months ago, or were you simply holding off updating for a long time?, no known issues at this time with latest.

 

ok so onto the issue, i would suspect something has changed on your end, check the following and think about what might of been changed at the time the issue started:-

 

1. try different machine running web browser

2. try different browser

3. ensure router/firewall is not blocking (common issue)

4. shutdown wireguard if running on unraid host

5. check vlan is not blocking

6. try going to 'terminal' of container and issue the following command:-

curl http://localhost:8112

 

if you see output then you know the web ui is operational.

7. restart host

8. try resetting deluge, rename /config/core.conf to /config/core.conf.old and then restart the container.

27 minutes ago, Autchirion said:

After seeing a post here, that showed me how to get the complete logfile (and which one it is), I added this, probably this can help to explain why my modem doesn't survive the container.

Any Help welcome, I'm still at a complete loss, I'm currently only downloading ubuntu and this already is disruptive to my modem.

supervisord.log 88.02 kB · 0 downloads

weak hardware is the normal cause for this, your options really are to reduce the load on the modem (you mean router right?) by reducing the number of connections, you could also reduce the load by slowing your dl and ul rates in deluge, this will most probably get you a more stable connection, but in reality your best bet is to replace that router.

12 minutes ago, binhex said:

you know the last update happened 3 1/2 months ago, or were you simply holding off updating for a long time?, no known issues at this time with latest.

 

ok so onto the issue, i would suspect something has changed on your end, check the following and think about what might of been changed at the time the issue started:-

 

1. try different machine running web browser

2. try different browser

3. ensure router/firewall is not blocking (common issue)

4. shutdown wireguard if running on unraid host

5. check vlan is not blocking

6. try going to 'terminal' of container and issue the following command:-

curl http://localhost:8112

 

if you see output then you know the web ui is operational.

7. restart host

8. try going from scratch, you will of course need to put the vpn config files in the correct place.

 

1) same for different machine

2) same for different browser (tried chrome and MS edge)

3) not blocking any local traffic

4)wireguard is off

5) no vlan use

6) sh-5.1# curl http://localhost:8112
curl: (7) Failed to connect to localhost port 8112: Connection refused
sh-5.1# 

7) host is restarted

8 ) yes it seems i need to start from scratch... strange, it would be nice to have some sort of "check the config/problem solving" script :-) i just dont know what to look for in these stops. And yes i know its been a while for the update. This is the reason i dont like to update so often. It tends to break stuff. All other binhex dockers run fine and i update them once a week.

 

edit: btw: the first curl was from container terminal, here is from server terminal:

root@hal:~# curl http://localhost:8112
curl: (56) Recv failure: Connection reset by peer

Edited June 7, 20215 yr by orlando500

6) sh-5.1# curl http://localhost:8112
curl: (7) Failed to connect to localhost port 8112: Connection refused

try https://localhost:8112 it might be that you are using https.
 

edit: btw: the first curl was from container terminal,

this is correct, you wont get through from the host terminal (blocked via iptables).

p.s. thanks for the donation

3 hours ago, binhex said:

try https://localhost:8112 it might be that you are using https.
 
this is correct, you wont get through from the host terminal (blocked via iptables).

p.s. thanks for the donation

 

https gave the same error.  Im trying to reinstall now.

 

ps: you deserve some support for all your hard work. we take for granted all the hours you put down in the binhex dockers. But from time to time i try to show that i care and want to thank you...

3 hours ago, binhex said:

try https://localhost:8112 it might be that you are using https.
 
this is correct, you wont get through from the host terminal (blocked via iptables).

p.s. thanks for the donation

 

Did a reinstall and everything worked like a charm with the same setup. Guess the image had taken a hit in the upgrade or something. Thanks for the help

 

Maybe someone has an idea what's wrong, sorry because probably offtopic:

 

As soon as a torrent is up/downloading my WHOLE internet connection drops in an instant.

Latency up to 500ms or timeout, up/download <1mbit

Happens on all clients, iPhones, iPads, my desktop...

I'm using UniFi-Gear so it should be more than capable to handle the tasks at hand...

 

The only thing I can think of would be to many connections but even the crappiest hardware I've ever used had no problem with the 400-setting in deluge...

18 hours ago, binhex said:

weak hardware is the normal cause for this, your options really are to reduce the load on the modem (you mean router right?) by reducing the number of connections, you could also reduce the load by slowing your dl and ul rates in deluge, this will most probably get you a more stable connection, but in reality your best bet is to replace that router.

Thank you for your answer, as a clarification regarding the router-modem topic. I'm using cable internet, this goes into a device which is provided by my ISP, this can act as a router as well, or just "change" the packets that are comming from the cable to ethernet. I'm using this device merely to do that, it doesn't create a wifi, I can not connect multiple devices to it etc. So all the other stuff (WiFi, DHCP and other services) are done by my router (my own hardware).

As a short explanation what you get from your ISP is a modem-router, but they only call it router, because most people don't care about the difference. Modem (modulator demodulator) de-/modulates the cable (or whatever connection type you use) signal from/to ethernet. The router then provides the packets that are embedded in these signals to the devices in your network. 

My router doesn't have any issues keeping up, that's 100% sure, the device which is provided by my ISP can't keep up, I figured this out with different tries.

 

So, my point is, I used to have 150+ torrents running on qbittorrent (without VPN), but as soon I add one torrent to delugevpn my modem just plainly gives up. Now, why can my modem (of router if you want to) handle 150+ torrents without a vpn, but can't keep up with 1 torrent if I use VPN. I'm not a network expert, I've got only very basic understanding of the ISO-OSI model with TCP/IP. But what I understand VPN is doing, it takes all the packets encrypts them and sends them to a different receiver. This should not generate any additional load on the router, only on the device that runs the VPN. I agree, it might cause a minor increase of traffic by a small one digit percentage, but not significant (1 vs 150+ torrents).

 

So what I'm thinking is, as soon there is a torrent active the openvpn hammers my modem with requests, that it eventual will reject but this will put heavy load on my modem.

 

But I understand this might go beyond what we are handling here, what I'm currently considdering is to use wireshark to record some of the network traffic with delugevpn on, then some with qbittorrent on and one without any of these on and see if there is a major differences in messages. If not, my ISP fucked up the modem-router software and I'm screwed, because changing this usually causes big trouble with my ISP.

30 minutes ago, Autchirion said:

but as soon I add one torrent to delugevpn my modem just plainly gives up. Now, why can my modem (of router if you want to) handle 150+ torrents without a vpn, but can't keep up with 1 torrent if I use VPN. I'm not a network expert, I've got only very basic understanding of the ISO-OSI model with TCP/IP. But what I understand VPN is doing, it takes all the packets encrypts them and sends them to a different receiver. This should not generate any additional load on the router, only on the device that runs the VPN.

the load on your modem will be increased by having to send fully encrypted packets to a remote vpn endpoint, but yeah the load should not be significant as its not doing the encryption, however badly designed firmware can cause issues here, especially if not fully tested with a vpn connection, so i would suspect the combination of mediocre hardware in your modem and the combination of poor firmware is most probably the culprit, perhaps check if there is an firmware update for your modem, or google around the make and model of your modem and see if anybody has a resolution for your issue.

HI, I've finally managed to link Radarr to DelugeVPN however now when the torrents are added, they just remain at 0% downloaded and eventually move to Paused.

Is this a common issue or one that can easily be resolved?

Thanks

3 hours ago, ldog88 said:

HI, I've finally managed to link Radarr to DelugeVPN however now when the torrents are added, they just remain at 0% downloaded and eventually move to Paused.

Post the docker run commands for both containers.

On 6/7/2021 at 8:42 AM, binhex said:

from your log:-

 

2021-06-06 22:52:05 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)

2021-06-06 22:52:05 TLS Error: TLS handshake failed

so its either a issue with connectivity to the vpn endpoint or an issue with their certificate that they issued, try a different endpoint and/or downloading the latest openvpn config files.

Thanks for looking at the log file. I didn't think to go back and look if my config files were still there. 

 

When I toggle the VPN_ENABLED "off" in the edit I am able to access the WEBui, when I turn it back on no access to WEBui.

 

When my appdata/binhex-delugevpn/openvpn folder was empty I dropped in my .conf and .ovpn files from a backup. This got the log file dancing, but I could not get into the WEBui still.

 

I grabbed a fresh .ovpn file from my VPN provider (UDP type) and deleted the previous .conf file. A new .conf file was generated when I restarted the container. Still no luck getting into WEBui and the log file was actively writing. 

 

I also have changed my password with the VPN hoping that might update something on their end for me. Hasn't seemed to, I still have the same scrambled username and password to input into the docker I had been using for nearly a year. 

 

It feels like I am getting closer now. 

2021-06-08 Log File.txt

18 hours ago, binhex said:

the load on your modem will be increased by having to send fully encrypted packets to a remote vpn endpoint, but yeah the load should not be significant as its not doing the encryption, however badly designed firmware can cause issues here, especially if not fully tested with a vpn connection, so i would suspect the combination of mediocre hardware in your modem and the combination of poor firmware is most probably the culprit, perhaps check if there is an firmware update for your modem, or google around the make and model of your modem and see if anybody has a resolution for your issue.

Here is the catch with that, when using the privoxy tunnel of said container with my other PC and checking the speed with speedtest.net I get 260mbit/s down and 51mbit/s up (I've got a 250/50 line, so this is the maximum I can expect). Also I get full speed using the official app on my PC, which is again an argument against a general problem with the modem having issues. But I also received a new version of the router/modem from my provider. I first have to check if I can operate it as a modem, as soon I know this is possible, I'll switch to said modem and hope for the best.

But this is only a thought I'm having right now, as I said I'll look further into it and keep you posted on the topic. So you might be able to help the next person that has the same issue. 🙂

 

One more question, do you plan on using/enabling wireguard for this container? I'm using wireguard for other things a lot and I think it's the supperior protocoll.

3 hours ago, Strats said:

It feels like I am getting closer now. 

authentication failure now, from your log:-

 

2021-06-08 22:22:10,145 DEBG 'start-script' stdout output:
2021-06-08 22:22:10 AUTH: Received control message: AUTH_FAILED

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

2 hours ago, Autchirion said:

do you plan on using/enabling wireguard for this container?

its already implemented, see Q21:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

5 hours ago, binhex said:

its already implemented, see Q21:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

I'm a bloody moron... thank you!

 

also, with the other modem it's working great, unfortunately this modem-router sucks in other terms... 🙂 Thank you for your great support here!

Hi everyone,

 

Yesterday I was playing with HW transcoding settings in Plex that caused me to bounce my machine several times. Since then, I've had almost ~4k of my torrents sitting in "Queued", with just under 2k seeding. I use PIA as my VPN. 

My Queue settings are:

Total - 8000

Download - 4000

Uploading - 6000

 

I have just under 6k torrents total, with 244 on Downloading. Any ideas?

6 hours ago, binhex said:

authentication failure now, from your log:-

 

2021-06-08 22:22:10,145 DEBG 'start-script' stdout output:
2021-06-08 22:22:10 AUTH: Received control message: AUTH_FAILED

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

Thanks, got it going now.

 

My issues likely were:

• old ovpn file, replaced with new one
• didn't wait long enough for new password to update with VPN provider before trying it with the container

Hey Guys,

 

I'm using PIA with the current delugevpn container. It worked fine once, then I rebooted now it isn't working perfectly any more. So, one of my trackers requires that I can be contacted from outside (aka port is forwarded). This tracker reports (which it wasn't before the restart), that I'm not reachable now.

I used https://www.yougetsignal.com/tools/open-ports/ to check if the port is opened, but it isn't. I couldn't find any error message in the log file or anything that would indicate that something went wrong. Also I checked in deluge, the incoming port is exactly set as the same port which is used by the VPN.

 

Anything else I need to check? I already attached a log file, I don't understand what is happening here.

 

I could try fireguard (I would love to use this in future), but I'm not sure if something else is going wrong and I don't want to mess with too much stuff.

 

Thank you in advance,

Autchi

13 minutes ago, Autchirion said:

I used https://www.yougetsignal.com/tools/open-ports/ to check if the port is opened, but it isn't.

did you put in the external ip assigned to you from the vpn provider? (shown in the log), otherwise if using your isp's assigned ip it will show the port closed.

11 minutes ago, binhex said:

did you put in the external ip assigned to you from the vpn provider? (shown in the log), otherwise if using your isp's assigned ip it will show the port closed.

could have pointed that out, sorry. Yes, I did that.

Currently it's:

2021-06-10 14:15:49,273 DEBG 'watchdog-script' stdout output:
[debug] VPN incoming port is 20694
[debug] Deluge incoming port is 20694
[debug] VPN IP is 10.23.112.2
[debug] Deluge IP is 10.23.112.2

feel free to double check.

 

It just fixed itself (at least according to the tracker), I don't know what happened, but it seems like it takes more than half an hour to get the port forwarded... or something else happened. But checking on the website still reports as port is not forwarded.

 

I added the log file where this must have happened. 

supervisord.log

Edited June 10, 20215 yr by Autchirion
fixed itself

10 minutes ago, Autchirion said:

could have pointed that out, sorry. Yes, I did that.

Currently it's:

2021-06-10 14:15:49,273 DEBG 'watchdog-script' stdout output:
[debug] VPN incoming port is 20694
[debug] Deluge incoming port is 20694
[debug] VPN IP is 10.23.112.2
[debug] Deluge IP is 10.23.112.2

feel free to double check.

ahh sorry my bad, looks like i echo out the internal tunnel ip address not the external ip, so for your example above 10.23.112.2 will be internal only, you need the external ip, this can be found by opening terminal for the container and running the command:-

curl ifconfig.io

this will return an ip, copy and paste this into https://www.yougetsignal.com/tools/open-ports/ with the currently assigned port (check log as it can change) and test it, i think you will find its open.

31 minutes ago, binhex said:

ahh sorry my bad, looks like i echo out the internal tunnel ip address not the external ip, so for your example above 10.23.112.2 will be internal only, you need the external ip, this can be found by opening terminal for the container and running the command:-

curl ifconfig.io

this will return an ip, copy and paste this into https://www.yougetsignal.com/tools/open-ports/ with the currently assigned port (check log as it can change) and test it, i think you will find its open.

 

Thank you, that worked out well, so I would assume it's a tracker issue because of the randomly changing port after a reboot of the container.

 

Suggestion: Add the output of the external IP into the log.

Just now, Autchirion said:

Thank you, that worked out well, so I would assume it's a tracker issue because of the randomly changing port after a reboot of the container.

you will get a randomly assigned ip AND a randomly assigned port on reboot, nothing can be done about this for PIA currently as both are dynamic.

 

1 minute ago, Autchirion said:

Suggestion: Add the output of the external IP into the log.

i could do but its another sensitive bit of info that i dont really want to expose in the logs.

Just now, binhex said:

you will get a randomly assigned ip AND a randomly assigned port on reboot, nothing can be done about this for PIA currently as both are dynamic.

 

i could do but its another sensitive bit of info that i dont really want to expose in the logs.

of course, I understand this limitation of PIA, that's up to the tracker admin now... 🙂

 

Ah, that's a good thought to not put it into the log to keep it more private. Thank you for always thinking about our privacy!