UxPlay rarely visible in iOS 17 and macOS sonoma

padcom commented 6 months ago

This is one of those issues that are most frustrating but will be hardest to figure out, I presume..

On one machine I have the latest UxPlay and the latest avahi-daemon, all compiled from sources. As a second machine (a VirtualBox with latest xubuntu) and all stock (uxplay and avahi-daemon).

When trying to connect to my iPhone (iOS 17.1.2) the uxplay server rarely shows up in the list of available devices when trying to mirror the screen. The same occurs with macOS sonoma, 14.1.1.

However, my iPhone sees the mac almost immediately.

Would you be so kind as to explain how I could debug this problem? It annoys the hell out of me, and I don't even know where to start.

I tried logging the announced services using avahi-browse -a | grep Air and I can see everything just popping up in the log, when it was started and when it was shut down.

One more interesting thing is that when it finally shows up in the list, I can connect once or twice but then a few times later it just doesn't want to connect. I presume the ports have changed, but that happens also when I use the -p parameter to use the legacy ports.

Please help, I feel completely helpless..

thiccaxe commented 6 months ago

First step would be to download the "Discovery" app on your phone, this will allow you to see what mdns records the phone is picking up

thiccaxe commented 6 months ago

My next step would be to run UxPlay on mac to see if that is having similar issues

padcom commented 6 months ago

So 2 separate computers running UxPlay isn't enough? You'd say a 3rd one would make a difference?

thiccaxe commented 6 months ago

Adding additional UxPlay instances won't help, but there could be issues with mdns inside a vm; try running UxPlay on "bare metal" (your Mac)

padcom commented 6 months ago

Out of the two instances I already ran, the first one is running on bare metal, the second one in a VM. Anything else you'd like to take a stab on?

thiccaxe commented 6 months ago

What about the discovery app?

thiccaxe commented 6 months ago

I'd also disable Bluetooth since afaik iOS devices can use that to discover airplay. See if the max is still detected reliably

fduncanh commented 6 months ago

sounds like this problem?

(On Linux and *BSD): if a firewall is active on the server hosting UxPlay, make sure the default network port (UDP 5353) for mDNS/DNS-SD queries is open (see Troubleshooting below for more details); also open three UDP and three TCP ports for Uxplay, and use the "uxplay -p " option (see "man uxplay" or "uxplay -h").

It took me a long time to understand this myself! Check your avahi-browse results against those shown here in the README

padcom commented 6 months ago

@fduncanh You might have noticed that I did check it on 2 machines. On both I've had the avahi-borowse command running and both were reacting in real-time to me starting and stopping uxplay. So I don't think that was the issue. I also did test it with -p to get predictable ports with no success. I have also tested that if I have another app running on those ports I can connect to it without any issues so the firewall (which is not active on my machines anyways) isn't the issue.

padcom@padcom:~$ sudo ufw status
Status: inactive

Anything else I can check? Could it be that MacOS and iOS have changed something and now uxplay isn't compatible with those new OSes anymore?

fduncanh commented 6 months ago

@padcom you assert that the avahi-browse output is "OK", and you dont just have the loopback connection. Why not just post it to show this? (edit it if you want).

MacOS Sonoma 14.1.2 (latest) functions perfectly as Client and Server. iOS 17.1.1 functions as client.

padcom commented 6 months ago

@fduncanh There it is. Lines starting with + appear <1s after the server is started, lines with - appear a bit over 1s after the server is stopped:

$ avahi-browse -a | grep Air
+   eth0 IPv6 9C6B00022573@UxPlay@padcom                    AirTunes Remote Audio local
+   eth0 IPv6 UxPlay@padcom                                 AirPlay Remote Video local
+   eth0 IPv4 9C6B00022573@UxPlay@padcom                    AirTunes Remote Audio local
+   eth0 IPv4 UxPlay@padcom                                 AirPlay Remote Video local
-   eth0 IPv6 9C6B00022573@UxPlay@padcom                    AirTunes Remote Audio local
-   eth0 IPv4 9C6B00022573@UxPlay@padcom                    AirTunes Remote Audio local
-   eth0 IPv6 UxPlay@padcom                                 AirPlay Remote Video local
-   eth0 IPv4 UxPlay@padcom                                 AirPlay Remote Video local

padcom commented 6 months ago

And the output of uxplay, for completeness:

