Open NeutralKaon opened 1 year ago
@systemcrash, @LewdNeko: What do you think?
I forgot to say – this is a tangential issue that I don't think is related at all – but if it helps this is on an AMD "Starship Matisse" PCH motherboard with too many audio devices. The one that is the first card -- i.e. the one that amixer
returns without an argument -- confusingly is actually HDMI passthrough options from my graphics card. The real audio outputs are visible with amixer -c1
and friends. As previously documented, this causes volume management to break in ap2/utils.py but being terribly lazy and hard-coding the requisite device/"card" in works, e.g.:
line_pct = subprocess.check_output(["amixer","-c1", "get", "PCM"]).splitlines()[-1]
and similarly for setting the volume. It may be worth adding yet another command line parameter if anyone else has this issue. The above errors occur with or without those changes, however (and the output above was done straight from your current revision with -nv
to bypass them anyway).
So, there may be something a little non-standard about my alsa
/ pulsed audio
setup but I don't think it's related to this crypto error.
Given that most of what we know about airplay is educated guesswork, dealing with crypto problems is always going to be a bit sketchy. I remember playing with these components and repeating various tests to see what flags did. Mojave thinks the receiver handles the encryption: it does. It's just that the derived key isn't what it should be. Forcing the player module to stream out stuff which fails a MAC check is probably wrong.
It's possible we missed somewhere how Poly1305 should be handled. I don't remember the exact details, but each RTP packet contains the necessary MAC at the end. It works in tons of other scenarios, so in this case we still don't understand what specifically breaks this scenario.
You might try changing 'sourceVersion' (to something lower?), and see if it fools Mojave to treat us differently. See comments in ap2-receiver.py
.
@systemcrash Thanks hugely for your time. I've iterated through a bunch of versions of SERVER_VERSION
, which should enable and disable features, and all results in the same failure. I have similar issues connecting with shairport-sync's development branch supporting airplay 2 – except the connection is terminated by the mac host. I'll dig around and post more if I discover something useful.
It's not impossible that the sender has bugs in AP2. I ran 10.14 for a while during development (although I don't recall trying to set my mac as a sender very often), and everything is OK for now on 10.15.x.
It might be worth rolling back to earlier versions - it's not impossible that we introduced bugs.
I figured out stream connections in 723bace76de1b84c94750275cc0ee0913691ae5e - try that.
python3 ap2-receiver.py -n en0 --debug -ftxor 59
Maybe also RTP redundancy ( 568e19044b5b9705a2790bb2852027dc9f32e4e6 ). Something to change the default behaviour of the sender.
@systemcrash Thanks again for the offer, but neither of those commits "work". According to this issue 10.14 doesn't disclose the session key (shk
) and that might explain all…
Did you try bitmask 59?
python3 ap2-receiver.py -n en0 --debug -ftxor 59
You may need to roll back to 42d4926524392c4ac0ec5339e710bc6ef2c3d306 and try the above. I think I found a bug when connecting from macOS.
Edit: current master seems OK
Did you run with the correct bit flags to trigger streams mode?
The problem
Thanks for a lot of work clearly making an excellent project. Unfortunately, either in docker or running natively on ubuntu 22.04 (x64) I can't stream music from other devices on my lan – the crypto seems to fail. I've tried two different network interfaces (wifi and ethernet) and other implementations of airplay work with my alsa / pulsedaudio config (i.e.
shairplay-sync
).What commit exhibits the issue?
9b37407
Was there a last known working commit?
No response
What type of installation are you running?
virtualenv
With which python3 version do you run Receiver?
Python 3.10.4
OS the receiver runs on
Ubuntu 22.04
OS the sender runs
OS X 10.14.6
Which sender client was used
YouTube website in Firefox (as a browser)
Command invocation
python3 ap2-receiver.py -m DownstairsSpeakers --netiface=wlp3s0 -nv
Please include --debug output which helps to illustrate the problem
Additional information
No response