Unable to connect

[barbequesauce]

Hi there -

Running transmission-daemon 2.93 on raspbian jessie (ip 10.0.1.201), with rpc whitelist and rpc host whitelist enabled. My macOS desktop (ip 10.0.1.17) is unable to connect to the daemon using transgui 5.15.4. Is there a log file I can check to see why it's not connecting?

For reference, here's my daemon's rpc settings.

    "rpc-authentication-required": false,
    "rpc-bind-address": "10.0.1.201",
    "rpc-enabled": true,
    "rpc-host-whitelist": "torrenter,*.local",
    "rpc-host-whitelist-enabled": true,
    "rpc-password": "{cca7b4e7b259ce47caab1ef06dca800f996f8086LiVd20kf",
    "rpc-port": 9091,
    "rpc-url": "/transmission/",
    "rpc-username": "patrick",
    "rpc-whitelist": "127.0.0.1,10.0.1.*",
    "rpc-whitelist-enabled": true,

[antekgla]

What is the error TransGUI report?

[barbequesauce]

At first it says "Connecting to daemon..." in the bottom left. After a while it returns "Connection timed out".

[antekgla]

Can you connect with the WebUI?

[barbequesauce]

Yes.

[antekgla]

I can reproduce your problem with my daemon 2.84 in linux.
I have rpc-enable false and whitelist-enable true and TransGUI connect without a problem.

Please dont be offended with this question because this happens to me in a Raspberry Pi with Transmission daemon. I was editing the wrong settings.json
I was editing settings.json in /etc/transmission-daemon/settings.json and that is wrong...
The correct settings.json to edit is: /home/pi/.config/transmission-daemon/settings.json

[barbequesauce]

No offense taken...

pi@raspi:/ $ sudo find / | grep -i settings.json
/mnt/sda/transmission.old/settings.json
/mnt/sda/transmission/settings.json
pi@raspi:/ $ 

[antekgla]

Maybe you can stop transmission-daemon and run it with --logfile command:

transmission-daemon --logfile /your/path/to/transmission.log

just be sure the ownership and permissions of /your/path/to/ directory is set correctly.

[barbequesauce]

not sure what you're looking for here? I already hardcode the log path in my startup script. How would that impact transgui?

pi@raspi:/mnt/sda/transmission $ ps auxwww | grep -i transmi
debian-+  4793 18.0  0.5 106476  5672 ?        Ssl  Apr19 1035:04 /usr/local/bin/transmission-daemon --config-dir /mnt/sda/transmission --bind-address-ipv4 10.56.10.6 --logfile /mnt/sda/transmission/daemon.log

[barbequesauce]

I got adventurous today and set the username & password in settings.json (as well as flipped authentication required to true - all while transmission-daemon wasnt running). I have no problem connecting with the transmission-remote command line tool, only the gui...

[barbequesauce]

Finally got it working... with a dotted IP in the remote host field. Switch back to hostname (raspi.local) and it times out.

tremc has no problem on the same client machine hitting the same daemon with hostname, so it's not name resolution at the machine level.

[b-]

This bug/issue still exists. Please reopen this issue, or add a “wontfix” label with an explanation why.

[jpegxguy]

#1186, #1127 (this) and #1137 are known duplicates. shouldn't only one be left open (possibly the oldest, this one)

[PeterDaveHello]

Agree, thanks @jpegxguy !

[spanevin]

I have my own dns server which servers my local zone (available inside my local network only).
Let's say the machine where transmission-daemon listens for clients is named server.mynetwork

I use transgui from a windows 10 machine inside the same network.
The problem is that after reboot of this machine, transgui can't resolve server.mynetwork (it shows "Host not found" error) for a few minutes. After 3-5 minutes of connection attempts everything starts working normally.

While it doesn't work, I can successfully ping server.mynetwork from a console. Also other applications which use server.mynetwork (like jabber client) can connect to it successfully. So, dns resolution in OS works correctly, the problem is inside transgui only.

Is it the same problem which is discussed here?

[petetum]

While I have no solution for the actual issue I do have a workaround.

And before you say it... Yes, it should work without workarounds but until it's fixed at least there is an alternative way.

In a nutshell.. register a dynamic DNS online, update it on the machine that hosts the transmission-deamon with the local IP address, then enter the dynamic dns hostname in the GUI.

1. Get a domain.

Go to duckdns.org
You won't need to register an account, just log in with your github.
Register a domain (for example YOURDOMAIN.DUCKDNS.ORG)

2. On your linux server create a script.

The following works on Ubuntu 20.04.5 LTS. For other systems you need to do your own research.

mkdir ~/duckdns
touch ~/duckdns/duck.sh
chmod 700 ~/duckdns/duck.sh

Replace YOURDOMAIN with the one you registered and replace the token (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx) with yours.

echo "echo url=\"https://www.duckdns.org/update?domains=yourdomain.duckdns.org&token=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx&ip=\"\$(hostname -i | awk '{print $1}') | curl -k -o ~/duckdns/duck.log -K -" > duck.sh

3. Schedule the update.

This will add the duck.sh script we made to the job scheduler and it will run every 5 minutes.

(crontab -l && echo "*/5 * * * * ~/duckdns/duck.sh >/dev/null 2>&1") | crontab -

4. Final step in Transmission Remote GUI

Open Transmission remote GUI and connect to the domain you created in step 1.
Enjoy!

[spanevin]

While I have no solution for the actual issue I do have a workaround.

...
Open Transmission remote GUI and connect to the domain you created in step 1. Enjoy!

Much easier is to just add a line into a hosts file... it's usually not a dynamic IP on a transmission-daemon machine, if it's available through local DNS... I believe it's really rare case when DNS and DHCP are different machines in a home network, or the transmission-daemon machine has dynamic IP...