Local Network / DHCP Settings: DHCP Server shows "Disabled" but is actually running (Range N/A and Active Leases 0/0 also wrong)

[kateatlinksys]

Reproduce steps:

1. Login to Linksys Now.
2. Go to Menu > Local Network (and the DHCP Settings detail page).

Actual result:
The GUI reports DHCP Server as Disabled (toggle off), DHCP Range = N/A, and Active Leases = 0/0 ("No DHCP clients").
But the DHCP server is actually running — clients still obtain IPs. Backend (serial console) confirms:

• dnsmasq is running; dhcp.lan.ignore is not set (i.e. LAN DHCP is NOT disabled)
• DHCP range is configured: dhcp.lan.start=100, limit=150 (192.168.1.100–249)
• /tmp/dhcp.leases holds 2 active leases: 192.168.1.174 (DESKTOP-QTALE4M), 192.168.1.249 (ASTWP-041510)

So three fields are all inverted/wrong versus the backend: Status (Disabled vs running), Range (N/A vs 100–249), Active Leases (0 vs 2).

Expected result:
The GUI should reflect the real DHCP server state — Status Enabled, the actual DHCP range, and the active leases currently issued.

Env.: M60DU-EU / Pinnacle 2.0 FW 1.2.2.26062820 / Linksys Now 2.5.0.700525

Log:
(user pastes console / network / device log)

Screenshot:

[AustinChangLinksys]

🔍 Automated investigation (preliminary triage)

Line: 2.x / USP (TR-369)

Root cause:

• Trigger (likely firmware-side): The firmware's USP data model Device.DHCPv4.Server.Pool.1.* appears to be out of sync with the actual dnsmasq state. The reporter's serial console confirms dnsmasq is running with dhcp.lan.start=100, limit=150 and 2 active leases, yet the GUI shows Enable=off, empty range, and 0 clients — meaning the firmware returned Pool.1 values that do not reflect the live LAN DHCP service.
• UI note: The GUI faithfully renders whatever the firmware reports for Device.DHCPv4.Server.Pool.1; all three affected fields (Status, Range, Active Leases) read from that single subtree, which is why they are wrong together.

Evidence:

1. LAN info (Status + Range) is read from a hardcoded Device.DHCPv4.Server.Pool.1.* subtree. The LAN interface index is resolved dynamically via Alias='lan', but the DHCP pool index is fixed at .1. with no equivalent resolution (lib/generated/lan_network_info.g.dart L48-56):

static List<String> _buildPaths(String instancePath) => [
      '${instancePath}IPv4Address.1.IPAddress',
      '${instancePath}IPv4Address.1.SubnetMask',
      'Device.DHCPv4.Server.Pool.1.Enable',
      'Device.DHCPv4.Server.Pool.1.MinAddress',
      'Device.DHCPv4.Server.Pool.1.MaxAddress',
      'Device.DHCPv4.Server.Pool.1.LeaseTime',
      'Device.DHCPv4.Server.Pool.1.DNSServers',

2. Status is a straight passthrough of Pool.1.Enable; Range shows N/A only when Min/MaxAddress come back empty (lan_network_info.g.dart + lan_info_ui_model.dart):

dhcpEnabled: response['Device.DHCPv4.Server.Pool.1.Enable'] == true || ... == 'true' || ... == '1',
...
String get dhcpRange => (minAddress.isNotEmpty && maxAddress.isNotEmpty)
    ? '$minAddress ~ $maxAddress' : 'N/A';

Codegen throws when these keys are missing, so the observed "Disabled / N/A" (rather than an error) implies the firmware DID return Pool.1 with Enable=false and empty Min/MaxAddress.

3. Active Leases (0/0) is counted from the same Pool.1.Client.* subtree (lib/generated/dhcp_clients.g.dart L31-34; card at usp_dhcp_active_leases_card.dart L16):

'Device.DHCPv4.Server.Pool.1.Client.*.Chaddr',
'Device.DHCPv4.Server.Pool.1.Client.*.Active',
...
final activeCount = clients.where((c) => c.active).length;

Confidence: Medium — the reporter's serial-console evidence and the code path both point to a firmware-side Device.DHCPv4.Server.Pool.1 reporting mismatch (dnsmasq running but USP model reports disabled/empty), but no UI log.txt was attached to capture the actual USP Get response. To pin it down, a USP dump of Device.DHCPv4.Server.Pool.* (Enable / MinAddress / MaxAddress / Client) on the affected DUT would confirm whether firmware misreports Pool.1, or whether the live LAN pool sits at a different instance index than the hardcoded .1.

---

Auto-generated triage by Austin's tooling, pending Austin's review. Not a fix commitment.