Skip to content

feat(sources): name devices by MAC address in a rule, on the local network only - #105

Merged
Wasabules merged 1 commit into
mainfrom
feat-rules-by-mac
Oct 27, 2026
Merged

Wasabules merged 1 commit into
mainfrom
feat-rules-by-mac

Conversation

@Wasabules

Copy link
Copy Markdown
Owner

Stacked on #104, which is on #103. It will be retargeted to main once they are merged.

A rule that names an address loses its device when DHCP gives that device another address. SourceMatch.MACs lets a rule name devices by MAC instead.

What a rule takes

  • A MAC, whole, in any spelling: aa:bb:cc:dd:ee:ff, AA-BB-CC-DD-EE-FF, aabb.ccdd.eeff.
  • Or a pattern for one maker's devices: 04:03:12:*.
  • Anything else is refused when the rule is saved (macEntry).

Local network only, and the UI says so

  • The MAC comes from the neighbor table (feat(devices): MAC addresses and makers on the local network, and devices that moved #104). The reader asks it for the MAC of the address each message comes from, as the message arrives. The rule editor's preview and the re-reading of stored messages (feat(sources): read stored messages again with the rules #100) ask the same table.
  • The table only knows this machine's own networks. Behind a router, every device arrives with the router's MAC, so the table is not asked there. An address with no MAC known (routed, or not in the table yet) does not match a rule that names MACs. A rule by MAC therefore never matches a device behind a router.
  • The editor shows this in a highlighted note directly under the field. The user guide and the documentation page say the same.

Also

  • When a rule names a single address whose MAC is known, the editor offers to name the MAC instead.
  • The Devices tab also finds a device's rule by its MAC.
  • The 8 languages, the user guide, the README and the documentation page are updated.

Tests

internal/sources:

  • the same device at its address, then at its new address after a lease change;
  • a maker's pattern;
  • a device behind a router (no MAC) is never matched;
  • the preview gives the same results;
  • malformed entries are refused.

The UI was checked through the screenshot bridge: the field, the warning and the offer to name the MAC.

Checked: go vet (Windows, Linux), staticcheck, go test -race ./..., svelte-check --fail-on-warnings, npm test, npm run build, the docs' links.

…twork only

A rule that names an address loses its device when DHCP gives it
another. SourceMatch.MACs names devices by MAC instead: a MAC whole, in
any spelling, or a pattern for a maker's devices (04:03:12:*). The
reader asks the neighbor table (#104) for the MAC of the address each
message comes from, as it arrives; the preview and the reading again of
stored messages ask the same table.

A MAC is only known on this machine's own networks. Behind a router
every device arrives with the router's MAC, so the table is not asked
there and a rule naming MACs never matches: an address with no MAC
known - routed, or not in the table yet - is no match. The editor says
so under the field, in plain sight, and so do the guide and the
documentation page.

- When a rule names one address whose MAC is known, the editor offers
  to name the MAC instead.
- The Devices tab finds the rule that names a device by its MAC too.
- Entries that are no MAC are refused (macEntry).
@Wasabules
Wasabules changed the base branch from feat-device-mac to main October 27, 2026 12:38
@Wasabules Wasabules closed this Oct 27, 2026
@Wasabules Wasabules reopened this Oct 27, 2026
@Wasabules
Wasabules merged commit 61b0e61 into main Oct 27, 2026
14 of 15 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant