Making some more interesting discoveries on this topic. Any iPhone users who also happen to be somewhat Wireshark savvy--could you help test something with me?
I just ran a wireless sniffer capture from my MacBook. If you're not familiar, this is a built-in Mac tool that does a low-level (i.e. raw) capture from your wireless card. It gets all the 802.11 packets you don't typically see in a Wireshark capture on a Mac. Here's the process: https://osxdaily.com/2015/04/23/sniff-packet-capture-packet-trace-mac-os-x-wireless-diagnostics/
When analyzing the sniffer capture in Wireshark (again, post-capture), I found two of my iPhones (an iPhone 11 and an iPhone 12 Pro Max) are not indicating support for neighbor reports in their RM capabilities when sending an association request to the AP. Supposedly these iPhones support 802.11k, but the association request says otherwise.
Example:
When the AP sends the association response back, it indicates it supports neighbor report (hooray for 802.11k), but also states AP channel report capability is disabled:
Because the iPhones state they don't have neighbor report enabled, they never send a Neighbor Report Request, thus the AP does not send a Neighbor Report Response back.
Not sure what to make of all this yet, but wanted to float the info out there to the smarter brains who might have some thoughts about it.
For anyone willing to test this with me, the following display filter in Wireshark should show the packets we're interested in here:
Display Filter:
wlan.fc.type_subtype==0x0 || wlan.fc.type_subtype==0x1 || wlan.fixed.action_code==4 || wlan.fixed.action_code==5
Key:
wlan.fc.type_subtype==0x0 = Association Request
wlan.fc.type_subtype==0x1 = Association Response
wlan.fixed.action_code==4 = Neighbor Report Request
wlan.fixed.action_code==5 = Neighbor Report Response