[GTALUG] War Story: debugging remote port access

[Michael Galea]

On 2021-03-20 12:37 p.m., Giles Orr via talk wrote:
> A couple quick details:
> - I believe the TLUG list was down: I sent a message 12 March which
> didn't appear, and GMail eventually informed me it couldn't deliver
> it.  Two days later it told me it had been trying all along and had
> given up (I emailed Alex and Scott)
> - I'm borrowing Hugh's "War Story" format ... remember, imitation is
> the sincerest form of flattery
> 
> This is the problem I emailed the list about, but I've now solved it.
> It's slightly embarrassing, but may be helpful to others.
> 
> I have a local Samba and MPD server running on a Raspberry Pi 2.  This
> has run far better than I had expected for nearly two years.  But
> because of the USB2 ports on the Pi 2, data transfers to and from it
> are slow.  I configured a Pi 4 as its replacement, but I couldn't
> finish because after I installed MPD I couldn't access it remotely.
> MPD is the "Music Player Daemon", but the only important part of this
> is it offers access on port 6600.  On the Pi 2 (which has the older
> GUI Raspbian on it), I just installed MPD and it worked - according to
> my notes.  I didn't bother with a firewall.
> 
> On the new machine (Pi 4 with USB3 and Raspberry Pi OS Lite) with MPD
> running, I could access MPD locally with:
> 
>      $ mpc status
>      volume: n/a   repeat: off   random: off   single: off   consume: off
> 
> 'mpc' is the command line client for MPD, and the response you see
> above is the correct one when MPD is idle.  But as soon as I changed
> to pseudo-remote, or actually remote:
> 
>      $ mpc --host=pi44.local status
>      mpd error: Connection refused
> 
> That's without a firewall.  I thought perhaps the new Raspberry Pi OS
> Lite might have helpfully provided some iptables/netfilter rules, and
> I figured UFW would help:
> 
>      # apt install ufw
>      # ufw enable
>      # ufw allow 6600
> 
> This changed nothing about the behaviour of 'mpc' (although it did
> break Samba ... fixed by opening ports 137, 138, 139, and 445).  I
> dragged out 'telnet' to connect to the local port: all that did was
> prove that I can access MPD locally but not remotely (MPD responds "OK
> MPD 0.21.4" when you're able to connect).
> 
>       -----
> 
> Finally I figured it out.  When I told a co-worker, he got it right
> away, so I suspect many of you will have too.  I said above that it
> "just worked" on the original Pi, but I suspect that's not true.  I
> take notes when I install software, but I failed to note one change
> I'm fairly sure I made ...
> 
> What I finally remembered is that almost any service can be configured
> to listen to "localhost" only.  Remembering that, I found the single
> critical line in /etc/mpd.conf:
> 
>      bind_to_address  "localhost"
> 
> I compared that to the older Pi, which says:
> 
>      bind_to_address  "0.0.0.0"
> 
> For those not aware, "0.0.0.0" is short for "listen on all
> interfaces," while "localhost" reasonably enough means "listen only to
> connections coming from the local machine."  This is a common thing in
> servers and I should have remembered sooner.  Restarted MPD and all is
> good.  At least I have a firewall now ...
> 
Hi Giles,
I also use mpd for playing music on a few pi 2s around the house. One is
on Ethernet and the other wireless. Indeed, my Pi's bind to localhost.
I find the performance to be very good, but I nfs mount my music
collection instead of keeping it local.
The only problem I have encountered is that if mpd starts before nfs 
mounts, it doesn't see the collection. I solve that by hanging fire in
rc.local until nfs mount, delaying mpd.
I use the android mpdroid app, which is great at queuing up music.
I also use the replaygain feature of mpd, which obeys mp3 IDv3 tags
in music to normalize the volume of tracks in an album.

-- 
Michael Galea