War Story: debugging remote port access
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 ... -- Giles https://www.gilesorr.com/ gilesorr@gmail.com
Thanks for the port war story. I've learned that something like netstat -na | grep -w LISTEN often helps me discover/confirm port problems. And having a telnet client (or nc) on another machine, often provides much more specific answers than a web browser or an application client (which often say "something went wrong" with no further details). Cheers John
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
On 2021-03-22 12:53 a.m., Michael Galea via talk wrote:
The only problem I have encountered is that if mpd starts before nfs mounts, it doesn't see the collection.
Doesn't the mpd systemd service wait for network? It did the last time I installed it on a Raspberry Pi for an audio project. cheers, Stewart
On 2021-03-22 8:09 a.m., Stewart C. Russell via talk wrote:
On 2021-03-22 12:53 a.m., Michael Galea via talk wrote:
The only problem I have encountered is that if mpd starts before nfs mounts, it doesn't see the collection.
Doesn't the mpd systemd service wait for network? It did the last time I installed it on a Raspberry Pi for an audio project.
cheers, Stewart --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
That, unfortunately, has not been my experience. I am on the 0.19.1-1.1 version, which I installed in 2016 from raspian. Maybe things have improved since then in other mainline distros. How would mpd know to wait? The config just specifies the hard path that mpd uses to read audio files from. It would have to know when nfs actually mounts. Finally, my rc.local approach also incorporates amixer calls to set the volume on startup. I too often found myself having to manually sign on and set the volume manually after upgrades. No longer. -- Michael Galea
On Mon, Mar 22, 2021 at 10:26 AM Michael Galea via talk <talk@gtalug.org> wrote:
On 2021-03-22 8:09 a.m., Stewart C. Russell via talk wrote:
On 2021-03-22 12:53 a.m., Michael Galea via talk wrote:
The only problem I have encountered is that if mpd starts before nfs mounts, it doesn't see the collection.
Doesn't the mpd systemd service wait for network? It did the last time I installed it on a Raspberry Pi for an audio project.
cheers, Stewart --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
That, unfortunately, has not been my experience. I am on the 0.19.1-1.1 version, which I installed in 2016 from raspian. Maybe things have improved since then in other mainline distros.
How would mpd know to wait? The config just specifies the hard path that mpd uses to read audio files from. It would have to know when nfs actually mounts.
systemd should be able to take care of this for you. Just set a dependency on the mount itself and it should magically happen. Dhaval
participants (6)
-
Dhaval Giani -
Giles Orr -
John Sellens -
lsorense＠csclub.uwaterloo.ca -
Michael Galea -
Stewart C. Russell