I can't receive a stream from Mojave – RTP ChaCha20_Poly1305 decrypt: ValueError('MAC check failed') #78
Comments
|
@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 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 So, there may be something a little non-standard about my |
|
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 |
|
@systemcrash Thanks hugely for your time. I've iterated through a bunch of versions of |
|
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 723bace - try that.
Maybe also RTP redundancy ( 568e190 ). 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 ( |
|
Did you try bitmask 59?
You may need to roll back to 42d4926 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
The text was updated successfully, but these errors were encountered: