Repository navigation
Devices: read manufacturer, model, OS and type from FLWRT 2.0's X_LINKSYS_* leaves (ref FWDEV#207) #1693
Copy link
Copy link
Labels
2.xLabeled for 2.x versionLabeled for 2.x versionFLWRT-2.0Labeled belonging on FLWRT-2.0Labeled belonging on FLWRT-2.0enhancementNew feature or requestNew feature or requestfeature:monitoringNetwork monitoring and diagnosticsNetwork monitoring and diagnosticstriagedAutomated diagnosis complete; root cause investigated (bug lane entry)Automated diagnosis complete; root cause investigated (bug lane entry)
Milestone
Description
Ref linksys/FWDEV#207. The firmware (linksys/feed_premium#54 and linksys/targets#268) merged on 2026-10-13. Parity row: linksys/Architecture#210, Instant-Devices — device details (maker, model, OS, signal).
The app today (dev-2.7.3)
connected_devices.yamlreads only the unprefixed 1.0 leaves, which do not exist on 2.0.- The detail page takes the manufacturer only from
OuiLookup.getVendorOrPrivate(usp_device_detail_view.dart), so a client with a randomised MAC shows "Private/Random". - The device type comes only from
DeviceClassifier.classify(hostname, mac). None of its five call sites looks at firmware data.
FW contract
Read-only on Device.Hosts.Host.{i}.: X_LINKSYS_Manufacturer, ModelName, OperatingSystem, DeviceType and FriendlyName. When nothing is detected, a leaf reads "". It is never absent.
To do
- Read the five leaves. The definition is in linksys/usp_framework#82.
- Order: the firmware value first, and today's heuristics only when it reads
"". The unprefixed 1.0 leaves are not part of the order. - Type:
X_LINKSYS_UserDeviceTypefirst (written by Naming nodes and devices: name, location and type (ref FWDEV#207, FWDEV#208 gap 4) #1691), thenX_LINKSYS_DeviceType. Map them to the app's categories through the 1.0devregex.jsonstrings, whichicon_rules_data.dartalready uses. Fall back to today's heuristics only when neither maps. Match name patterns onFriendlyNamebeforeHostName. - Manufacturer: the firmware value first, the OUI only when it reads
"".
Depends on
- linksys/usp_framework#82 merged.
- One node is enough to verify.
Acceptance criteria
- An iPhone, a Mac and an Android phone that FW recognises each show FW's values.
- A client FW returns
""for shows the same as today. - An iPhone with a randomised MAC shows Apple, not "Private/Random".
- Unit tests for the order: firmware value,
""falls back, a user-set type wins.
Decisions (2026-10-16, PR #1697)
- The user's type is the app's own code, not a devregex string (Naming nodes and devices: name, location and type (ref FWDEV#207, FWDEV#208 gap 4) #1691):
X_LINKSYS_UserDeviceTypeholds1–12(phone … wearable), written by the app, so To do item 3's "map them through the devregex strings" applies toX_LINKSYS_DeviceTypeonly. The user type is read as the app's code first; a devregex string another client wrote still maps. Mobileis refined by model, asicon_rules_data.dart'sMobile|Phonerules do: devregex types a Kindle and an iPod Touch asMobile, so aMobileKindle is a tablet and an iPod a media player.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
2.xLabeled for 2.x versionLabeled for 2.x versionFLWRT-2.0Labeled belonging on FLWRT-2.0Labeled belonging on FLWRT-2.0enhancementNew feature or requestNew feature or requestfeature:monitoringNetwork monitoring and diagnosticsNetwork monitoring and diagnosticstriagedAutomated diagnosis complete; root cause investigated (bug lane entry)Automated diagnosis complete; root cause investigated (bug lane entry)
Activity
AustinChangLinksys commentedon Oct 15, 2026
Classification: enhancement (firmware-data read path), not a bug. Line: 2.x — the ticket reads
Device.Hosts.Host.{i}.X_LINKSYS_*USP leaves, a protocol-layer dependency that exists only on the USP line (and the issue already carries2.x/FLWRT-2.0). (author=Austin — self-filed tracking item, may already be in progress)Codebase findings (checked on
origin/dev-2.7.3):lib/page/devices/views/usp_device_detail_view.dart:131— manufacturer comes only fromOuiLookup.getVendorOrPrivate(device.mac)(defined atlib/core/utils/oui_lookup.dart:67). Matches the issue's claim.DeviceClassifier.classifycall sites:usp_connected_devices_card.dart:271,device_filter_provider.dart:267,312,usp_device_list_tile.dart:68,usp_topology_builder.dart:279; plusclassifyWithConfidenceatusp_device_detail_view.dart:127. None reads firmware data — fiveclassifysites as stated, and the detail view is a sixth.lib/generated/connected_devices.g.dart:91-96— the generated host model lists onlyPhysAddress/IPAddress/HostName/Active/ActiveLastChange/Layer1Interface…; none of the fiveX_LINKSYS_*/ModelName/OperatingSystemleaves are read yet. Note the issue saysconnected_devices.yamllives in the app; in the app repo only the generated file exists — the YAML isusp-definitions/devices/connected_devices.yamlin usp_framework.usp-definitions/devices/connected_devices.yaml:151already defines.X_LINKSYS_Manufacturer, andusp-codegen/tests/dart-verify/test/production_writes_test.dart:48-50exercisesX_LINKSYS_UserDeviceName/Type. The prerequisite linksys/usp_framework#82 shows as MERGED (2026-10-15T01:46Z), but the app has not yet regenerated against it.Blockers / open questions:
genstep) before the leaves are readable.X_LINKSYS_UserDeviceType; "a user-set type wins" cannot be verified end-to-end until Naming nodes and devices: name, location and type (ref FWDEV#207, FWDEV#208 gap 4) #1691 lands.devregex.json": not verified here that this file / strings exist in the 2.x tree (lib/core/utils/icon_rules_data.dartexists). Needs confirmation by the implementer.""rather than absent for undetected leaves — FW team to confirm on a real node.Suggested roles:
2x-dev, 2x-verifyAutomated triage by gate.py. Dispatch requires Austin's authorization.
test(devices, topology): golden states for the edit pen and dialogs, …
feat(devices): read FL-WRT 2.0 device identity, and name clients and …