Device Details

Investigate a single device end-to-end: identity, current enforcement, automation matches, activity patterns, LLM verdict, and the full event history — all in one page.

You reach Device Details by clicking a MAC address anywhere in the system — from Devices History, search results, the dashboard, action logs, or firewall decisions.

The page is organised top-to-bottom as the header, then the sections below in this order: Device Status, Enforcement Status, DHCPv6 Client Details (when applicable), Which Rules Apply?, Activity Timeline, Actions Timeline, Activity Heatmaps, LLM Analysis, and finally the All DHCP Events table.

The top bar shows the device identity, lets you change the time range, and exposes one-click actions.

From left to right:

Back arrow — return to the previous page.
MAC address — the device identity, displayed in monospace.
Status badges — one badge per active enforcement action (Blocked, Denied, Throttled, Monitored, Allowed). No badge means no active enforcement.
Time range controls — previous/next arrows step the window backward or forward, and the picker selects ranges like “Last 24 hours” or a custom range. All sections below recompute when you change this.
Refresh — re-fetch everything for the current time range.
Quick action buttons — Block, Deny, Throttle, Monitor, Allow, Cleanup, Analyze. Active actions show as filled; available actions show as outlined. See Action Controls below.
Export — download a CSV of the visible DHCP events.
Print — open a formatted printable report in a new browser window.

Device Status

Core identity for the device, plus the on-demand network probe.

The left side shows:

Hostname — most recently advertised hostname (Option 12).
Vendor — vendor class identifier (Option 60).
First Seen — earliest event timestamp recorded for this MAC.
Last Seen — most recent event timestamp.
IPv4 — last IPv4 address seen for this device (omitted if none).
IPv6 — last IPv6 address seen for this device (omitted if none).
Total Events — count of all DHCP events recorded.

The right side hosts the Device Probe controls, described below.

Device Probe

The Probe Device action runs network-level diagnostics against the device’s current IP to gather identifying information.

The probe is a network-level diagnostic only. It is not TR-069/CWMP or SNMP — there is no application-layer CPE management protocol involved.

A probe run executes:

ICMP ping — reachability and latency. You can pick a preset (Quick / Standard / Thorough) or set custom ping count, size, TTL, and timeout.
Reverse DNS — PTR lookup for the device’s current IP.
OUI lookup — first three bytes of the MAC mapped to the IEEE OUI vendor name. Always works, even when the device is offline, because it is a local database lookup.
nmap scan — only runs when nmap is available on the appliance’s PATH. Surfaces open TCP ports and any OS/service banners nmap volunteers.

There is no firmware-version, model-number, or serial-number gathering — the probe cannot pull those without a management protocol on the device side.

Triggering and Interpreting Probes

Click Probe Device to run. Results appear inline within seconds (longer if nmap is enabled).

Ping reply — device is reachable; OUI vendor, reverse-DNS name, and any nmap findings will be present.
No ping reply — device is offline or behind a firewall blocking ICMP. OUI vendor lookup still succeeds; reverse DNS may or may not resolve depending on the resolver.
nmap unavailable — appliance is running without nmap on PATH. Install nmap on the appliance and restart the processor service to enable port-scan output.

Enforcement Status

A collapsible section that shows every active enforcement signal for this device, in three columns.

The header summarises the state (“3 actions | nftables active” or “No active enforcement”). Click to expand or collapse — it auto-expands when there is any active enforcement.

Database Actions

Lists every row in the mac_actions table that is currently active for this device. Each card shows:

The action type as a colour-coded badge (block, deny, throttle, monitor, allow).
When it was executed.
Who executed it (automation, llm, or a username).
When it expires (omitted for permanent actions).
An expandable “Show details” line with the raw details string (often includes the automation rule name).
A “View Analysis” link if the action was tied to an LLM analysis.

Rate Limit Enforcement

Tracks the kernel-level rate-limit set (blocked_macs). If the device is currently in the set, a green check mark appears alongside the expiration time and a progress bar. The bar colour shifts red as the expiration nears (red under 10 minutes, yellow under 1 hour, primary under 24 hours, gray beyond).

A device appears here when it violated the minimum protocol rules at the nftables level — separate from any LLM or automation decision.

Behavioral Enforcement

Tracks the LLM/automation/manual-decision sets: llm_blocked_marks, llm_denied_marks, llm_throttled_marks, llm_allowed_marks, llm_monitored_marks. Each set is shown as present (with expiration bar and attribution) or absent.

When an entry is attributed via the matching mac_actions row, the source is labelled below the entry:

Rule: <name> — automation rule that fired.
LLM Analysis — verdict from the LLM analyser.
<username> — manual action by an operator.

The column footer shows:

Mark Confidence — high for direct MAC marks; low (collision) when the mark was inferred via the truncated 3-byte MAC and may collide with another device.
Analysis Cooldown — minutes remaining before the device can be re-analysed by the LLM.

