University network issue, UxPlay not visible to dns-sd clients( Client does not see uxplay,(was Stalling on "Initialized server socket(s)" for no apparent reason))
SalsaMilk opened this issue · comments
I am using Manjaro 6.1.55-1 on an Intel laptop. Here's the output:
UxPlay 1.66: 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
0:00:00.098061822 3407 0x7f9250000e00 FIXME default gstutils.c:4036:gst_pad_create_stream_id_internal:<video_source:src> Creating random stream-id, consider implementing a deterministic way of creating a stream-id
using system MAC address d8:c0:a6:b8:a0:85
Initialized server socket(s)
It gets stuck here. I reviewed the example output and it appears that the next line printed should be something like Accepted IPv4 client on socket 24. I went through all of the possible issues in troubleshooting. Avahi appears to be working properly:
+ wlp0s20f0u1 IPv6 UxPlay@manjaro AirPlay Remote Video local
+ wlp0s20f0u1 IPv4 UxPlay@manjaro AirPlay Remote Video local
+ lo IPv4 UxPlay@manjaro AirPlay Remote Video local
+ wlp0s20f0u1 IPv6 EAEF902BECED@UxPlay@manjaro AirTunes Remote Audio local
+ wlp0s20f0u1 IPv4 EAEF902BECED@UxPlay@manjaro AirTunes Remote Audio local
+ lo IPv4 EAEF902BECED@UxPlay@manjaro AirTunes Remote Audio local
What did I miss? What could my issue be? Any info is appreciated!
- are you on the latest UxPlay
- can you see the UxPlay server on a iOS client from mdns?
- can you run a http server like python3 -m http.server and access it from the iOS client?
If yes to all, try running a wireshark to see if the client is somehow making a request that doesn't make its way to UxPlay
Yes I am on the latest version of UxPlay.
No I cannot see the server from an iOS client.
Yes I can access an HTTP server from the iOS client.
No I cannot see the server from an iOS client
Then mdns is broken. Check that the mdns port is opened
From the README: Was this done?:
After installation:
(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").
a closed port 5353 might not be your issue, since
If the UxPlay services are listed by avahi-browse as above, but are not seen by the client, the problem is likely to be a problem with the local network.
But if you do have a firewall on by default, you need to open the 3 UDP+TCP ports and use the uxplay -p <...> option.
This sounds more like what you describe
The manjaro firewall is usually firewalld. check with "systemctl status firewalld"
Port 5353 is open.
uxplay -p <...>
Gives me the same issue.
I don't think I'm using a firewall
> systemctl status firewalld
Unit firewalld.service could not be found.
> systemctl status firewall
Unit firewall.service could not be found.
> systemctl status ufw
Unit ufw.service could not be found.
In that case how might I resolve this issue?
Just to be clear:
-
You start uxplay, and (in a different window) on the system that is running uxplay, you check that
avahi-browse -a -tshows the expected output as you showed in your initial post. -
your client (what is it , ioS or macOS? give details) does not see uxplay. Are you able to try with a different client?
There is a free iOS app that scans mDNS called Discovery - DNS-SD Browser
https://apps.apple.com/us/app/discovery-dns-sd-browser/id305441017
install it on your (iOS) client, and check if sees _raop._tcp and _airplay._tcp, as you found on the server.
- If it doesn't see them, this would confirm that you have a network problem (nothing to do with uxplay). client and server have to be on the same local network (unless wide-area dns discovery is activated) (see http://www.dns-sd.org/)
Let us know what the iOS app shows. (If the client is macOS, there is probably some equivalent tool)
You start uxplay, and (in a different window) on the system that is running uxplay, you check that avahi-browse -a -t shows the expected output as you showed in your initial post.
yes
your client (what is it , ioS or macOS? give details) does not see uxplay. Are you able to try with a different client?
There is a free iOS app that scans mDNS called Discovery - DNS-SD Browser
https://apps.apple.com/us/app/discovery-dns-sd-browser/id305441017
I have already tried that app on both a 6th generation iPad running iPadOS 16.6.1, and an iPhone 14 running iOS 16.6.1. I do not see _raop._tcp or _airplay._tcp.
I think you're right that it's a network issue. Thank you everyone for your help.
I believe my issue is that I am on a University network, and the devices seem to be "sandboxed." Any suggestions on how I could address this issue?
University networks today are very security-conscious. Not sure what you can do.
This is not anything that we can help with, so closing.
Can Discovery-dns-sd-browser see any services offered by your laptop?
I don't think so but I also don't know a conclusive way to test that.
I was able to get UxPlay working by having my iPad and laptop connect to my iPhone's hotspot. I am still taking suggestions on any way I could potentially get this working on my University's network, but I do understand that this may be practically impossible without some hacking. Which is a good thing I guess!
Since you "can access an HTTP server from the iOS client" The unifersity has allowed fevices to communicate with each other. most likely the university's firewall is blocking mdns, as this would cause a huge amount of discovery/response packets to be sent out...
My understanding is that with a huge amount of mdns clients publishing services (all iDevices, Macs, printers, etc.) mdns could become unreliable.
Likely there is no way around this. One option could be to run a local vpn server on the university network that will simply bridge together your mdns devices... likely better off using a non-airplay alternative, since you are on a Mac.
I am not on a Mac...
If you are desperate to use airplay, you could spoof an Apple TV by publishing a "proxy" mdns record on the sending device which points to a local tcp/udp proxy. This proxy can be manually configured to the ip address and ports of your actual UxPlay server.
I am not on a Mac...
Oops, my bad :/ well, if you do end up being on Mac the above two could work
Thank you for the suggestions.