Wireless adapter and what it hears
A wireless adapter introduces itself much as a wired one does — a hardware address whose leading bytes come from a registered block, a name in the operating system, a driver — and then it does what no other part of a PC does: it listens, and reports what it hears. The networks around it, their strength and their channels become part of what the system knows about itself. A website is told none of that, installed software is told all of it, and a virtual machine usually has nothing to report at all.
What the adapter reports
Two answers come out of a wireless adapter. The first describes the part itself: a hardware address whose leading bytes belong to a registered block, the name the operating system gives the interface, the driver that runs the radio with its own maker and version, and the bands, channel widths and modes the radio supports. The second answer is a survey. The radio scans and returns what it can hear: for every network a name, the address of the access point answering for it, the strength of the signal, the channel and band in use, and the kind of protection the network asks for. The first answer says what the PC is. The second says where it is.
How websites see it
None of that reaches a web page. The browser offers no interface for a scan: a script cannot ask for the networks around the PC, for the name of the network it is joined to, or for the hardware address of the adapter carrying the request. A page sees the public address of the connection, how long its requests take and how steadily, and, in some browsers, a coarse estimate of connection quality. A wireless link behaves unlike a wired one — latency that wanders, throughput that dips and recovers — so a page that measures carefully can guess which of the two it is talking to. One indirect route matters more. If a visitor agrees to share location, the answer comes from the operating system, and on a PC with no satellite receiver it is usually assembled from the networks the wireless adapter could hear. The precision of that answer says a real radio is listening, somewhere that agrees with the rest of the story.
How installed software sees it
Through the operating system a program reads both answers in full. It lists the network interfaces and takes, for each, the hardware address, the interface name, the driver and its version, and whether the radio is switched on. It can ask about the current connection — the network name, the access point behind it, the band, the channel, the signal strength — and it can ask for a scan, or read the last one, and receive the whole neighborhood. On some systems that list is handed over only to a program cleared to see location, which says plainly what it is worth. Launchers and the protective components of online services read these fields when they decide whether they are running on a real PC: a list of networks has to be plausible for a place, not merely plausible.
What a virtual machine reports
A virtual machine normally has no radio at all. Its traffic arrives through an emulated or paravirtual wired interface, so the guest sees a wired adapter whose vendor prefix and driver both name the virtualization product, and the list of wireless interfaces comes back empty. Nothing is being concealed; there is simply nothing there to listen with. The emptiness is the tell. A system that presents itself as a laptop and cannot hear a single network around it is describing a place that does not exist, and any program that looks sees the contradiction. A physical adapter can be passed to a virtual machine directly, and then the answers are real ones; that is the exception, not the rule. Where a list of networks does exist, it still has to fit the rest of the identity: the place the connection address suggests, and a neighborhood that changes the way a real one changes.
What this stop of the tour shows
In this scene the camera turns to the wireless adapter, and the card beside it opens in two halves: what the radio says about itself on one side, what it can hear on the other. Both halves are drawn on the page rather than painted into the video, so they can be read in any language and without the animation. This is the last stop; from here the tour returns to the hub, where the parts are read together.
| Field | What it says |
|---|---|
| Vendor prefix | The leading part of the hardware address of the adapter, taken from a registered block. Systems also present a randomized address while scanning, so what a network sees is not always the maker. |
| Interface name | The name the operating system gives the adapter. It usually carries the maker and the model of the radio; in a virtual environment it names the virtualization product instead. |
| Driver | The software that runs the radio, with its own maker and version. A paravirtual driver names the product that supplied it. |
| Bands and modes | The frequency ranges, channel widths and modes the radio can work in. They place the part in a rough generation, and they have to match the model it claims to be. |
| Visible networks | Everything the radio can hear: for each network a name, the address of the access point, the channel and the signal strength. Matched against records of where such access points have been seen, it places a PC more closely than the connection address does. |
| Current connection | The network the adapter is joined to, the band and channel in use, the signal strength, and the rate agreed with the access point. |