Closed Booth1983 closed 2 years ago
The protocol sets up a pairsessionID for this during the initial client-server pairing, but the original work from which UxPlay is derived did not implement it. In principal the info for it might be available, (see the original doc in the uxplay wiki). Not easy....
@Booth1983 It seems that AppleTV allows up to 16 device connections, and seems to associate a quantity pairSessionId with each, according to the analysis https://github.com/FDH2/UxPlay/wiki/AirPlay2.
The protocol was apparently extracted from third-party AirPlay server HappyCast with partiallly obfuscated code, and the person (apparently "dsafa22") who achieved this didn't seem to need this feature.
It seems to be created in the pair setup process. I dont fully understand yet where it is returned to the client; maybe it is associated with the "shared secret" which would be client specific.
The main issue is that a second device should not be allowed to connect while a first device is actively connected, right? UxPlay keeps track of connections, so it could probably be fairly easy to check this before accepting a new connection request. Is this the only issue, or are there other concerns?
@Booth1983
I found a very simple fix to the issue of a second device capturing a session in progress.
Each client creates 2 connections, but for unclear reasons, the max number was set at 10 by the original author of the mirror code dsafa22 in 2019. I have reset this to 2. Now, if a second client tries to connect it will be left waiting in a queue until the first client disconnects, at which point the waiting client will be allowed to connect.
This is now in the git master branch. Please test it and report if it fixes your issue.
Thanks for the update and feedback. I created a workaround for the problem of getting pushed out.
I started uxplay with the port set to 7000.
uxplay -n X -nh -m -avdec -p 7000
The I updated iptables with the following command:
sudo /sbin/iptables -I INPUT -p tcp --syn --dport 7001 -m connlimit --connlimit-mask 0 --connlimit-above 2 -j REJECT --reject-with tcp-reset
But I will test your update and give you a feedback.
I think you will find the fix works, and is better than messing with iptables!
Update: Your solution works great. Thanks!
great!
user feedback is the key to improvements!
Hi, I really love this project.
But for security in a company WiFi. Is it possible to implement a password for Login?
Maybe it could be possible to implement a maximum of connections. I can throw myself out of airplay with a seccond device. Maybe this can be prevented.