Skip to content

Devices: read manufacturer, model, OS and type from FLWRT 2.0's X_LINKSYS_* leaves (ref FWDEV#207) #1693

Description

@AustinChangLinksys

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.yaml reads 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

  1. Read the five leaves. The definition is in linksys/usp_framework#82.
  2. Order: the firmware value first, and today's heuristics only when it reads "". The unprefixed 1.0 leaves are not part of the order.
  3. Type: X_LINKSYS_UserDeviceType first (written by Naming nodes and devices: name, location and type (ref FWDEV#207, FWDEV#208 gap 4) #1691), then X_LINKSYS_DeviceType. Map them to the app's categories through the 1.0 devregex.json strings, which icon_rules_data.dart already uses. Fall back to today's heuristics only when neither maps. Match name patterns on FriendlyName before HostName.
  4. 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_UserDeviceType holds 1–12 (phone … wearable), written by the app, so To do item 3's "map them through the devregex strings" applies to X_LINKSYS_DeviceType only. The user type is read as the app's code first; a devregex string another client wrote still maps.
  • Mobile is refined by model, as icon_rules_data.dart's Mobile|Phone rules do: devregex types a Kindle and an iPod Touch as Mobile, so a Mobile Kindle is a tablet and an iPod a media player.

Activity

  1. AustinChangLinksys commented on Oct 15, 2026

    @AustinChangLinksys
    CollaboratorAuthor

    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 carries 2.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 from OuiLookup.getVendorOrPrivate(device.mac) (defined at lib/core/utils/oui_lookup.dart:67). Matches the issue's claim.
    • DeviceClassifier.classify call sites: usp_connected_devices_card.dart:271, device_filter_provider.dart:267,312, usp_device_list_tile.dart:68, usp_topology_builder.dart:279; plus classifyWithConfidence at usp_device_detail_view.dart:127. None reads firmware data — five classify sites as stated, and the detail view is a sixth.
    • lib/generated/connected_devices.g.dart:91-96 — the generated host model lists only PhysAddress/IPAddress/HostName/Active/ActiveLastChange/Layer1Interface…; none of the five X_LINKSYS_* / ModelName / OperatingSystem leaves are read yet. Note the issue says connected_devices.yaml lives in the app; in the app repo only the generated file exists — the YAML is usp-definitions/devices/connected_devices.yaml in usp_framework.
    • usp_framework: usp-definitions/devices/connected_devices.yaml:151 already defines .X_LINKSYS_Manufacturer, and usp-codegen/tests/dart-verify/test/production_writes_test.dart:48-50 exercises X_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:

    Suggested roles: 2x-dev, 2x-verify

    Automated triage by gate.py. Dispatch requires Austin's authorization.

  2. added
    triagedAutomated diagnosis complete; root cause investigated (bug lane entry)
    on Oct 15, 2026
  3. added this to the 2.7.3 milestone on Oct 19, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

2.xLabeled for 2.x versionFLWRT-2.0Labeled belonging on FLWRT-2.0enhancementNew feature or requestfeature:monitoringNetwork monitoring and diagnosticstriagedAutomated diagnosis complete; root cause investigated (bug lane entry)

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions