One-off - proper handling of iPad A16 LL opcode 0xFF mess

[arkhipenko]

Is there anything that could be done about this non-standard iPad opcode??

The A16 iPad (11th gen, iPad15,7 / iPad15,8) has a Bluetooth controller that behaves differently at the Link Layer
from every earlier Apple device. Independently reported by many developers, reproducing only on A16, in several
related forms:

Mechanism: Vendor LL opcode 0xFF
What the A16 does: Sends a vendor-specific LL Control PDU during negotiation
Effect on a peripheral: Stacks that don't recognize it get link instability / drop
Source: thread/798241 (https://developer.apple.com/forums/thread/798241)
────────────────────────────────────────
Mechanism: LL_CHANNEL_REPORTING_IND (0x28)
What the A16 does: Sends it at connection setup
Effect on a peripheral: Stack replies "Unknown Response" (0x07), A16 goes quiet then closes link
Source: thread/793999 (https://www.developer.apple.com/forums/thread/793999)
────────────────────────────────────────
Mechanism: LL_CONNECTION_UPDATE_IND storm
What the A16 does: Fires param updates as often as ~120 ms on iPadOS 26
Effect on a peripheral: Overwhelms peripheral -> disconnect/reconnect loop, HCI err 0x28 "Instant Passed"
Source: Nordic DevZone (https://devzone.nordicsemi.com/f/nordic-q-a/124994/ios-26-bluetooth-disconnect-issues/567643)
────────────────────────────────────────
Mechanism: MTU / LE-Privacy stall
What the A16 does: Doesn't complete MTU exchange (empty PDUs)
Effect on a peripheral: Workaround: force PHY LE 2M first, then MTU proceeds
Source: thread/795870 (https://developer.apple.com/forums/thread/795870)

[h2zero]

I don't think we should make adjustments to the core codebase for a single misbehaving device, the device in question should update it's firmware to be compatible with the spec.

[arkhipenko]

Yeah! Hear that, Apple!! :)))