DHCPv6 Client Details

Structured DHCPv6 identity, relay, and class information — only shown when the device has DHCPv6 events.

The section header links to RFC 8415. Three columns appear when their data is present:

DUID Identification

Type — DUID-LLT, DUID-EN, DUID-LL, or DUID-UUID.
Raw DUID — the full identifier (truncated in the middle if very long; hover to see the full value).
Extracted MAC — MAC address embedded inside the DUID (LLT and LL types only).
Hardware Type — link-layer type for LLT/LL DUIDs.
DUID Created — the timestamp inside DUID-LLT.
Enterprise Number / Vendor — for DUID-EN.
UUID — for DUID-UUID.

Relay Information

Hop Count — number of relay agents the message traversed.
Peer Address — IPv6 address of the relay agent that forwarded the message.
Link Address — link-address field from the relay-forward message; identifies the client’s network segment.
Interface-Id (Option 18), Remote-Id (Option 37, RFC 4649), Subscriber-Id (Option 38, RFC 4580), Client Link-Layer (Option 79, RFC 6939) — when set by the relay.

Class Information

Vendor Class (Option 16) and Enterprise ID / Vendor when present.
User Class (Option 15) when present.

Known limitation: DUID-only DHCPv6 clients (those without an extractable MAC address) appear in lists and search results but cannot be opened on this page — there is no per-DUID route. Their entries display a DUID-derived placeholder in the MAC column and are not clickable links.

Which Rules Apply?

Evaluates the device against every automation rule and shows which would trigger, plus the winner.

The header shows a match count badge once the evaluation has run. Expand the section to fetch results; refresh inside the section to re-evaluate after rule changes.

For each rule the panel reports whether it would trigger, the filter and threshold values that were compared, and which rule wins by priority. This is the same evaluator used by the Automation Test Console, scoped to the current device’s recent activity.

Use this section to answer “why did automation block this device?” or “would the rule I just edited catch this device?”.

Activity Timeline

Stacked bar chart of DHCP events per message type across the selected time range, with a summary table.

The chart stacks one colour per DHCP message type (DISCOVER, REQUEST, ACK, OFFER, NAK, RELEASE, INFORM, and the DHCPv6 equivalents). The x-axis spans the current time range.

Below the chart, the per-message-type stats table lists:

Column	Description
Name	Message type with its colour swatch
Min	Smallest per-bucket count
Max	Largest per-bucket count
Mean	Average per-bucket count
Total	Sum across the time range

This is the right place to spot bursts of one specific message type (for example, a flood of DISCOVERs without matching ACKs).

Actions Timeline

A time-axis visualisation of every enforcement action executed on this device within the current range.

Each dot is one action, coloured by type. Hover for a tooltip with the action type and timestamp; click for the Action Detail Modal showing:

Action type, status (active / expired), execution timestamp, duration.
Who executed it (operator username, automation, or llm).
The action’s details/evidence text.
A summary of the linked LLM analysis if the action was LLM-driven, including suspicion reasons and recommendation.

The chart includes inline zoom and a horizontal scrubber so you can drill into busy periods.

Activity Heatmaps

Two fixed-timeframe heatmaps that visualise long-term presence and time-of-day rhythms.

Their timeframes and granularity are not user-adjustable — the header states “Fixed: 90-day calendar, 30-day weekly pattern”.

90-day calendar heatmap — one cell per day for the last 90 days, coloured by that day’s event count. Reveals long-term presence patterns and outage periods.
30-day weekly punch card — day-of-week × hour-of-day grid over the last 30 days, coloured by event count. Reveals time-of-day rhythms.

Each heatmap aggregates all message types into a single per-bin count; there is no per-message-type breakdown here (use the Activity Timeline above for that).

Reading the Heatmaps

A healthy device typically shows periodic activity aligned with lease renewal cycles. Warning signs to look for in the punch card:

Constant fill across all hours of all days — possible flood or chatty firmware.
Bursts at unusual hours for the device type — possible spoofing or scheduled scan.
Long inactive stretches followed by sudden bursts — possible re-attach or spoof flip.

LLM Analysis

The most recent LLM verdict for the device, plus a button to run a fresh analysis.

If no analysis has run, the panel shows an empty state and a “Run Analysis” prompt. If an analysis exists, four summary cards appear at the top:

Card	Meaning
Risk Score	0–100% threat score. Red over 70%, yellow over 40%, green below.
Recommended Action	block / deny / throttle / monitor / allow / none, with a priority badge (critical / high / medium / low).
Confidence	How confident the model is in its verdict, 0–100%.
Analysis Date	When the analysis was produced.

A second row shows the analysis context: time window analysed, number of requests, unique IPs seen.

Below the cards:

