Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

librespot and firewall ports #89

Open
giannello opened this issue Jul 5, 2016 · 3 comments
Open

librespot and firewall ports #89

giannello opened this issue Jul 5, 2016 · 3 comments

Comments

@giannello
Copy link

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?

@plietar
Copy link
Owner

plietar commented Jul 5, 2016

(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 !

@plietar
Copy link
Owner

plietar commented Jul 5, 2016

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.

@giannello
Copy link
Author

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 :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants