A router's MAC filter, a DHCP reservation, a captive-portal exemption and a parental-control schedule can all stop matching the same phone on the same night, with nothing changed on the router and nothing changed on the phone. The first check takes three seconds and needs no tools. Open the router's client list, find the address it now shows for that device, and read the second hexadecimal character. If it is 2, 6, A or E, the address is flagged as locally administered — not the manufacturer-assigned address the allowlist was built from, so that entry cannot match while the device keeps using a private address.
That character carries real weight for a structural reason: two flag bits fall inside it, and an address issued out of an IEEE prefix carries a zero in one of them — so it cannot show a 2, 6, A or E.
The practical consequence runs opposite to most advice on the subject: randomisation usually does not need to be switched off. On a home network using WPA2 or better, the private address a modern phone presents is normally stable — the trouble is that it is a different stable address from the one on the allowlist, adopted at a moment nobody logged. Which of four rotation schedules the device is on decides whether the fix is to copy one address once, or to stop using address-based rules for that device at all.
Where 2, 6, A and E come from
The 48-bit address every Wi-Fi station puts in its frames carries two flag bits in its first byte, defined the same way for decades. IETF RFC 7042, IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters, states it plainly: "Two bits within the initial octet of an EUI-48 have special significance in MAC addresses: the Group bit (01) and the Local bit (02)." The parenthesised numbers are hexadecimal weights, which is why the test works on the written form of the address without any decoding.
The Local bit is the one that matters. RFC 7042 continues: "The Local bit is zero for globally unique EUI-48 identifiers assigned by the owner of an OUI or owner of a longer prefix. If the Local bit is a one, the identifier has been considered by IEEE 802 to be a local identifier under the control of the local network administrator." Whether a phone inventing an address sets that bit to one is the operating system's choice, not something RFC 7042 requires.
Because the Group bit weighs 1 and the Local bit weighs 2, both live in the low half of the first byte — the second character when the address is written out. Its sixteen possible values split three ways. Four (0, 4, 8, C) have both flags clear, as an address from an IEEE prefix does. Four (2, 6, A, E) have the Local bit set and the Group bit clear, marking one that did not come from such a prefix. The other eight (1, 3, 5, 7, 9, B, D, F) have the Group bit set, marking a group address rather than one station.
The inference is stronger in one direction than the other. A 2, 6, A or E rules out an IEEE-assigned hardware address on any platform, because it follows from the bit definitions alone. Reading a 0, 4, 8 or C as proof that randomisation is not involved holds only where the operating system is documented to set the Local bit when it invents an address. Android documents that; Apple's two pages and Microsoft's never mention the bits, so on an iPhone or a Windows laptop it rules nothing out.
Two bits pinned on Android, forty-six left free
The Android Open Source Project reference on MAC randomization behavior describes Android's own implementation in two sentences: "The MAC randomization feature randomizes the address by setting the locally administered bit to 1, and the unicast bit to 0. The other 46 bits are randomized." Setting the unicast bit to 0 is the same thing as clearing the Group bit, which is why an invented address still behaves as an ordinary station address on the wire.
Forty-six free bits is worth converting, because it explains why guessing never recovers a lost entry. Two raised to the forty-sixth power is 70,368,744,177,664 — a little over seventy trillion addresses one device could present on one network. A twenty-five-entry allowlist covers roughly 3.553 × 10-13 of that space, so there is no working version of "try the neighbouring addresses". On Android, where the pinned bits are documented, the only surviving relationship between the old entry and the new one is that both carry a 2, 6, A or E in the second position.
It also settles the case where a router shows two entries that look like one phone. If one reads 2, 6, A or E in that slot, that entry cannot be the hardware address, so the two are not duplicate records — the device presented both to the same network at different times. The same discipline of reading an address range settles a different false alarm, in which a WAN address that begins 100.64 explains why correct port-forwarding rules do nothing — the rule is saved exactly as intended while the number it depends on is not what the person assumed.
Four schedules, four different answers to "when"
"When does the address change" has no single answer, and this is the part vendor pages leave out. There are four schedules in common use, and they differ by more than an order of magnitude.
Apple, Fixed. Apple Support's page on using private Wi-Fi addresses on Apple devices lists three settings. With Off, "your device uses its hardware MAC address". With Fixed, "your device uses a private address, but the private address doesn't rotate", and Fixed is the default on networks with "WPA2 or stronger security". So on a properly secured home network, an iPhone presents one private address per network and keeps it. Specific events replace it, though not instantly: "If you erase all content and settings or reset network settings on your device, it uses a different private address the next time it joins the network." Forgetting the network discards the address used there, "unless it has been less than 24 hours since the last time it was made to forget that network." That grace period is why forgetting and immediately rejoining produces no new address, while doing the same thing a week later does.
Apple, Rotating. With Rotating, the device "uses a private address that rotates to a different private address every 2 weeks", and this is the default on networks with weak security or none. Fourteen days into a 365.25-day year works out to just over 26 rotations a year, meaning a single hand-copied allowlist entry is correct for about 3.83% of the year and wrong for the other 96.17%. A guest SSID left open, or one still running an older security mode, will land a device here without anyone choosing it.
Android, persistent. Android has randomised by default for years — "For devices running Android 10 or higher, the framework uses a randomized MAC address by default" — and the default flavour is persistent. What makes it persistent is worth reading closely: "Android generates a persistent randomized MAC address based on the network profile's parameters, including SSID, security type, or FQDN (for Passpoint networks)." Derived from those inputs rather than stored as a one-off, it survives the usual troubleshooting: "The MAC address doesn't get re-randomized if you forget and re-add the Wi-Fi network, because the MAC address depends on the network profile's parameters." It otherwise "remains the same until a factory reset."
That derivation carries an implication the document does not spell out, and it is the best available explanation for an overnight break on an Android device. If the address is a function of SSID and security type, changing either input changes the output — and a router firmware update that shifts a network from WPA2-only to a WPA2/WPA3 transition mode is a changed profile parameter, as is an SSID renamed by one character. AOSP does not state what happens in that case, so this is a hypothesis to test rather than documented behaviour. It costs nothing to check and it fits the symptom exactly.
Android, non-persistent. Android 12 added a second mode, used when a network suggestion app requests it or when the network "is an open network that hasn't encountered a captive portal" and a device overlay permits it. The address is then regenerated on reconnect if either condition holds: "The DHCP lease duration has expired and more than 4 hours have elapsed since the device last disconnected from this network" or "The current randomized MAC for the network profile was generated more than 24 hours ago." That 24-hour floor is fourteen times faster than Apple's two-week rotation, putting the ceiling at 365 regenerations a year.
What breaks, and in what order
Four router features depend on a stable address, and they fail in a staggered way that hides the common cause. A MAC filter fails at once and loudly: association is refused and the phone reports a generic inability to join. A DHCP reservation fails quietly: the device still joins but takes a pool address, so anything pointed at the old IP stops working while the phone looks fine. A captive portal fails at the next connection, its recorded session no longer matching. A parental-control schedule fails most quietly of all — the rule stays in place, stops covering the device, and produces no error.
Android's own documentation is unusually direct about the trade-off: "Persistent MAC addresses are necessary when networks rely on MAC address persistence to provide useful functionality. For example, they can help remember a device and let you bypass the login screen as expected, or enable parental controls." That is the platform acknowledging that portal memory and parental controls are address-keyed, and that persistence is what keeps them working.
The staggered timing is what sends people down the wrong path. A phone that cannot join looks like a Wi-Fi fault, so the router gets rebooted and the band and channel get changed. That instinct is worth resisting until the address has been read, much as a 5 GHz band that goes silent for exactly 31 minutes turns out to be working correctly. Where several devices are affected rather than one, counting the devices on the network before touching the router separates an address problem from a capacity one.
Pinning the address instead of chasing it
The repair is not to disable privacy features across the board. On a network the household controls, the goal is a private address that does not move, so it can be enrolled once.
Read the address the router currently shows and check the second character. If it is 0, 4, 8 or C on an Android device, randomisation is ruled out; on an iPhone or a Windows laptop it is not, because neither vendor states which bits its private addresses set — read that device's privacy setting instead. If it is 2, 6, A or E, open the privacy setting for that specific network on the device — not a global switch. Apple's three states are Off, Fixed and Rotating, and Fixed keeps a private address that does not rotate, which usually satisfies both the household and the router. On Android the equivalent choice is per-network and offers the hardware address as an alternative; the wording of that control is set by each manufacturer's interface and is not stated in the platform documentation consulted here, so the options are worth reading rather than assuming a label. Microsoft Support's guidance on using random hardware addresses in Windows describes the same split, between a global setting where "random hardware addresses are used while your PC scans for networks and connects to any network" and a per-network setting where "random hardware addresses are used the next time you connect to that network."
Then reconnect and read the address again, because the value shown before the change is not necessarily the one that appears after it. Copy the new address into the MAC filter, the reservation and the parental-control rule together, and delete the stale row rather than leaving it to confuse the next diagnosis.
Where none of this is controllable — a guest SSID a landlord runs, a workplace network defaulting to Rotating — address-based rules are the wrong tool, and no router setting will make them right. Identity has to come from above layer two: a per-user portal login, a certificate, or a pushed profile.
When This Doesn't Apply
Not every symptom in this family is a randomisation problem, and three cases in particular look identical but are not.
The first is scanning rather than joining. Apple Platform Security's section on Wi-Fi privacy describes a separate mechanism: "Apple platforms use a randomized Media Access Control address (MAC address) when performing Wi-Fi scans when not associated with a Wi-Fi network." That is not the private address a device uses once it joins, and the same document narrows it further — "Wi-Fi scans that happen while trying to connect to a preferred Wi-Fi network aren't randomized." A presence-detection tool reporting odd addresses only from nearby unassociated devices is seeing scan randomisation, which no per-network privacy setting will change.
The second is a network profile that has genuinely changed. If an Android device is on persistent randomisation and a new address appears anyway, the profile inputs are what to examine, because a persistent address "remains the same until a factory reset" and does not change on a forget-and-rejoin. Whether a security-mode change regenerates it is not documented by AOSP and is not confirmed here.
The third is everything below the address layer. A device that fails to associate on one band, at one distance, or after one particular reboot has a radio or channel problem, and the second hex digit reads the same before and after. This test separates an identity failure from a connectivity failure; it does not diagnose the latter. It is also Wi-Fi only — wired Ethernet interfaces are not covered by the settings above, and a MAC filter on a wired port does not fail for this reason.
The test, restated
Second character 2, 6, A or E: the address did not come from an IEEE prefix, so the allowlist entry built from the hardware address cannot match it. Second character 0, 4, 8 or C: on Android that rules randomisation out; on Apple and Windows it does not, and the privacy setting has to be read instead. The eight remaining values mark group addresses, not one station. One character, read without touching the phone, narrows in three seconds a question that otherwise ends in a router reset that changes nothing.
Comments
Post a Comment