Recommendation — the model’s free-text recommendation.
Action Justification — why the model proposed that specific action (highlighted with a yellow side bar).
Indicators — keyword tags the model surfaced (for example dhcp-flood, vendor-mismatch).
Evidence — bullet list of specific observations the model based its verdict on.

The Analyze button at the top right triggers a new run. When the device is in cooldown, the remaining minutes are shown next to the button and it is disabled until the cooldown expires.

All DHCP Events

Paginated, filterable table of every DHCP event for this device.

The header is followed by a collapsible Filters panel (message type, protocol, IP, XID, time-range refinements). Pagination appears both above and below the table, with page-size options 25 / 50 / 100 / 250.

Columns

Column	Description
Timestamp	When the packet was processed
Proto	v4 or v6 badge
Type	DHCP message type
Source IP	The relay or client IP that sent the packet
Server IP	DHCP server that handled the packet (when known)
Requested IP	IP the client asked for (Option 50)
Lease	Granted lease time
XID	Transaction ID linking the DHCP exchange
Rule	Which processor rule matched this packet

Hostname, Vendor, and Client MAC are not repeated as columns — they are device-level properties shown in the page header and the Device Status section.

Expanded Row

Click any row to expand it. The expanded panel shows:

For DHCPv4 events — Packet Details: op code, hardware type, hardware length, hop count, seconds, flags, source/destination ports, destination IP, destination MAC, assigned IP (yiaddr) on responses, server hostname, boot filename, and the server identifier option.
For DHCPv6 events — DHCPv6 Details: Client DUID, Server DUID, DUID type, link address, peer address, interface ID, remote ID, subscriber ID, preferred lifetime, valid lifetime, IA addresses (assigned IPv6 addresses), and delegated prefixes (for prefix delegation).
DHCP Options — every raw DHCP option carried in the packet, as code → value pairs.

Action Controls

Apply enforcement actions directly from the device header.

The quick action buttons sit in the header. The actions are grouped:

Restrictive — Block, Deny, Throttle
Permissive — Monitor, Allow
Utility — Cleanup, Analyze

Action	Effect	Default duration
Block	Drop all DHCP packets at the kernel; events still recorded	2 hours
Deny	Drop all DHCP packets and suppress event emission in the userspace inspector	Permanent
Throttle	Rate-limit to 10 packets / minute; excess dropped	1 day
Monitor	Log packets in the per-message-type chain; no enforcement	7 days
Allow	Bypass all enforcement chains (trusted)	30 days
Cleanup	Remove the device from all enforcement sets	—
Analyze	Open the Analyze dialog to run an LLM analysis	—

Clicking Block, Deny, Throttle, Monitor, Allow, or Cleanup opens the Action Modal:

Confirms the MAC address, action type, and duration.
Lets you set a custom duration in seconds and add an optional reason.
On confirm, records who executed the action, applies the nftables set update, and writes an entry to mac_actions.

Clicking Analyze opens the Analyze Modal, where you choose the analysis prompt/profile and submit; the result appears in the LLM Analysis section once the run completes.

Export and Print

Two ways to take the device’s information off the page: CSV export of events, or a formatted printable report.

CSV Export

Click Export in the header. The download contains only the All DHCP Events rows (not the whole page), one row per event, with these columns:

Timestamp, Type, Source IP, Server IP, XID, Hostname, Vendor, Rule, Requested IP, Lease Time

The filename is device_<mac-with-dashes>_events_<YYYY-MM-DD>.csv. The export respects the current filters and time range.

Printable Report

Click Print in the header. A new browser window opens with a formatted report that includes, in order:

Heading — MAC address, generation timestamp, time range.
Device Status — three-column layout: device information (hostname, vendor, first/last seen, total events, active actions), Rate Limit Enforcement set state, and LLM Enforcement set state.
Activity Timeline Statistics — the same per-message-type Min/Max/Mean/Total table shown on screen.
Actions Timeline — table of executed actions with timestamp, type, executor, status, and duration.
Activity Patterns — message-type distribution (the heatmap charts themselves are not rendered in print).
LLM Analysis — risk score, recommended action, confidence, analysis date, recommendation, indicators, evidence.
DHCP Events — table of the first 100 events shown on screen; an italic line notes if more were truncated.

The report uses a print-friendly stylesheet, so it can be printed to paper or saved to PDF from the browser.

IP Address History

The event history captures every IP address the device has been assigned over time.

By examining the event rows you can see:

The your_ip field in DHCPv4 responses, or the IA Addresses in expanded DHCPv6 events, shows what IP was assigned.
The Requested IP column shows what the client asked for (Option 50 in DHCPv4).
Tracking these across time reveals whether a device changes IPs frequently — a possible indicator of MAC spoofing or DHCP starvation.

Tip: filter by message type ACK (DHCPv4) or REPLY (DHCPv6) and sort by Timestamp ascending to see the chronological progression of IP assignments for a device.