Is this a hardware limitation, or a limitation of the Linux Bluetooth stack? Or maybe I'm just wrong?
My understanding is that most bluetooth devices interface with the operating system over a standardized host controller interface (HCI) over a UART or SPI interface. Basically the OS sends some standardized commands to the HCI and receives some data back. This means that the OS doesn't have full control over the radio and are limited in what they can do to a set of standardized commands[1]. For example, even if you monitor everything that OS sends/receives over this HCI channel (using, e.g. btmon on Linux) you will not see everything that is going on.
For example, with bluetooth classic, during inquiry (discovering pairable devices) you don't really see all the details of what the device is doing. The hardware doesn't seem to signal anything about a host devices scanning you and the reply packets that are sent. I was trying to debug some issues with Windows 11 not discovering my device (despite it being in inquiry scan mode and that my phone could see it but not my desktop) and btmon was totally unhelpful in this case and I believe it to be a limitation of how the OS and the bluetooth device communicate at a fundamental level. It turns out the answer to my particular issue was the "class of device" that my device reported wasn't one that Windows 11 will show during pairing.
[1] https://software-dl.ti.com/simplelink/esd/simplelink_cc13x2_...
This sniffer is set up to follow the channel jumping, but instead of participating in the packet exchange, it just listens for both parts. As the channel jumps are predetermined, the sniffer can sleep between these events, then start the radio up to listen on the right channel at the right time.
The hardware does not support listening to multiple channels at the same time, so to follow a connection, the sniffer needs to listen to the connection establishment exchange to learn the timing and channel pattern for the connection.
Device discovery and connection establishment runs on three channels, but all beacon packets (advertisements) are sent on all three channels, so the sniffer only needs to listen to one of them.
The connection requests are sent as immediate responses to an advertisement. If we want to be sure we catch all connection requests for a specific device, we can choose to "follow" its advertisements, which are sent on each of the three channels in sequence.
The sniffer is implemented by interacting directly with the radio hardware peripheral, which acts just like a state machine with states RX, TX, idle, and a few warmup states.