Remote connections to beet.bpd from clients on other machines?

[somewhat related to How do I use the BPD plugin to play music from my server?)

i have beets’ bpd server running on a RPI, and i want to connect to
this service remotely via one of the mpc-like clones, controlling the
player,eg from iOS, OSX, etc. Following these helpful
notes

suggest forwarding localhost ports :6600 and :80 to the LAN port :24.
i’m trying to replicate the port forwarding mentioned there that uses (raw) iptables, to use
ufw. below is a picture of the hints and my gufw version.


i must have something wrong, because none of the mpc-like clients i’ve
tried are able to successfully connect to 192.168.1.213:24.

are any of the rest of you using a configuration like this?

Dear @rik,

It would be important that you describe your network topology where your Beets BDP server is running. If it is a regular home network setup then you will have a router which by default (i hope) blocks all incoming network connections. The port forwarding is meant to be configured on your router. What you show above is that you are allowing incoming connections on ports 80 and 6600 on your RPI device but that is not enough if you want to connect to it from remote (that is: from outside of your router). Also, you are talking about connecting to port 24 (hmmmm, that is a reserved port) but I think you got something mixed up - the /24 after the ip address is not a port number but a subnet mask (don’t worry about it). And, typically, from outside of your router, you will need to be using a public ip address and what you are showing there is a private one.

So, there are many components to this issue to be checked and solved before you can make this working. But if you are determined enough, you can do it!

The some first important question is: how is your network configured? Do you have access to your router (it must have a web interface with login/pwd). What is your public ip (https://www.whatismyip.com/ or from your router) and is that ip dynamic or static? Please also supply your full iptables configuration with iptables -L.

hi @jakabadambalazs , thanks for helping me think this thru. you’ve already helped clarify.

pi@raspberrypi:~ $ sudo iptables -L | grep 6600
ufw-user-logging-output  tcp  --  localhost            raspberrypi.attlocal.net  tcp spt:6600 dpt:24
ACCEPT     tcp  --  localhost            raspberrypi.attlocal.net  tcp spt:6600 dpt:24
ufw-user-logging-output  udp  --  localhost            raspberrypi.attlocal.net  udp spt:6600 dpt:24
ACCEPT     udp  --  localhost            raspberrypi.attlocal.net  udp spt:6600 dpt:24
LOG        tcp  --  localhost            raspberrypi.attlocal.net  tcp spt:6600 dpt:24 limit: avg 3/min burst 10 LOG level warning prefix "[UFW ALLOW] "
RETURN     tcp  --  localhost            raspberrypi.attlocal.net  tcp spt:6600 dpt:24
LOG        udp  --  localhost            raspberrypi.attlocal.net  udp spt:6600 dpt:24 limit: avg 3/min burst 10 LOG level warning prefix "[UFW ALLOW] "
RETURN     udp  --  localhost            raspberrypi.attlocal.net  udp spt:6600 dpt:24
pi@raspberrypi:~ $ 

the connections are all meant to be intra-LAN, from (computer, phone) clients within the same 192.* addresses.

and i now think port forwarding is not needed. i just need to open these ports to other addresses? or i maybe just have addressing wrong?

my tests have simply been from various mpd clients (persephone, cyp on OSX, rigelian, MaximumMPD on iOS). most fail, with “can’t connect” or “timeout” errors. cyp acts as if it has an empty database.

do you know of simpler tests? should i get some port-scanning utility to probe the RPI?

Hi @rik,

The iptables command outputs the registered rules divided into three sections:

Chain INPUT (policy DROP)
num  target     prot opt source               destination         
...rules...

Chain FORWARD (policy DROP)
num  target     prot opt source               destination         
...rules...

Chain OUTPUT (policy DROP)
num  target     prot opt source               destination
...rules...

and by grepping the outout you remove those sections. I can sort of guess where your rules belong to but in case of the firewall guesswork is not a good approach. So, pls post the full output. If you add the line numbers like this sudo iptables -L --line-numbers I can more easily point to a specific line.

In the meanwhile here is what I would do to test that everything else works as expected and it is only a matter of configuring your firewall. (Only do this if there is no security risk in accessing your RPI):

  1. backup my iptables config: iptables-save > iptables.rules.txt
  2. clean all rules and reset the default policy to ACCEPT:
iptables -F INPUT
iptables -F OUTPUT
iptables -F FORWARD
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
  1. Now connect to your bdp server from another device on your LAN. At this point if everything works then jump to point 4). If not then you first have to solve the issue with the service (I don’t use bdp so I cannot be of help there).
  2. Assuming all is working now restore your saved iptables config: iptables-restore < iptables.rules.txt

Based on what you say about devices connecting on your LAN, port forwarding is not you case.
If you are struggling with understanding what protocols/ports are necessary to have open you can always use tcpdump (⌐■_■) on your RPI.

PS: I still don’t think port 24 has anything to do with this. Can you point me to the documentation?

EDIT:
I just looked up in the BPD documentation: if you have not changed your default ports you should be accepting incoming connections on ports 6600 and 6601 over TCP protocol. MPD protocol docs.