(Human)
Noticed the physical port graphic was wrong today. I guess it's because I have WAN on vlan0 instead of the default vlan2. Probably an extremely rare setup. Just thought I would report it since it's so trivial to do so from my existing troubleshooting conversation.
Re-reading over the below generated report, it looks accurate.
(I'm not on the latest firmware, but I did check against today's status-data.jsx.)
The workaround fixed the issue.
(Gemini 3.1 Pro Extended)
Description
On Broadcom ARM devices (specifically tested on the Netgear R7000), the "Ethernet Ports State" graphic on the status-home UI misaligns physical ports when the physical WAN port is reassigned to a new VLAN via the Advanced > VLAN Ethernet menu.
The background UI generation—specifically the <% etherstates(); %> call from status-data.jsx and the httpd C backend—relies on the wan_ifname and wan_ifnames NVRAM pointers to locate the physical WAN socket for visual mapping.
When a user disables logical WAN routing and manually reassigns the physical WAN socket to a new VLAN (e.g., changing it to vlan0), the firmware fails to update these pointers to reflect the new assignment. The pointers are left orphaned on their factory defaults (e.g., vlan2). The frontend then mistakenly pulls a physical port from that default factory array to draw the WAN graphic, completely scrambling the sequence of the remaining LAN icons.
Reproduction Steps
- Set WAN0 Type to
Disabled in the web interface.
- Navigate to Advanced > VLAN Ethernet. Uncheck the physical WAN port from its default VLAN and reassign it to a new one (e.g., VLAN 0) to use it as a standard switch port. Assign standard LAN ports to your primary bridge.
- Plug a live connection into the physical LAN 1 port. Leave the physical WAN port unplugged.
- Navigate to the Home / Status page.
- The
Ethernet Ports State graphic will incorrectly show WAN0 as 1000Mbps (stealing the LAN 1 hardware state) and LAN 0 as Unplugged (representing the actual empty physical WAN socket).
Expected Behavior
When a user modifies the physical WAN socket's VLAN assignment, the system should automatically update the wan_ifname and wan_ifnames NVRAM variables to match, ensuring the etherstates() backend logic accurately maps the graphical UI to the hardware layer.
Temporary Workaround
Manually repointing the orphaned NVRAM variables to the user's custom VLAN immediately fixes the frontend alignment. The frontend DOM correctly updates on the next async polling cycle:
nvram set wan_ifname=vlan0
nvram set wan_ifnames=vlan0
nvram commit
Hardware Verification (robocfg)
This is strictly a UI presentation abstraction leak, not a hardware fault. Executing robocfg show proves the physical layer and user-defined bridging is fully functional. The hardware WAN socket correctly reports DOWN, but the UI scripts erroneously assign port index 1 (LAN1) to the WAN graphic due to the stale wan_ifnames variable.
Device Info
- Router: Netgear R7000
- Firmware: FreshTomato Firmware 2026.1 K26ARM USB AIO-64K
- Kernel/Driver: Linux kernel 2.6.36.4brcmarm and Broadcom Wireless Driver 6.37.14.126 (r561982)
(Human)
Noticed the physical port graphic was wrong today. I guess it's because I have WAN on
vlan0instead of the defaultvlan2.Probably an extremely rare setup.Just thought I would report it since it's so trivial to do so from my existing troubleshooting conversation.Re-reading over the below generated report, it looks accurate.
(I'm not on the latest firmware, but I did check against today's status-data.jsx.)
The workaround fixed the issue.
(Gemini 3.1 Pro Extended)
Description
On Broadcom ARM devices (specifically tested on the Netgear R7000), the "Ethernet Ports State" graphic on the
status-homeUI misaligns physical ports when the physical WAN port is reassigned to a new VLAN via the Advanced > VLAN Ethernet menu.The background UI generation—specifically the
<% etherstates(); %>call fromstatus-data.jsxand thehttpdC backend—relies on thewan_ifnameandwan_ifnamesNVRAM pointers to locate the physical WAN socket for visual mapping.When a user disables logical WAN routing and manually reassigns the physical WAN socket to a new VLAN (e.g., changing it to
vlan0), the firmware fails to update these pointers to reflect the new assignment. The pointers are left orphaned on their factory defaults (e.g.,vlan2). The frontend then mistakenly pulls a physical port from that default factory array to draw the WAN graphic, completely scrambling the sequence of the remaining LAN icons.Reproduction Steps
Disabledin the web interface.Ethernet Ports Stategraphic will incorrectly show WAN0 as1000Mbps(stealing the LAN 1 hardware state) and LAN 0 asUnplugged(representing the actual empty physical WAN socket).Expected Behavior
When a user modifies the physical WAN socket's VLAN assignment, the system should automatically update the
wan_ifnameandwan_ifnamesNVRAM variables to match, ensuring theetherstates()backend logic accurately maps the graphical UI to the hardware layer.Temporary Workaround
Manually repointing the orphaned NVRAM variables to the user's custom VLAN immediately fixes the frontend alignment. The frontend DOM correctly updates on the next async polling cycle:
Hardware Verification (robocfg)
This is strictly a UI presentation abstraction leak, not a hardware fault. Executing
robocfg showproves the physical layer and user-defined bridging is fully functional. The hardware WAN socket correctly reportsDOWN, but the UI scripts erroneously assign port index 1 (LAN1) to the WAN graphic due to the stalewan_ifnamesvariable.Device Info