Wired network: the adapter's identity
A wired network adapter introduces itself with an address stored in it, a name, a driver, the speed its link settled on and a limit on how much it carries in one frame. The first three bytes of that address are registered to the maker, so the address names its origin to anyone able to read it. A page in a browser reads none of this, installed software reads all of it through the operating system, and the far end of a connection sees the consequence of a field it never reads directly.
What the adapter reports
A wired adapter answers for itself in several ways at once. On the internal bus it presents identifiers that tell the operating system which driver belongs to it, and that driver reports a descriptive name, usually the family of the chip on the card. On the network it uses a hardware address of six bytes: the first three are registered to the maker, the rest belong to the individual unit, and one bit of the first byte marks an address set locally rather than taken from a registered range. That address rides in every frame the adapter sends and identifies it on its own segment of the network, and nowhere beyond it. Two more fields describe the link rather than the hardware: the speed the two ends agreed on when the cable came up, and the largest payload a single frame carries — the maximum transmission unit.
How websites see it
Nothing in a browser hands a page the hardware address, the list of interfaces, the driver or the frame limit. A site gets the address the connection arrives from, which belongs to the network rather than to the adapter, and it gets the behavior of the connection itself. That behavior says more than it looks like: opening a connection announces the largest segment the system will accept, and that value follows from the frame limit of the interface the traffic leaves by. With the other choices a network stack makes in the same moment, it narrows the family of operating system at the other end and stands out when the limit is not one a wired network would give. A script can also time its own requests to estimate round trip and throughput, and some browsers report a coarse grade of connection quality, derived from timings rather than from the adapter.
How installed software sees it
A program on the system asks the operating system for the list of network interfaces and gets, for each one, far more than a page ever sees: the interface name, the description supplied by the driver, the hardware address, the driver and its version, whether the link is up, the speed, the frame limit and the addresses assigned. Programs that build an identifier for the system they run on have leaned on the hardware address of the wired adapter for a long time, because it stays the same across restarts. Security components of online services read the same list to ask whether the adapters, their drivers and their addresses agree with the processor, the display and the configuration around them.
Why it matters for a virtual machine
A virtual adapter is software, and it answers as software. Its hardware address is usually drawn from a range registered to the maker of the virtualization product, so the first three bytes name that product to anyone who looks them up. Its name is either a generic one belonging to the paravirtual driver or the name of an older physical chip the adapter imitates — a chip that sits oddly in a system reporting a recent processor and a recent display. The link speed is often a nominal value that never changes, because there is no cable and nothing was negotiated. And when the traffic of a virtual machine is wrapped in another layer before it leaves the host, the frame limit inside is smaller than a wired network would give, and that smaller value travels outward in every connection opened from inside. The environment in this tour answers the way a physical adapter does, consistently with the other parts on the route.
What this stop of the tour shows
In this scene the camera follows the cable to the adapter and opens its fields as a readable card: the prefix of the address with the maker it belongs to, the name, the driver, the negotiated speed and the frame limit. The card is drawn on the page rather than painted into the video, so it can be read in any language and with the animation off. The next stop is the wireless adapter, the last on the route.
| Field | What it says |
|---|---|
| Hardware address | The address the adapter puts in every frame it sends. It identifies the adapter on the local segment of the network and travels no further than that. |
| Vendor prefix | The first three bytes of the address, registered to the maker and open for anyone to look up. One bit of them marks an address assigned locally instead. |
| Adapter name | The description the driver reports, usually the family of the chip, alongside the name the operating system gives the interface. |
| Driver | The software that runs the adapter, with a name and a version of its own. A paravirtual driver announces its own kind to everything on the system. |
| Link speed | The rate the two ends of the cable agreed on when the link came up. It describes the connection, not the adapter alone. |
| Maximum transmission unit | The largest payload the interface carries in one frame. The system derives from it the largest segment it announces when opening a connection, so the far end sees a consequence of a field it cannot read. |