$ ./uxplay -p
UxPlay 1.67: An Open-Source AirPlay mirroring and audio-streaming server.
using network ports UDP 7011 6001 6000 TCP 7100 7000 7001
using system MAC address 9c:6b:00:02:25:73
Initialized server socket(s)
^CStopping...

padcom commented 6 months ago

And uxplay output with debug enabled:

$ ./uxplay -p -d
UxPlay 1.67: An Open-Source AirPlay mirroring and audio-streaming server.
Audio format 1: AAC-ELD 44100/2
GStreamer audio pipeline 1: "appsrc name=audio_source ! queue ! avdec_aac ! audioconvert ! audioresample ! volume name=volume ! level ! autoaudiosink sync=true"
Audio format 2: ALAC 44100/16/2
GStreamer audio pipeline 2: "appsrc name=audio_source ! queue ! avdec_alac ! audioconvert ! audioresample ! volume name=volume ! level ! autoaudiosink sync=false"
GStreamer video pipeline will be:
"appsrc name=video_source ! queue ! h264parse ! decodebin ! videoconvert ! autovideosink name=video_sink sync=true"
Initialized GStreamer video renderer
using network ports UDP 7011 6001 6000 TCP 7100 7000 7001
using system MAC address 9c:6b:00:02:25:73
using Public Key:
a03bfce3b8c07ade35cee7fbd2e02646cb477305f86763ed7251fba31e8009e0
Initialized server socket(s)
register_dnssd: advertised AirPlay service with "Features" code = 0x527FFEE6
^CStopping...
Exiting HTTP thread

padcom commented 6 months ago

I'd also disable Bluetooth since afaik iOS devices can use that to discover airplay. See if the max is still detected reliably

I figured as much :) Yes, BT has been disabled for testing on my mac, still there is no problem connecting from iphone to mac and still, neither see uxplay...

fduncanh commented 6 months ago

I wonder why your loopback isnt showing? (I don't know if this is important or not)

+   eth0 IPv6 UxPlay@xxx                                  AirPlay Remote Video local
+   eth0 IPv4 UxPlay@xxx                                  AirPlay Remote Video local
+     lo IPv4 UxPlay@xxx                                  AirPlay Remote Video local
+   eth0 IPv6 80C16EECA088@UxPlay@xxx                     AirTunes Remote Audio local
+   eth0 IPv4 80C16EECA088@UxPlay@xxx                     AirTunes Remote Audio local
+     lo IPv4 80C16EECA088@UxPlay@xxx                     AirTunes Remote Audio local
+

padcom commented 6 months ago

avahi-daemon.conf for completeness (see allow-interfaces to understand why nothing else other than eth0, which is the only connected interface, shows up in the list):

$ cat /etc/avahi/avahi-daemon.conf 
# This file is part of avahi.
#
# avahi is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as
# published by the Free Software Foundation; either version 2 of the
# License, or (at your option) any later version.
#
# avahi is distributed in the hope that it will be useful, but WITHOUT
# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
# or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
# License for more details.
#
# You should have received a copy of the GNU Lesser General Public
# License along with avahi; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
# USA.

# See avahi-daemon.conf(5) for more information on this configuration
# file!

[server]
#host-name=foo
#domain-name=local
#browse-domains=0pointer.de, zeroconf.org
use-ipv4=yes
use-ipv6=yes
allow-interfaces=eth0
#deny-interfaces=eth1
#check-response-ttl=no
#use-iff-running=no
#enable-dbus=yes
#disallow-other-stacks=no
#allow-point-to-point=no
#cache-entries-max=4096
#clients-max=4096
#objects-per-client-max=1024
#entries-per-entry-group-max=32
ratelimit-interval-usec=1000000
ratelimit-burst=1000

[wide-area]
enable-wide-area=yes

[publish]
#disable-publishing=no
#disable-user-service-publishing=no
#add-service-cookie=no
#publish-addresses=yes
publish-hinfo=no
publish-workstation=no
#publish-domain=yes
#publish-dns-servers=192.168.50.1, 192.168.50.2
#publish-resolv-conf-dns-servers=yes
#publish-aaaa-on-ipv4=yes
#publish-a-on-ipv6=no

[reflector]
#enable-reflector=no
#reflect-ipv=no
reflect-filters=_airplay._tcp.local,_raop._tcp.local

[rlimits]
#rlimit-as=
#rlimit-core=0
#rlimit-data=8388608
#rlimit-fsize=0
#rlimit-nofile=768
#rlimit-stack=8388608
#rlimit-nproc=3

fduncanh commented 6 months ago

Re: the mac

are we talking about mac as client or mac as the uxplay server?

padcom commented 6 months ago

Mac as client, iPhone as client; Linux Mint and Xubuntu as server. It's pointless to run uxplay on mac since it's supported natively on macOS

padcom commented 6 months ago

And a screenshot of my iPhone not showing uxplay... :(

fduncanh commented 6 months ago

To summarise, you problem is (?)

Uxplay run on a (Desktop AMD64) machine running Ubuntu 23.10 (?), natively (not a virtualbox copy)
your iOS 17.1.1 client "rarely" (? what that that mean?) sees UxPlay DNS_SD services, but sometimes does.
You claim there is no firewall (hmm try "systemctl status firewalld", you just showed that ufw was not active)

mDNS queries are on port UDP 5353 ; "works rarely" does sound like mDNS queries are not getting through, but loopback service works partially

*in any case it is a specific problem on your network

padcom commented 6 months ago

ad 1 and 2. I tried both, at first uxplay was visible from both (native Linux Mint, virtualbox Xubuntu), then after a few minutes it disappeared, re-appeared a few times in unspecified intervals, more than 1h for sure).

ad 3.

$ systemctl status firewalld
Unit firewalld.service could not be found.

As I mentioned a few times already, I am running Ubuntu-based distros, specifically Linux Mint and Xubuntu. firewalld is a RedHat invention AFAIK.

fduncanh commented 6 months ago

You need the iOS and Mac Discovery App to troubleshoot. Its not a UxPlay issue, its a DNS_SD issue.

https://apps.apple.com/us/developer/lily-ballard/id305441020

EDIT: could also be a network issue.

fduncanh commented 6 months ago

ad 1 and 2. I tried both, at first uxplay was visible from both (native Linux Mint, virtualbox Xubuntu), then after a few minutes it disappeared, re-appeared a few times in unspecified intervals, more than 1h for sure).

