uxplay doesn't show me any debug error messages -- can't seem to detect uxplay from my iOS device

[ahmadsharif1]

In the code block below my own comments are prefixed by "#":

uxplay -v
UxPlay version 1.56; for help, use option "-h"

strace -o /tmp/ss uxplay -d

supported audio format 1: AAC-ELD 44100/2
supported audio format 2: ALAC 44100/16/2
GStreamer video pipeline will be:
"appsrc name=video_source ! queue ! h264parse ! decodebin ! videoconvert ! autovideosink name=video_sink sync=false"
Initialized GStreamer video renderer
strace: decode_nlattr: [xlat 0x558bfaf732c0, dflt "AF_???", decoders 0x7ffd10434e90] size is zero (going to pass nla_type as decoder argument), but opaque data (0x7ffd10434f50) is not - will be ignored
strace: decode_nlattr: [xlat 0x558bfaf732c0, dflt "AF_???", decoders 0x7ffd10434e90] size is zero (going to pass nla_type as decoder argument), but opaque data (0x7ffd10434f50) is not - will be ignored
strace: decode_nlattr: [xlat 0x558bfaf732c0, dflt "AF_???", decoders 0x7ffd10434e90] size is zero (going to pass nla_type as decoder argument), but opaque data (0x7ffd10434f50) is not - will be ignored
using system MAC address 48:2a:e3:86:0e:56
Initialized server socket(s)

# uxplay seems to hang at this point? Or maybe it is waiting for avahi?
# I tried digging into the strace logs but didn't find anything interesting:

tail -n 10 /tmp/ss
poll([{fd=7, events=POLLIN}, {fd=11, events=POLLIN}], 2, 100) = 0 (Timeout)
poll([{fd=7, events=POLLIN}, {fd=11, events=POLLIN}], 2, 100) = 0 (Timeout)
poll([{fd=7, events=POLLIN}, {fd=11, events=POLLIN}], 2, 100) = 0 (Timeout)
poll([{fd=7, events=POLLIN}, {fd=11, events=POLLIN}], 2, 100) = 0 (Timeout)
poll([{fd=7, events=POLLIN}, {fd=11, events=POLLIN}], 2, 100) = 0 (Timeout)
poll([{fd=7, events=POLLIN}, {fd=11, events=POLLIN}], 2, 100) = 0 (Timeout)
poll([{fd=7, events=POLLIN}, {fd=11, events=POLLIN}], 2, 100) = 0 (Timeout)
poll([{fd=7, events=POLLIN}, {fd=11, events=POLLIN}], 2, 100) = 0 (Timeout)
poll([{fd=7, events=POLLIN}, {fd=11, events=POLLIN}], 2, 100) = 0 (Timeout)

# Then I tried looking into /var/log/messages to see if avahi was working properly:

less /var/log/messages

avahi-daemon[2188837]: avahi-daemon 0.8 starting up.
dbus-daemon[1598]: [system] Successfully activated service 'org.freedesktop.Avahi'
systemd[1]: Started Avahi mDNS/DNS-SD Stack.
avahi-daemon[2188837]: Successfully called chroot().
avahi-daemon[2188837]: Successfully dropped remaining capabilities.
avahi-daemon[2188837]: No service file found in /etc/avahi/services.
avahi-daemon[2188837]: Joining mDNS multicast group on interface wlp82s0.IPv6 with address <snipped>
avahi-daemon[2188837]: New relevant interface wlp82s0.IPv6 for mDNS.
avahi-daemon[2188837]: Joining mDNS multicast group on interface wlp82s0.IPv4 with address 192.168.1.212.
avahi-daemon[2188837]: New relevant interface wlp82s0.IPv4 for mDNS.
avahi-daemon[2188837]: Joining mDNS multicast group on interface lo.IPv6 with address ::1.
avahi-daemon[2188837]: New relevant interface lo.IPv6 for mDNS.
avahi-daemon[2188837]: Joining mDNS multicast group on interface lo.IPv4 with address 127.0.0.1.
avahi-daemon[2188837]: New relevant interface lo.IPv4 for mDNS.
avahi-daemon[2188837]: Network interface enumeration completed.
avahi-daemon[2188837]: Registering new address record for <snipped> on wlp82s0.*.
avahi-daemon[2188837]: Registering new address record for 192.168.1.212 on wlp82s0.IPv4.
avahi-daemon[2188837]: Registering new address record for ::1 on lo.*.
avahi-daemon[2188837]: Registering new address record for 127.0.0.1 on lo.IPv4.
avahi-daemon[2188837]: Server startup complete. Host name is <snipped>.local. Local service cookie is 2893770692.

