search

librespot-org / librespot

Open Source Spotify client library
MIT License
4.78k stars 593 forks source link

Did spotify drop mdns support for spotify connect? #281

Closed agrenott closed 5 years ago

agrenott commented 5 years ago

Hi,

I've been trying for days now to use the self discovery of librespot on my local network (not specifying my user account in the configuration). Librespot implements the local discovery via mDNS protocol. However, using wireshark on my windows PC running official spotify client, I see no traffic on port 5353 (except discovery of proxy viq WPAD, which can be disabled in spotify advanced settings). Instead, I can see SSDP traffic, with M-SEARCH query.

I can't find anything confirming this on the web. Does anyone here encounter the same issue, or is able to get some network trace with official spotify connect device to confirm it?

This would mean the whole mDNS part of librespot could be dropped, and should be replaced with SSDP equivalent...

Thanks, Aurelien

devgianlu commented 5 years ago

Which version of the Spotify client are you running?

On Mon, Dec 10, 2018, 21:12 agrenott <notifications@github.com wrote:

Hi,

I've been trying for days now to use the self discovery of librespot on my local network (not specifying my user account in the configuration). Librespot implements the local discovery via mDNS protocol. However, using wireshark on my windows PC running official spotify client, I see no traffic on port 5353 (except discovery of proxy viq WPAD, which can be disabled in spotify advanced settings). Instead, I can see SSDP traffic, with M-SEARCH query.

I can't find anything confirming this on the web. Does anyone here encounter the same issue, or is able to get some network trace with official spotify connect device to confirm it?

This would mean the whole mDNS part of librespot could be dropped, and should be replaced with SSDP equivalent...

Thanks, Aurelien

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/librespot-org/librespot/issues/281, or mute the thread https://github.com/notifications/unsubscribe-auth/AOI-8aP9FbVAL3R4XwG0MmdHB7398VV6ks5u3sBJgaJpZM4ZMGDl .

agrenott commented 5 years ago

On windows: 1.0.95.289.g342899da. And same with android client 8.4.83.625.

devgianlu commented 5 years ago

~I've managed to updated the Android client and it doesn't detect librespot-java anymore, I am waiting for the Windows update.~ That was an issue on my side (librespot-org/librespot-java#32).

awiouy commented 5 years ago

Have you tried building librespot with with-dns-sd, see https://github.com/librespot-org/librespot/wiki/Compiling

agrenott commented 5 years ago

Yes, but I'm still stuck on a libsystemd.so not found at link time (while it's there and I've added the path with ld -L argument) - using raspotify cross-compilation docker image tweaked a bit. But anyway, as I can't even see any mDNS packet going out of the official client, I don't think it would make any difference. Or are you saying avahi-daemon would handle SSDP requests as well for librespot?

sashahilton00 commented 5 years ago

I'm now running 1.0.95.289.g342899da on OS X, and librespot is still working fine. Looks like we'll have to wait for iOS/Android versions to update a few and watch for changes.

devgianlu commented 5 years ago

1.0.95.289.g342899da is also fine on Windows.

agrenott commented 5 years ago

What do you mean by "fine"? Do you see mDNS queries sent from the windows client? Are you able to use spotify connect without specifying user/password when starting librespot?

devgianlu commented 5 years ago

I've not checked the traffic between the clients, but Zeroconf works fine with librespot-java.

If you see some SSDP, maybe they are slowly switching to it, I'll check.

devgianlu commented 5 years ago

@agrenott There are a lot of SSDP packets being sent on my network, but that's normal. I have not seen anything related to Spotify, could you point out which type of service (NT header in the NOTIFY request) is used?

agrenott commented 5 years ago

Here is the SSDP query from spotify client on windows (sent each time you display the list of available devices):

0000   01 00 5e 7f ff fa 70 85 c2 43 63 26 08 00 45 00   ..^.ÿúp.ÂCc&..E.
0010   00 99 26 4d 00 00 01 11 00 00 c0 a8 00 03 ef ff   ..&M......À¨..ïÿ
0020   ff fa df f0 07 6c 00 85 39 58 4d 2d 53 45 41 52   ÿúßð.l..9XM-SEAR
0030   43 48 20 2a 20 48 54 54 50 2f 31 2e 31 0d 0a 48   CH * HTTP/1.1..H
0040   4f 53 54 3a 20 32 33 39 2e 32 35 35 2e 32 35 35   OST: 239.255.255
0050   2e 32 35 30 3a 31 39 30 30 0d 0a 4d 41 4e 3a 20   .250:1900..MAN: 
0060   22 73 73 64 70 3a 64 69 73 63 6f 76 65 72 22 0d   "ssdp:discover".
0070   0a 4d 58 3a 20 31 0d 0a 53 54 3a 20 75 72 6e 3a   .MX: 1..ST: urn:
0080   64 69 61 6c 2d 6d 75 6c 74 69 73 63 72 65 65 6e   dial-multiscreen
0090   2d 6f 72 67 3a 73 65 72 76 69 63 65 3a 64 69 61   -org:service:dia
00a0   6c 3a 31 0d 0a 0d 0a                              l:1....

Or a bit more readable view (from wireshark):

Internet Protocol Version 4, Src: 192.168.0.3, Dst: 239.255.255.250
User Datagram Protocol, Src Port: 57328, Dst Port: 1900
Simple Service Discovery Protocol
    M-SEARCH * HTTP/1.1\r\n
        [Expert Info (Chat/Sequence): M-SEARCH * HTTP/1.1\r\n]
        Request Method: M-SEARCH
        Request URI: *
        Request Version: HTTP/1.1
    HOST: 239.255.255.250:1900\r\n
    MAN: "ssdp:discover"\r\n
    MX: 1\r\n
    ST: urn:dial-multiscreen-org:service:dial:1\r\n
    \r\n
    [Full request URI: http://239.255.255.250:1900*]
    [HTTP request 2/2]
    [Prev request in frame: 40]
devgianlu commented 5 years ago

dial-multiscreen-org doesn't belong to Spotify.

DIAL—for DIscovery And Launch—is a simple protocol that second-screen devices can use to discover and launch apps on first-screen devices.

agrenott commented 5 years ago

And still, I'm almost sure those come from spotify client, as I capture them only when it's started. And the string "ST: urn:dial-multiscreen-org:service:dial:1" appears inside the binary (looking with process explorer).

agrenott commented 5 years ago

Arg, got it. Looks like my spotify client correctly sends the mDNS requests, but on an invalid network interface, so it never reaches the "real" network...

devgianlu commented 5 years ago

That is indeed true, but I cannot force Spotify to use SSDP between two clients. This means that they are using both mDNS and SSDP. I'll try with my smart TV.

Update: My TV is indeed dispatching a service with type urn:dial-multiscreen-org:service:dial:1.

sashahilton00 commented 5 years ago

Those SSDP requests are likely to be from the Cast SDK that is integrated into the Spotify clients. Whilst I can't be certain, I would say that nothing has changed w/ regards to the mDNS discovery.

agrenott commented 5 years ago

I guess we can close the issue, as mDNS support is not dropped, just mis-behaving when several network interfaces are available (in my case using Hyper-V internal interface). BTW, seems the android spotify client isn't using mDNS (or has similar issue than the windows one).