Successor to #8, which bundled two very different problems. The FairPlay half is now a settled decision (recorded in docs/crypto.md — it will not be implemented here). This issue is the half that is still genuinely open, and it needs hardware rather than a code change.
The question
hap_pairing.rs originally used a fabricated SRP group — not the RFC 5054 3072-bit group, and not even prime. #23 replaced it with the real group, and srp.rs now pins the group's properties (bit length, primality, safe-primality, generator, and a check against a rearrangement of RFC 3526's formula) separately from the protocol round-trip, since a round-trip test passes happily when both sides share the same wrong modulus.
So the constant is now verifiably correct. What is not known is whether the surrounding handshake actually works, which no unit test in this repository can answer.
What has been tried
examples/pair_probe.rs (added in #26) exists for exactly this:
cargo run -p openplay-airplay --example pair_probe -- <receiver-ip>:7000
Run against a MacBook Air (Mac16,12): GET /info succeeds, and every other endpoint returns 403. That is not a crypto failure — macOS defaults its AirPlay Receiver setting to "Current User", which refuses the request before any pairing happens. The probe never reached the SRP exchange, so it produced no evidence either way.
(#26 also made hap_pairing.rs check the HTTP status line before parsing a body, because that 403 was reaching the TLV8 decoder and surfacing as Missing state TLV — a crypto-sounding error for an access-control problem. Same misleading-diagnostic shape as the original bug, one layer up.)
What would close this
A pair_probe run against a receiver that actually accepts the connection — an Apple TV, an AirPlay 2 TV, or a Mac with System Settings → General → AirDrop & Handoff → AirPlay Receiver set to Everyone / Anyone on the same network. Paste the output.
Three outcomes, all useful:
- Pair-setup completes — the SRP fix is confirmed end to end, and the README's "untested against hardware" caveat can finally come off.
- Pair-setup fails past the SRP exchange — a real, newly-actionable bug in the handshake, with a reproduction.
- 403 again — the receiver setting was wrong; retry.
Scope
Explicitly not in scope: FairPlay, and therefore Apple TV 2nd/3rd generation. Those are refused up front by model string and that is intended behaviour, not a gap. See the decision section in docs/crypto.md.
Until this is answered, the AirPlay row in the README stays marked untested. It is one command against the right hardware, and I do not have that hardware — help genuinely wanted.
Successor to #8, which bundled two very different problems. The FairPlay half is now a settled decision (recorded in
docs/crypto.md— it will not be implemented here). This issue is the half that is still genuinely open, and it needs hardware rather than a code change.The question
hap_pairing.rsoriginally used a fabricated SRP group — not the RFC 5054 3072-bit group, and not even prime. #23 replaced it with the real group, andsrp.rsnow pins the group's properties (bit length, primality, safe-primality, generator, and a check against a rearrangement of RFC 3526's formula) separately from the protocol round-trip, since a round-trip test passes happily when both sides share the same wrong modulus.So the constant is now verifiably correct. What is not known is whether the surrounding handshake actually works, which no unit test in this repository can answer.
What has been tried
examples/pair_probe.rs(added in #26) exists for exactly this:cargo run -p openplay-airplay --example pair_probe -- <receiver-ip>:7000Run against a MacBook Air (
Mac16,12):GET /infosucceeds, and every other endpoint returns 403. That is not a crypto failure — macOS defaults its AirPlay Receiver setting to "Current User", which refuses the request before any pairing happens. The probe never reached the SRP exchange, so it produced no evidence either way.(#26 also made
hap_pairing.rscheck the HTTP status line before parsing a body, because that 403 was reaching the TLV8 decoder and surfacing asMissing state TLV— a crypto-sounding error for an access-control problem. Same misleading-diagnostic shape as the original bug, one layer up.)What would close this
A
pair_proberun against a receiver that actually accepts the connection — an Apple TV, an AirPlay 2 TV, or a Mac with System Settings → General → AirDrop & Handoff → AirPlay Receiver set to Everyone / Anyone on the same network. Paste the output.Three outcomes, all useful:
Scope
Explicitly not in scope: FairPlay, and therefore Apple TV 2nd/3rd generation. Those are refused up front by model string and that is intended behaviour, not a gap. See the decision section in
docs/crypto.md.Until this is answered, the AirPlay row in the README stays marked untested. It is one command against the right hardware, and I do not have that hardware — help genuinely wanted.