avahi-browse -a -t 
+ wlp82s0 IPv4 Chromecast-Ultra-758e950774f334977a5419353100cae0 _googlecast._tcp     local
+ wlp82s0 IPv4 2ec0ae99-4883-529b-b128-430294d2e853          _spotify-connect._tcp local
+ wlp82s0 IPv4 Roku Ultra                                    AirPlay Remote Video local
...

cat ... avahi-daemon.conf
[publish]
# disable-user-service-publishing=yes

# I commented out that line that perhaps could prevent publishing?

# I tried to look at iptables to see if that was missing something and flushed everything:

# iptables -S
# Warning: iptables-legacy tables present, use iptables-legacy to see them
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N uplink-filter
-A INPUT -j ACCEPT
-A OUTPUT -o lo -j uplink-filter

# iptables-legacy -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT

How do I debug this further? IMO, uxplay itself should report some error on the output if something is wrong with avahi publishing. That is what I am guessing is the problem, but I can't seem to make any progress on that.

[fduncanh]

uxplay doesnt currently report on its DNS_SD contacts with avahi. (It might be possible to add debug message to do this)

you probably read the README, but in case not, here is the relevant entry:

• from the README

1. uxplay starts, but stalls after "Initialized server socket(s)" appears, without any server name showing on the client.

Stalling this way, with no server name showing on the client as available, probably means that your network does not have a running Bonjour/zeroconf DNS-SD server. On Linux, make sure Avahi is installed, and start the avahi-daemon service on the system running uxplay (your distribution will document how to do this). Some systems may instead use the mdnsd daemon as an alternative to provide DNS-SD service. (FreeBSD offers both alternatives, but only Avahi was tested: one of the steps needed for getting Avahi running on a FreeBSD system is to edit /usr/local/etc/avahi/avahi-daemon.conf to uncomment a line for airplay support.)

After starting uxplay, use the utility avahi-browse -a -t in a different terminal window on the server to verify that the UxPlay AirTunes and AirPlay services are correctly registered (only the AirTunes service is used in the "Legacy" AirPlay Mirror mode used by UxPlay). If the UxPlay service is listed by avahi-browse, but is not seen by the client, the problem is likely to be a problem with the local network. After starting uxplay, use the utility avahi-browse -a -t in a different terminal window on the server to verify that the UxPlay AirTunes and AirPlay services are correctly registered (only the AirTunes service is used in the "Legacy" AirPlay Mirror mode used by UxPlay). If the UxPlay service is listed by avahi-browse, but is not seen by the client, the problem is likely to be a problem with the local network.

[ahmadsharif1]

I did read that part, which is why I showed that avahi-daemon was running from my /var/log/messages in my original comment.

Also note that avahi-browse -a -t does show AirPlay from my Roku.

What else can I do other than running avahi-daemon on my machine?

[fduncanh]

The code that registers the uxplay service with the DNS_SD service (usually avahi) is in lib/dnssd.c.

If you find a useful place there to add a useful message to confirm registration, please report back!

[ahmadsharif1]

Thanks. I will look into that.

What do you think the issue could be? I posted output from iptables, /var/log/messages about avahi-daemon and also avahi.conf file (I commented out that line that I believe the README is referring to).

[fduncanh]

this is what avahi-browse -a -t shows after "uxplay -nh" is run on my system

