Cannot connect on an RPI 4

[fivenote]

I have a RPI 4, 32 bit Raspian - pretty standard. I compiled RpiPlay following the instructions. The RPiPlay app starts and I see it in the list of mirror devices on my iPhone. However, when I select it, there's no connection. The phone eventually says "unable to connect" and there are no messages shown in RpiPlay.

I tried with an iPhone 6s and iPad Pro running iOS 14.2, and an old iPad2 run-in iOS 9.3.

What's missing?

Thanks!!

[fivenote]

Found the problem... firewall was blocking ports.

The ports rpiplay use seem to be random. Any way to set firewall rules that let rpiplay work? Doesn’t seem like a good option to disable a firewall for this.

Thanks.

[icaduff11]

I'm experiencing the same issue as you described in your first comment. I've been trying to connect to RpiPlay with multiple different devices with different macOS and iOS versions.

Which firewall do you mean in your second post? I've disabled the router FW and also the macOS FW but neither worked for me. Would be interested in what steps you took to make it works.

Thanks in advance!

[fivenote]

I have ufw running on my pi and blocking all incoming ports except for a few servers the pi is running.

So when an airplay request came in, ufw blocked it. I turned ufw off and airplay worked. I then looked at the ufw logs to see which ports it blocked when an airplay request came in. It bounced around the 40000-50000s. I can't isolate a specific port that rpiplay uses so that I can add a firewall rule for it.

So for now... if I want rpiplay, ufw has to be switched off.

[icaduff11]

Thanks for going into more detail, I got it to work as well.

[pallas]

This is essentially a duplicate of #175, but all the detail is here so I'll close that one instead. Yes, the ports are by default ephemeral. All of the sockets in RPiPlay are ultimately created by netutils_init_socket, to which 0 is being passed in as the requested port. I believe (but have not confirmed) that if you change those calls to request a specific port, that's what will happen. Note that port is actually an inout pointer. The callsites I see are in raop_rtp_init_mirror_sockets, raop_ntp_init_socket, raop_rtp_init_sockets, and httpd_start; that last one is called from raop_start, which is called from start_server. Since SO_REUSEADDR is set, you should be able to do this without worrying about bind failing when the server restarts.

[Waester]

@pallas I can confirm that by changing these lines to static ports works.

https://github.com/FD-/RPiPlay/blob/e485668f752cedf9d1304ca08d5b2f2d03b67063/rpiplay.cpp#L384 port = 7000 (source)

https://github.com/FD-/RPiPlay/blob/e485668f752cedf9d1304ca08d5b2f2d03b67063/lib/raop_ntp.c#L192 tport = 7011 (source)

https://github.com/FD-/RPiPlay/blob/e485668f752cedf9d1304ca08d5b2f2d03b67063/lib/raop_rtp.c#L231 cport = 6001 (source & source) dport = 6000 (source)

https://github.com/FD-/RPiPlay/blob/e485668f752cedf9d1304ca08d5b2f2d03b67063/lib/raop_rtp_mirror.c#L506 dport = 7100, (source)

I picked all the static ports based on the AirPlay and RAOP standard documented here: https://openairplay.github.io/airplay-spec/ https://git.zx2c4.com/Airtunes2/about/

[pallas]

I think the ports you picked make sense, although the mirror port might be dangerous since the OS could pick it for something else. I've seen that set to 7100 in several other sources, so maybe it's worth just merging your patch here.

[Waester]

~~I can try changing it to 7100, but it might conflict with the HTTP port. It depends if rpiplay support multiplexing ports. If it works I will post a PR, otherwise we will have to agree on a unofficial port that is not within the dynamic range.~~

[Waester]

@pallas ~~OK I verified that RPiPlay does not support port multiplexing, so using 7100 both as the HTTP port and mirror port did not work.~~

~~We might have to pick a unofficial port for this, or leave it dynamic but use the official range (49152-65535) I have seen the port 7020 being mentioned in this article https://www.programmersought.com/article/2084789418/, but I suspect that is a dynamic port that just happen to use the 7000 range. Because the airplay server used in the article is the predecessor to RPiPlay (https://github.com/KqSMea8/AirplayServer)~~

~~Thoughts?~~

[Waester]

Nevermind, my static HTTP port selection was wrong from the beginning, HTTP service should have been in port 7000 (source) and the HTTP request for mirroring happens in port 7100 (source)

I will post an PR.

EDIT: PR posted, https://github.com/FD-/RPiPlay/pull/196