ad 3.
$ systemctl status firewalld
Unit firewalld.service could not be found.
As I mentioned a few times already, I am running Ubuntu-based distros, specifically Linux Mint and Xubuntu. firewalld is a RedHat invention AFAIK.

Someone running Mint turned out to have them both (ufw + firewalld) running, despite repeatedly claiming there was no firewall: see #8

padcom commented 6 months ago

Yeah, I guess it is always better to check. I completely agree...

I tried that app you sent me a link to. Indeed, it shows nothing. What can I check more? Can this be some kind of setting on DHCP or somewhere else on the router?

padcom commented 6 months ago

I don't believe it. Switching both the iPhone and mac to 2.4GHz made the whole thing work. Any idea what might be causing 5GHz network to not work? Any setting I could check?

padcom commented 6 months ago

That's only on apple devices. I tested connection via 5GHz and wire (wlan0 and eth0) and both work just fine. Is it somehow possible there is something in the new macOS or iOS that could block service discovery on 5GHz? Could it be somehow related to my access point?

thiccaxe commented 6 months ago

Is this reproducible on your end?

fduncanh commented 6 months ago

Network problems are nothing to to with UxPlay..... (it doesn't know about 5 vs 2.4 GHZ ...)

fduncanh commented 6 months ago

My MacOS tests(working) WERE on 5GHz.... so was the iPad

padcom commented 6 months ago

Guys, no so fast. The root cause has not been found, even though it was not uxplay's fault. I may not be the only one having those kinds of issues and googling it shows that there are multiple cases such as this. It'd be really good to figure this one out.

Any idea what could be wrong? Anything I could poke at?

padcom commented 6 months ago

mDNS issues on another project - it can't be a coincidence...

https://github.com/Mixiaoxiao/Arduino-HomeKit-ESP8266/issues/12

padcom commented 6 months ago

My MacOS tests(working) WERE on 5GHz.... so was the iPad

Works on my machine, right?

padcom commented 6 months ago

Another issue, same router as mine...

https://www.snbforums.com/threads/mdns-bonjour-multicast.86353/

fduncanh commented 6 months ago

I can add something to the "troubleshooting" part of the UxPlay README

what would you suggest as the text?

maybe something like this (maybe too long?)

Some users using dual-band (2.4/5 GHz) routers have reported network problems where clients fail to see UxPlay's DNS_SD announcement (a symptom of the client failing to receive a response to its mDNS queries) when the client uses one of the two bands, but see it when switched to the other band. Other projects using Bonjour/DNS_SD have had similar reports; it is not clear what the issue is, but it has been suggested that some dual-band routers behave incorrectly (or are misconfigured) and may block Bonjour/mDNS traffic between the two bands. Suggested (possibly router-specific) fixes include setting a fixed channel instead of "auto" channel selection.

padcom commented 6 months ago

OK, so you guys might think it's none of your business and you don't care but some other people might. I have found an actual actionable way to make it more reliable.

It turns out that with the devices I have (Asus 4G-AC86U, Macbook Air M1 on macOS sonoma 14, iPhone SE 2020 on iOS 17) the 5G is not reliable if the router is set to auto configure WiFi channel. I have switched this setting twice now and on Auto it ALWAYS turns into a problem. If you think about it, it actually is consistent with the issue I observed that sometimes it shows up, briefly, but then it disappears. This is also consistent with my 2G4 setting, which is at a fixed channel.

Disabling the automatic channel selection fixes the problem. Enabling it makes the problem reappear. 100% reproducible.

fduncanh commented 6 months ago

If you have found the problem AND the fix, Bravo! I'll add it to troubleshooting section!

EDIT. Do both channels work if Auto select is off?

padcom commented 6 months ago

@fduncanh You mentioned you also run 5GHz wifi - can you check your channel selection setting?

padcom commented 6 months ago

EDIT. Do both channels work if Auto select is off?

I have it set just like on the screenshot. I'm not an expert on WiFi and frankly don't know what you're asking about. That was a blind shot on my end to figure it out, basically enabling/disabling 1 thing at a time and checking what will make a difference. But if you elaborate on what "both channels" mean I might be able to answer..

fduncanh commented 6 months ago

My dual-band router has "auto" selected in both bands.

The alternative to "auto" is not "off" (sorry) but is selecting one of many possible fixed channels.

padcom commented 6 months ago

I've the 2.4GHz set to auto, but there is way less channels to choose from and I guess the FHSS algo implemented in Apple devices makes use of as many channels as it gets. Since TCP frames re-send missed frames I guess that's OK but for UDP, if a packet is sent on one channel and the receiver switches in between, the packet gets lost. That's why sometimes it works, with variables sometimes for each setup.

At least that's a reasonable explanation. If that is really what's going on, IDK.. But it would make sense that Apple tried to mitigate the issue by helping themselves with Bluetooth-based discovery.

padcom commented 6 months ago

One more setting that may have influence over mDNS on Apple devices:

Setting auto channel bandwidth also makes the discovery brutally unstable or just plain not work. Setting it back to a fixed value (in my case 80MHz but YMMV) fixes the issue. Go figure...

I begin to think that Apple made this a problem on purpose, so that only Apple devices would find themselves via BT with no issues. That'd be their style anyways..

fduncanh commented 6 months ago

So fixed channel on 5GHz works for you?

padcom commented 6 months ago

That is correct. And fixing both the channel width and the channel itself makes it rock solid (at least with the Asus 4G-AC86U router).

fduncanh commented 6 months ago

OK here is a better(?) README text: comments?

Some users using dual-band (2.4GHz/5GHz) routers have reported that clients using the 5GHz band (sometimes) "fail to see UxPlay" (i.e., do not get a response to their mDNS queries). Other projects using Bonjour/mDNS have had similar reports; the issue seems to be router-specific, perhaps related to "auto" rather than fixed channel selection (5GHz has many more channels to switch between), or channel width selections; one speculation is that since mDNS uses UDP protocol (with no resending of "lost" messages), a mDNS query might get lost if channel switching occurs during the query.

If your router has this problem, a reported "fix" is to (at least on 5GHz) use fixed channel and/or fixed (not dynamic) channel width.

fduncanh commented 6 months ago

Now added to the README https://github.com/FDH2/UxPlay#1-avahidns_sd-bonjourzeroconf-issues

@padcom thanks for your report (and resolution) of this issue!

FDH2 / UxPlay

UxPlay rarely visible in iOS 17 and macOS sonoma #245