WiFi adapters don't really expose this type of interface. WiFi adapters interact with the host computer by sending and receiving packets, the 802.11 framing and

WiFi adapters don't really expose this type of interface. WiFi adapters interact with the host computer by sending and receiving packets, the 802.11 framing and radio de/modulation is performed internally by the adapter. In other words, the host computer sees IP packets, not radio data. Some adapters (or really most adapters) provide some ability for the host to send and receive raw 802.11 frames but it's an infrequently used feature and tends to have a lot of caveats and limitations... you'll see a lot of discussion of this if you read into security/exploitation use-cases for WiFi that involve monitoring or generating 802.11 management traffic. This is somewhat related to the old difference between a "modem" and a "winmodem": proper telephone modems performed the de/modulation internally, winmodems did not and relied on the host processor to do so, resulting in generally lower performance but a much cheaper device. At modern network data rates it is not really feasible to do this and the general direction is towards offloading more and more of the work to the network adapter, outside of the host's control or view. For gnuradio you need raw radio samples, often referred to as IQ data due to the nomenclature for amplitude and phase. Few devices that aren't specifically designed for software-defined radio use expose this data because it requires extra complexity in the device and tends to be rather high-bandwidth. The "RTL SDR" TV tuner dongles are so well known precisely because they contain an undocumented feature that allows a host to request raw IQ data, although at a poor sample rate and bandwidth since these devices were not really intended for it.