Electorrent icon indicating copy to clipboard operation
Electorrent copied to clipboard

Unable to connect to Deluge server when SSL is enabled

Open YoonAddicting opened this issue 5 years ago • 5 comments

Client:

  • [ ] µTorrent
  • [ ] qBittorrent
  • [ ] Transmission
  • [ ] rTorrent
  • [x] Deluge

Client Version: 1.3.15

Operating System: Host: FreeBSD (FreeNAS 11.2), Client: Windows 10 x64

Application Version: 2.6

Description: I am unable to setup the Deluge connection, neither with the builtin localclient user, nor with a brand new user, which is working through the Web-UI and a thin-client on the same windows client as Electorrent. I've tried both with the local IP, remote IP and web address, both Web-UI port and deluged daemon port, https and http (https is on and forced on the server, with a valid Let's Encrypt certificate), and no combination of any of these seems to be working. Currently the Web-UI is accessible through https://[localIP]:10276 and the daemon is running on 58846. I'm kinda lost at where I should be looking exactly for what the different parameters should be, if they aren't the correct ones.

The exact error I am receiving is: Connection problem The connection could not be established

(I think Deluge also needs to be added to the default issue formula.)

YoonAddicting avatar Jan 29 '19 00:01 YoonAddicting

If you are able to open the developer console you might get more info on the error. The connection could not be established is just a generic error for when the type of error is not recognised. Deluge is a bit different in the way that the web UI can serve multiple daemons. I suspect you only have one daemon running? If you have any other information on how I can recreate your setup please let me know. I have personally tested with https://github.com/linuxserver/docker-deluge. I will also add the Deluge option to the issue template.

tympanix avatar Jan 29 '19 00:01 tympanix

Attached here is an image of what the developer console says. image

I'm running a jail with Deluge on FreeNAS, running as the user nobody (UID: 65534). When connecting to the Web-UI on port 10276 for the first time it asks for a password for the Web-UI, no username however. After then I can select which daemon I'd like to connect to, where I'd connect to the one running on 127.0.0.1:58846. This daemon is running with the localclient username inside Deluge's auth file, no password is required to select this one though, after the initial password to connect to the Web-UI. Inside the web.conf file on the server, it shows the session login as "admin". As mentioned before, the daemon is enforcing SSL on Deluge. This is done through a Let's Encrypt certificate issued for the domain it's available through.

UPDATE Mid-ways through writing this: I tried disabling SSL in deluge, so it would connect over HTTP, and boom it worked, Filling in the IP, protocol, password (Web-UI password), client program and port (Web-UI port). So no username for Deluge. Now the next question would be, why doesn't it want to connect over SSL. I'm leaving what I already have written above, in case you need it for troubleshooting SSL.

YoonAddicting avatar Jan 29 '19 00:01 YoonAddicting

Great debugging work. So we are down to this being an SSL problem. I must admit I did not test Deluge with SSL just yet. Just to make sure, even though it says Invalid password in the console, I expect you to use the exact same settings (e.i. same password etc.), hence this error message is probably bogus?

tympanix avatar Jan 29 '19 01:01 tympanix

Yup, the password is the same (and correct), just did a sanity check to be sure, so the error message should be unrelated. The files it refers to differ between selecting HTTP and HTTPS in the setup, but both simply return Invalid password, when SSL is enabled in Deluge. I've attached a picture of the console in both cases, HTTPS on the top. image

YoonAddicting avatar Jan 29 '19 01:01 YoonAddicting

The error is thrown from here i both cases: https://github.com/tympanix/node-deluge/blob/b60695055f5991e06369d04ad1b2f2a798760ea0/index.js#L67

Some of the files are only different because HTTPS uses a different implementation underneath. From the implementation I can see that the Invalid password error is thrown prematurely, so something completely different may be wrong. You can set a breakpoint at the line which i linked in the developer console to check it out in detail if you wish. If not, I will get around to it myself at some point 👍

tympanix avatar Jan 29 '19 02:01 tympanix