[Instant Privacy] AllowedMACAddress not honored by firmware — whitelist completely ineffective

[HankYuLinksys]

Summary

Instant Privacy's MAC whitelist (AllowedMACAddress) is completely ineffective at the firmware execution layer. The feature only has two actual states:

Firmware Behavior	Trigger
Block all (no device can connect, including those in whitelist)	Flag transitions OFF→ON, filtering activated
Allow all (any device can connect)	Flag is OFF, or flag is 1 but filtering was never activated (e.g. factory reset default)

The AllowedMACAddress list content is ignored — even devices whose real (non-randomized) MAC is correctly written to the list are blocked. This is a pure firmware bug; the app cannot work around it.

Related Issues

• Instant Privacy: Default status is incorrect #968 — Default status incorrectly shown as ON (surface symptom of factory reset default value issue)
• [Instant-Privacy] Allowed devices with all 0 mac address information #1057 — Allowed devices showing all-zero MAC (surface symptom; underlying cause is whitelist not working)

Environment

• Device: Pinnacle 2.0 / M60-US
• Firmware: 1.2.2.26070203
• App: Linksys Now 2.x (USP path)

Key Findings

Finding A — The 0→1 flag transition activates filtering, not the list content

MACAddressControlEnabled flag's 0→1 transition is the switch that activates filtering. A flag value of 1 alone does not mean filtering is active — after factory reset, the flag defaults to 1 but filtering is never applied to the datapath, so devices connect freely. Only an explicit OFF→ON transition actually starts filtering.

Finding B — Once filtering is activated, the list content is not honored

Once filtering is activated, regardless of whether the list is empty, contains sentinel 00:00:00:00:00:00, or contains real device MACs, the behavior is the same: block all. The running filter does not allow any device based on AllowedMACAddress.

Finding C — Reboot does not make the whitelist effective

Even after correct list write + reboot, devices in the whitelist still cannot connect. This means the firmware does not correctly apply AllowedMACAddress to the filter even during boot-time config reload. The whitelist mechanism is simply not wired up in this firmware version.

Finding D — Factory reset default value is incorrect (but behavior is accidentally correct)

After factory reset, main APs default to MACAddressControlEnabled = 1 + AllowedMACAddress = 00:00:00:00:00:00. The flag defaulting to 1 is incorrect (clean state should be 0), but since filtering is never activated (Finding A), devices can still connect — the functional behavior (off) is accidentally correct, but the app misreads the flag and displays "ON".

Test Steps & Results

All tests performed via wired connection to the app. All Wi-Fi test devices had Private MAC disabled to ensure association uses the exact MAC in the whitelist.

Round 1 — Isolating "list content" variable (flag unchanged, only list modified)

#	Operation	Flag	List	Can new device connect?
1	After factory reset	1 (unchanged)	[000]	✅ Yes
2	Flag OFF	0	[000]	✅ Yes
3	Disconnect all Wi-Fi, then Flag ON	1 (0→1 transition)	[000]	❌ No
4	Remove 000	1 (unchanged)	[] empty	❌ No
5	Add 000	1 (unchanged)	[000]	❌ No
6	Clear, manually add phone's real MAC DC:52:85:5D:D0:7C	1 (unchanged)	[DC:52:...]	❌ No (even the whitelisted phone cannot connect)
7	Flag OFF then Flag ON	1 (0→1 transition)	[DC:52:...]	❌ No

Analysis:

• Steps 1 vs 3 have identical state (flag=1 + list=[000]) but opposite results → proves 000 is not an "allow-all sentinel"; the determining factor is whether filtering was activated (Finding A).
• After step 3 activated filtering, steps 4-7 all block regardless of list content (including real MAC) → list content is not honored (Finding B).

Round 2 — Isolating "write method" variable (standard enable path, atomic write)

The app's standard toggle uses buildEnableUpdates → MacFilterAccessPoints.update, writing flag=true + current device MAC list in a single atomic USP SET (verified in code — only these two fields are sent).

#	Operation	Result
1	Flag OFF	Laptop and phone connect normally with real MAC ✅
2	Standard toggle ON (atomic write: flag=true + 3 real MACs)	Laptop and phone kicked off, cannot reconnect ❌
3	Router reboot	Still cannot connect ❌

Log evidence (from privacy-toggle-enable.txt):

SET request (single atomic write):

{
  "Device.WiFi.AccessPoint.1.MACAddressControlEnabled": true,
  "Device.WiFi.AccessPoint.1.AllowedMACAddress": "DC:52:85:5D:D0:7C,5C:9B:A6:68:ED:4C,98:FD:B4:9D:B0:1B",
  "Device.WiFi.AccessPoint.2.MACAddressControlEnabled": true,
  "Device.WiFi.AccessPoint.2.AllowedMACAddress": "DC:52:85:5D:D0:7C,5C:9B:A6:68:ED:4C,98:FD:B4:9D:B0:1B",
  ...
}

GET response (config layer confirmed correct):

{
  "Device.WiFi.AccessPoint.1.MACAddressControlEnabled": "1",
  "Device.WiFi.AccessPoint.1.AllowedMACAddress": "DC:52:85:5D:D0:7C,5C:9B:A6:68:ED:4C,98:FD:B4:9D:B0:1B",
  ...
}

Config is correct, but phone (real MAC DC:52:85:5D:D0:7C is first in list) still cannot connect.

Analysis: Atomic write via standard path also fails → rules out "split write" hypothesis → confirms whitelist is ineffective regardless of write method (Finding B), and reboot cannot salvage it (Finding C).

TR-181 Specification Reference

Both MACAddressControlEnabled and AllowedMACAddress are standard TR-181 parameters (since Device:2.0) under Device.WiFi.AccessPoint.{i}., not vendor extensions (vendor extensions have X_ prefix).

Source: Broadband Forum Device:2 Data Model

Parameter	Type	Official Description
MACAddressControlEnabled	boolean (W)	"Indicates whether or not MAC Address Control is enabled on this WiFi. MAC Address Control limits client devices to those whose hardware addresses match the AllowedMACAddress list."
AllowedMACAddress	string(:17)[] (W)	"Comma-separated list of MAC Addresses. Hardware addresses of client devices that are allowed to associate with this WiFi if MACAddressControlEnabled is true."

The specification clearly states: when MACAddressControlEnabled = true, "only devices whose MAC matches the AllowedMACAddress list can connect." This firmware's behavior violates the spec — after filtering is activated, even devices in the list are blocked, effectively making the whitelist mechanism non-functional.

Required Firmware Fixes

• Fix AllowedMACAddress application at execution layer — when filtering is activated, allow devices in the list instead of blocking all.
• Fix factory reset default value: clean state should be MACAddressControlEnabled = 0, not 1 + 00:00:00:00:00:00.
• Ensure reboot / config reload correctly applies AllowedMACAddress to the filter.

Documentation

Detailed investigation documented in: doc/instant_privacy/factory-reset-false-enabled-state.md