25

I'm new to inspecting packets with Wireshark so this might be something very stupid on my part. That said, I don't really understand the transaction between my computer and my Roku.

17  1.129097    192.168.1.70    192.168.1.64    HTTP    248 GET /dial/com.spotify.Spotify.TVv2 HTTP/1.1

My computer is 70 and my Roku is 64.

This is the entire HTTP follow:

Client

GET /dial/com.spotify.Spotify.TVv2 HTTP/1.1
Connection: keep-alive
Accept-Encoding: gzip
Keep-Alive: 0
Host: 192.168.1.64:8060
User-Agent: Spotify/109800078 OSX/0 (iMac18,1)

Server

HTTP/1.1 404 Not Found
Server: Roku UPnP/1.0 MiniUPnPd/1.4
Content-Length: 0

I don't have anything related to Roku installed on my computer but I do have Spotify running.

will
  • 343
  • 3
  • 6
  • There is something inconsistent about the output you provided. The summary of the packet doesn't specify port numbers, but given that it says `HTTP` I'd assume the destination port is 80. However the request sent by the client says `Host: 192.168.1.64:8060` which has a different port number. Either the client is sending requests that are inconsistent, or you left out some potentially relevant information. – kasperd Feb 05 '19 at 11:00
  • 9
    @kasperd HTTP doesn't _have_ to be served on port 80, and I'd actually be rather surprised if Spotify took control of port 80 for its API. I think we can safely say that the Wireshark output just doesn't show us the port numbers. – Lightness Races in Orbit Feb 05 '19 at 11:22
  • 2
    @kasperd [Roku's control protocol](https://sdkdocs.roku.com/display/sdkdoc/External+Control+API) operates via REST on 8060 – user71659 Feb 05 '19 at 19:08
  • 1
    @LightnessRacesinOrbit That's not my point. My point is that Wireshark decides to decode the traffic as HTTP and shows it as HTTP rather than showing it as TCP and a port number. I wouldn't expect Wireshark to do that if it wasn't on port 80. – kasperd Feb 05 '19 at 19:17
  • 3
    @kasperd, there is a lot more to HTTP than just the port number. Just having the word GET at the start of the message payload, and what look like header/value pairs in the rest of the message would make anyone who cares to hazard an educated guess assume that it's HTTP traffic. (Plus, the protocol version at the end of the message's first line is kind of a dead giveaway, too...) – Ghedipunk Feb 05 '19 at 19:46
  • @Ghedipunk I don't expect Wireshark to make such guesses. You can always tell Wireshark what protocol to decode something as. No need to try to make guesses. And if the OP did in fact ask Wireshark to decode the protocol as HTTP, that's something which the question should have mentioned. – kasperd Feb 05 '19 at 20:04
  • 2
    @kasperd Wireshark is very clever. Have a read of [this](https://osqa-ask.wireshark.org/questions/21257/how-does-wireshark-determine-the-protocol)! It applies some heuristics when the protocol is not self-evident. Point is none of this reflects on the quality of the question at all. – Lightness Races in Orbit Feb 05 '19 at 20:19
  • @LightnessRacesinOrbit First half of that post just says look at what's in the packet and apply the decoding which the relevant protocol standard says to use. The rest of the post suggests it will use the information from some of the analyzed packets to deduce which protocol to analyze other packets as and sometimes just try a bunch of different protocols to see which can decode it without producing an error. I have used Wireshark in situations where those two later approaches should have worked, but they didn't. So I doubt that post is entirely accurate. – kasperd Feb 05 '19 at 20:53
  • 1
    @kasperd Forget Wireshark, look at QOS systems and firewalls that do deep packet inspection. They identify protocols on non-standard ports at wirespeed. It's a solved problem. – user71659 Feb 05 '19 at 22:01
  • 1
    @user71659 What are you even trying to say? What I have been saying all along is that **Wireshark** does not show HTTP in the Protocol column when the connection goes to port 8060. I just tested myself with the exact query copied from the question, and Wireshark shows me `TCP 221 GET /dial/com.spotify.Spotify.TVv2 HTTP/1.1 [TCP segment of a reassembled PDU]`. Notice how it says **TCP** not **HTTP**. – kasperd Feb 05 '19 at 22:13
  • 2
    @kasperd Invalid test. The heuristics follow the flow and look for things like response being `HTTP/1.1`, and `User-Agent` etc. A single line isn't representative. Because it's heuristics, you need to test with the original packet trace and version before you accuse the OP of tampering or omitting information. – user71659 Feb 05 '19 at 22:15
  • @user71659 Finally a comment that actually respond to what I was saying. Yes it turns out that `HTTP/1.1 404\n` in the response will cause Wireshark to treat the traffic as HTTP, but a well formed `GET` command in the request won't even if that contains `HTTP/1.1`. Just goes to show that heuristics aren't accurate. And it is possible in certain scenarios to construct traffic which can be decoded as more than one different protocol, so heuristics will never be accurate. – kasperd Feb 05 '19 at 22:39
  • @kasperd That's not necessarily inaccurate. Some protocols [put a HTTP/1.1](https://en.wikipedia.org/wiki/HTTP_tunnel) to get through firewalls and proxy servers then switch to their own protocol afterwards. – user71659 Feb 05 '19 at 22:51
  • 1
    Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/89309/discussion-between-kasperd-and-user71659). – kasperd Feb 05 '19 at 23:38
  • @kasperd There was no need to be rude. – Lightness Races in Orbit Feb 05 '19 at 23:48
  • 1
    @LightnessRacesinOrbit I am just pointing out that comments in this thread have repeatedly been misrepresenting what I said. How is that rude? I never said that HTTP cannot be used on other ports. Neither did I say it's impossible to detect HTTP if it's used on other ports. What I said is that whenever I have used Wireshark it has decoded traffic according to what standard applies to the port number used and if you wanted traffic decoded as anything else you had to explicitly tell Wireshark to do so. – kasperd Feb 05 '19 at 23:55

