I've got an rsync daemon running on an android phone. I just want to netcat the rsync port on the phone (configured on 1873), to verify the daemon is up and listening to the port, but strangely the netcat attempt is rejected.

Rsync is working fine, it's syncing files between the phone and Ubuntu box, so there is no firewall or any other network issue blocking traffic.

Rsync daemon is listening on the port:

cepheus:/ $ netstat -ltnp 2> /dev/null | grep 1873
tcp        0      0*               LISTEN      2992/rsync

So why is the connection refused?

$ nc -zv 1873
nc: connect to port 1873 (tcp) failed: Connection refused

The below is just for additional background, I hope it doesn't muddy the waters. My expectation is that if a tcp port is in "listening" mode, netcat -zv should succeed given no firewall/network issues.

The rsync daemon is started via adb like so:

adb -s shell -t '/data/local/tmp/rsync --daemon --no-detach --config=/data/local/tmp/rsyncd.conf --log-file=/proc/self/fd/2'

And the local port 6010 on my ubuntu box is port forwarded to 1873 on the phone.

$ adb forward --list tcp:6010 tcp:1873

The check on the adb port works fine for instance.

$ nc -zv 5555
Connection to 5555 port [tcp/*] succeeded!


$ nc -zv localhost 6010
nc: connect to localhost port 6010 (tcp) failed: Connection refused
Connection to localhost 6010 port [tcp/*] succeeded!

The connection attempt does actually succeed as verified in the daemon logs when setting the destination ip to localhost. The problem is that nc outputs exactly the same two lines when the daemon is down, and port closed.

Whilst Tom's answer does work, I'd rather not have the daemon listening on

I've tried setting the source port to local rsync port, but it just results in a bind error when using or Connection refused when setting it to internal ip address of the Ubuntu box:

$ nc -zv 1873 -s -p 6010
nc: bind failed: Address already in use

1 Answer 1


Looks like it's listening on only. You probably need to specify (or as the address (in rsyncd.conf or with the command-line option).

  • Thanks, changing it to resolved the issue.
    – Maikol
    Dec 11, 2019 at 21:56
  • However, is it the case that leaving the daemon to listen on is less secure as any connection including those outside the lan can now be accepted? Any idea how the port forward allowed the daemon to see the incoming connection on the loopback interface adapter eventhough the connection didn't originate locally?
    – Maikol
    Dec 11, 2019 at 22:17
  • I don't know what you want exactly to be honest. Either way you are exposing the daemon. If you prefer the adb way (so that you don't need to adjust the address all the time or whatever reason), it is working as well
    – Tom Yan
    Dec 12, 2019 at 2:01
  • I suppose adb do it with some sort tcp tunnel (everything is encapsulated and sent to the adb port to the adb daemon whatsoever).
    – Tom Yan
    Dec 12, 2019 at 2:06
  • as any connection including those outside the lan can now be accepted nope, what can actually reach it still depends on the network it is connected to.
    – Tom Yan
    Dec 12, 2019 at 2:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.