<snip>
+   eth0 IPv6 UxPlay                                        AirPlay Remote Video local
+   eth0 IPv6 Apple TV                                      AirPlay Remote Video local
+   eth0 IPv4 UxPlay                                        AirPlay Remote Video local
+   eth0 IPv4 Apple TV                                      AirPlay Remote Video local
+     lo IPv4 UxPlay                                        AirPlay Remote Video local
+   eth0 IPv6 80C16EECA088@UxPlay                           AirTunes Remote Audio local
+   eth0 IPv6 2CB43A06B752@Apple TV                         AirTunes Remote Audio local
+   eth0 IPv4 80C16EECA088@UxPlay                           AirTunes Remote Audio local
+   eth0 IPv4 2CB43A06B752@Apple TV                         AirTunes Remote Audio local
+     lo IPv4 80C16EECA088@UxPlay                           AirTunes Remote Audio local
<snip>

[fduncanh]

this is my avahi/avahi-daemon.conf

[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

It looks like the only active entries are

[server]
use-ipv4=yes
use-ipv6=yes
ratelimit-interval-usec=1000000
ratelimit-burst=1000

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

[publish]
publish-hinfo=no
publish-workstation=no

[reflector]

[rlimits]

[ahmadsharif1]

Could you also share what a normal output of uxplay -nh is?

I used strace on it to see what it is trying to do. Do you recommend any other tools to see where and why it is stuck?

[ahmadsharif1]

I suspect there is something misconfigured at the network layer, probably a few layers below avahi itself. I probably need to use some low level networking tools like wireshark(?), etc. to understand what is going on.

[fduncanh]

"uxplay -nh -m" (with no firewall running)

UxPlay 1.59: An Open-Source AirPlay mirroring and audio-streaming server.
using randomly-generated MAC address ba:48:e4:5e:f2:7e
Initialized server socket(s)

at this point uxplay is waiting for a client to ask for a connection. nothing more will happen until it hears back from a client.

If avahi-browse does not show an entry for uxplay, it is not registered and no client will see it.

after the client connects:

Accepted IPv4 client on socket 24
Local: 192.168.1.80
Remote: 192.168.1.116
Client identified as User-Agent: AirPlay/665.13.1
Accepted IPv4 client on socket 26
Local: 192.168.1.80
Remote: 192.168.1.116
raop_rtp_mirror starting mirroring
Begin streaming to GStreamer video pipeline

[ghost]

on a side note - I had the same issue with 1.58 and the update to 1.59 (@archAUR) magically made them go away

[fduncanh]

@ahmadsharif1 @uxch I have now added an explicit message and exit (with error code returned by DNSServiceRegister) if the DNS_SD registration (either RAOP or AirPlay) fails: (it previously wasn't being checked to see if it had succeeded) (in latest github)

[ahmadsharif1]

Thanks for the patch, @fduncanh .

I cloned the repo and built it and ran it. This time I got an error message:

uxplay -v
UxPlay version 1.59; for help, use option "-h"

uxplay
UxPlay 1.59: An Open-Source AirPlay mirroring and audio-streaming server.
using system MAC address 48:2a:e3:86:0e:56
Initialized server socket(s)
dnssd_register_raop failed with error code -65537
mDNS Error codes are in range FFFE FF00 (-65792) to FFFE FFFF (-65537) (see Apple's dns_sd.h)

I looked at dns_sd.h and I found that the error is:

https://opensource.apple.com/source/mDNSResponder/mDNSResponder-544/mDNSShared/dns_sd.h.auto.html

    kDNSServiceErr_Unknown                   = -65537,  /* 0xFFFE FFFF */

That was kind of anti-climactic. I am going to now experiment with avahi setup to try to see what is going on here.

[ahmadsharif1]

Oh wow, I am so sorry for wasting everyone's time. I was editing the wrong avahi-conf file! The real avahi.conf file had disable publishing and that was the source of the issue. /facepalm

Side note: I wish avahi-daemon had a way to dump its config because it's hard to know what the settings were at the time the daemon was launched. Thanks for all the help @fduncanh . You can close this.

[fduncanh]

Not a waste of time, Thanks for your reports, uxplay now reports a failure to find a DNS-SD server rather than just silently stalling.