2 Answers2

48

It appears to be a feature called Spotify Connect. Spotify allows you to play music from you phone or computer using your Roku or smart TV, as most people will likely have better sound systems for their TVs than for their computer.

Presumably your Spotify desktop app is automatically scanning your LAN and querying compatible devices to be able to offer this feature. In your case it looks like you have a compatible Roku, but the app isn't installed on it, so it returns a 404.

AndrolGenhald
  • 15,436
  • 5
  • 45
  • 50
  • Does it actually know before sending the request that it is being sent to a compatible device? And how would it know that? Or will it sent that request to every webserver on the LAN in order to find out which of them run compatible software? – kasperd Feb 05 '19 at 11:02
  • 13
    @kasperd The request you're seeing _is_ the discovery mechanism. Indeed, how else would it work? I'm actually surprised it's not unicast or something like that (though it may have done a port scan first). – Lightness Races in Orbit Feb 05 '19 at 11:21
  • 12
    This is a protocol called DIAL (Discovery and Launch). A device (in this case, the pc) sends out a multicast request on the local network. DIAL-enabled devices reply with their service url. Applications can then be queried by a HTTP GET to the relevant endpoint (defined by registering an app on the DIAL website, in this case it's spotify). You can find out more on the DIAL website: http://www.dial-multiscreen.org/ – Alex Meuer Feb 05 '19 at 16:56
  • 6
    For _discovering_ devices, DIAL uses mDNS. Once it's found a device, it queries its capabilities by hitting an HTTP endpoint (in the SRV response to the mDNS query) on the device. – Roger Lipscombe Feb 05 '19 at 17:21
  • @RogerLipscombe afik DIAL uses SSDP for discovery not mDNS. – Rick Feb 06 '19 at 13:34
  • @LightnessRacesinOrbit the http request is most likely after it's discovered the device and determined that it supports DIAL. The SSDP protocol that DIAL uses for discovery uses HTTPU which wireshark does not display as an HTTP request but rather usually correctly identifies as SSDP requests. Hence the http request is most likely trying to just find out what subservices are available for a device that it's already determined supports DIAL. – Rick Feb 06 '19 at 13:40
  • @Rick Yep, agreed. (Should probably have put more emphasis on my parenthetical) – Lightness Races in Orbit Feb 06 '19 at 13:44
  • @Rick, not as implemented by Chromecast, but, you know: standards. – Roger Lipscombe Feb 06 '19 at 13:52
2

You might not be aware of it (Roku doesn't heavily advertise it) but the Roku can be used for remote streaming across multiple services. I've used mine to stream Youtube from my phone over the Chromecast protocols.

As far as Spotify Connect goes, Spotify likes to identify all the devices streaming and any that could be used for streaming. For instance, if I fire it up on my phone, I can use my PC to control what's playing or vice versa (handy if you want to set a device up to stream and control it remotely). It's also a clever way for Spotify to also make sure you're only streaming on one device at a time per account.

Machavity
  • 3,766
  • 1
  • 14
  • 29