[GH-ISSUE #33] librespot and firewall ports

kerem commented

2026-02-27 19:28:22 +03:00

Owner

Originally created by @sashahilton00 on GitHub (Jan 29, 2018).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/33

Issue by giannello
Tuesday Jul 05, 2016 at 17:17 GMT
Originally opened as https://github.com/plietar/librespot/issues/89

My laptop/mobile phone and my raspberrypi are connected to separate subnets.
After starting librespot I can see that the entries are published via mdns

user@host:~$ avahi-browse --all --resolve
+ wlp3s0 IPv6 raspberrypi                                   _spotify-connect._tcp local
+ wlp3s0 IPv4 raspberrypi                                   _spotify-connect._tcp local
= wlp3s0 IPv4 raspberrypi                                   _spotify-connect._tcp local
   hostname = [raspberrypi.local]
   address = [XXX.XXX.XXX.XXX]
   port = [38143]
   txt = ["CPath=/" "VERSION=1.0"]

If I try to connect from my laptop to XXX.XXX.XXX.XXX:38143 I get a 404, and in the console where librespot is running I can see the message

DEBUG:librespot::authentication::discovery: Get "/" {}

When I start Spotify, I can't see the librespot device name in the list of available Spotify Connect devices.

The firewall rules allow hosts in the LAN to connect to every tcp/udp port of all the devices in the network with the raspberrypi, but not the other way around. Is there any communication happening from librespot to the spotify app that requires ports to be opened?

Originally created by @sashahilton00 on GitHub (Jan 29, 2018). Original GitHub issue: https://github.com/librespot-org/librespot/issues/33 <a href="https://github.com/giannello"><img src="https://avatars0.githubusercontent.com/u/551789?v=4" align="left" width="96" height="96" hspace="10"></img></a> **Issue by [giannello](https://github.com/giannello)** _Tuesday Jul 05, 2016 at 17:17 GMT_ _Originally opened as https://github.com/plietar/librespot/issues/89_ ---- My laptop/mobile phone and my raspberrypi are connected to separate subnets. After starting librespot I can see that the entries are published via mdns ``` user@host:~$ avahi-browse --all --resolve + wlp3s0 IPv6 raspberrypi _spotify-connect._tcp local + wlp3s0 IPv4 raspberrypi _spotify-connect._tcp local = wlp3s0 IPv4 raspberrypi _spotify-connect._tcp local hostname = [raspberrypi.local] address = [XXX.XXX.XXX.XXX] port = [38143] txt = ["CPath=/" "VERSION=1.0"] ``` If I try to connect from my laptop to XXX.XXX.XXX.XXX:38143 I get a 404, and in the console where librespot is running I can see the message ``` DEBUG:librespot::authentication::discovery: Get "/" {} ``` When I start Spotify, I can't see the librespot device name in the list of available Spotify Connect devices. The firewall rules allow hosts in the LAN to connect to every tcp/udp port of all the devices in the network with the raspberrypi, but not the other way around. Is there any communication happening from librespot to the spotify app that requires ports to be opened?

kerem

2026-02-27 19:28:22 +03:00

closed this issue
added the
help wanted

imported
labels

kerem commented

2026-02-27 19:28:23 +03:00

Author

Owner

@sashahilton00 commented on GitHub (Jan 29, 2018):

Comment by plietar
Tuesday Jul 05, 2016 at 18:23 GMT

(Just to confirm, does non-discovery authentication work ?)

The 404 is normal, does http://XXX.XXX.XXX.XXX:38143/?action=getInfo work ?

Here's my educated guess at the issue.
Discovery uses mDNS, which normally relies on multicast UDP on port 5353.

However Spotify has it's own implementation which uses unicast instead (if a Spotify engineer reads this, fyi this goes against the RFC)

Your router is probably letting multicast through but not unicast, which explains why avahi-browse works.

I don't think the client uses a fixed UDP port to receive packets, though you could fire up wireshark to check.

Does your firewall let you filter packets by source IP/port ?
Port 5353 from the Pi is where the packets come from.

Let me know if this helps !

@sashahilton00 commented on GitHub (Jan 29, 2018): <a href="https://github.com/plietar"><img src="https://avatars0.githubusercontent.com/u/1489775?v=4" align="left" width="48" height="48" hspace="10"></img></a> **Comment by [plietar](https://github.com/plietar)** _Tuesday Jul 05, 2016 at 18:23 GMT_ ---- (Just to confirm, does non-discovery authentication work ?) The 404 is normal, does `http://XXX.XXX.XXX.XXX:38143/?action=getInfo` work ? Here's my educated guess at the issue. Discovery uses mDNS, which normally relies on multicast UDP on port 5353. However Spotify has it's own implementation which uses unicast instead (if a Spotify engineer reads this, fyi this goes against the RFC) Your router is probably letting multicast through but not unicast, which explains why avahi-browse works. I don't think the client uses a fixed UDP port to receive packets, though you could fire up wireshark to check. Does your firewall let you filter packets by source IP/port ? Port 5353 from the Pi is where the packets come from. Let me know if this helps !

kerem commented

2026-02-27 19:28:23 +03:00

Author

Owner

@sashahilton00 commented on GitHub (Jan 29, 2018):

Comment by plietar
Tuesday Jul 05, 2016 at 18:29 GMT

Do you have access to an iOS device? I think Spotify uses Apple's implementation of mDNS on there, which appropriately uses multicast. If it works it would confirm my suspicions.

@sashahilton00 commented on GitHub (Jan 29, 2018): <a href="https://github.com/plietar"><img src="https://avatars0.githubusercontent.com/u/1489775?v=4" align="left" width="48" height="48" hspace="10"></img></a> **Comment by [plietar](https://github.com/plietar)** _Tuesday Jul 05, 2016 at 18:29 GMT_ ---- Do you have access to an iOS device? I think Spotify uses Apple's implementation of mDNS on there, which appropriately uses multicast. If it works it would confirm my suspicions.

kerem commented

2026-02-27 19:28:23 +03:00

Author

Owner

@sashahilton00 commented on GitHub (Jan 29, 2018):

Comment by giannello
Tuesday Jul 05, 2016 at 19:02 GMT

Non-discovery auth: not tested, will give it a try.
The 404 doesn't bother me that much, was just a way to confirm that librespotify is receiving and responding to packets coming from the LAN, and it does.

The firewall allows all UDP packets with destination port 5353 to flow in both directions. I don't have an iOS device to verify, will try to get my hands on one of them in the next days.
Keep in mind that, using separate subnets, the firewall has avahi-daemon working as reflector.

I'll run some more tests to try to pinpoint the issue. In the meantime I just moved the raspberrypi to the LAN and everything works fine - thanks for this amazing piece of software :)

@sashahilton00 commented on GitHub (Jan 29, 2018): <a href="https://github.com/giannello"><img src="https://avatars0.githubusercontent.com/u/551789?v=4" align="left" width="48" height="48" hspace="10"></img></a> **Comment by [giannello](https://github.com/giannello)** _Tuesday Jul 05, 2016 at 19:02 GMT_ ---- Non-discovery auth: not tested, will give it a try. The 404 doesn't bother me that much, was just a way to confirm that librespotify is receiving and responding to packets coming from the LAN, and it does. The firewall allows all UDP packets with destination port 5353 to flow in both directions. I don't have an iOS device to verify, will try to get my hands on one of them in the next days. Keep in mind that, using separate subnets, the firewall has avahi-daemon working as reflector. I'll run some more tests to try to pinpoint the issue. In the meantime I just moved the raspberrypi to the LAN and everything works fine - thanks for this amazing piece of software :)

kerem commented

2026-02-27 19:28:23 +03:00

Author

Owner

@ComlOnline commented on GitHub (Jan 31, 2018):

@giannello Did you get anywhere with this?

@ComlOnline commented on GitHub (Jan 31, 2018): @giannello Did you get anywhere with this?

kerem commented

2026-02-27 19:28:23 +03:00

Author

Owner

@ComlOnline commented on GitHub (Feb 5, 2018):

Since the zero-config port addition and the fact that this is an environment issue, I'm going to close this. If you need any more help let us know.

@ComlOnline commented on GitHub (Feb 5, 2018): Since the zero-config port addition and the fact that this is an environment issue, I'm going to close this. If you need any more help let us know.

kerem referenced this issue

2026-02-27 19:28:33 +03:00

[GH-ISSUE #65] Problems with username and special characters #52

Rows
Columns

[GH-ISSUE #33] librespot and firewall ports #23