Out-of-Band Management: AMT, DASH, and IPMI Power and Console from a Gateway
Out-of-band (OOB) management operates below the operating system. It reaches a machine through the management controller built into business-class hardware, and works when the machine is powered off, hung at boot, or running an unresponsive OS. This post describes how ET Ducky discovers and controls OOB hardware, what makes a device eligible, and the two ways a gateway is hosted.
OOB is delivered through a gateway: a service on the same local network as the managed hardware. The gateway discovers OOB-capable devices, holds a persistent connection to the cloud, and relays commands from the dashboard to the target controller.
Protocols and hardware
ET Ducky speaks three OOB protocols, each tied to a class of hardware.
| Protocol | Hardware | Port |
|---|---|---|
| Intel AMT | Intel vPro business laptops and desktops | 16992, 16993 (TLS) |
| DASH | AMD PRO systems with enterprise NICs | 623 |
| IPMI | Server baseboard management controllers | 623 |
Consumer hardware does not implement these controllers regardless of CPU brand. AMT requires an Intel vPro processor paired with a supported management NIC. DASH requires an AMD PRO system with an enterprise NIC. IPMI is a server baseboard management controller.
Device eligibility
The gateway pings the local subnet and probes each responding host with a WS-Man identify request on the AMT ports (16992 plain, 16993 TLS) and DASH port 623. A host is recorded as manageable only when it answers and the identify response carries the Intel/AMT or DASH signature. The signature check prevents unrelated services on those ports from being reported as OOB devices.
Eligibility has two levels:
- Discoverable: the controller answered the identify probe. The device appears in the Discovered / OOB list with its provider (AMT, DASH, or IPMI), firmware or ME/AMT version, and provisioning state.
- Operable: AMT is provisioned and the organization has supplied admin credentials, so power, console, and inventory commands run. A device that is AMT-capable but unprovisioned appears in the list, but its commands remain disabled until it is provisioned.
A fleet of vPro laptops appears in the list on the first scan. They are discoverable but not operable until AMT is provisioned and credentials are configured.
Provisioning dormant vPro
Many business-class machines ship with Intel AMT present in the chipset but not configured. They appear in the list as discoverable and unprovisioned. Because the ET Ducky agent already runs on the host with system privileges, it configures AMT locally through the Intel Management Engine Interface, without an external tool or BIOS access. This uses Intel host-based configuration, which places AMT in Client Control Mode. From the OOB candidates view, an operator clicks Provision on a row. The agent activates AMT, generates an admin password, and stores it encrypted in the platform. The host then becomes operable and is managed through the gateway like any other AMT device. Under Client Control Mode, KVM sessions require a six-digit consent code shown on the target's screen.
Operable devices expose a text serial console over AMT Serial-over-LAN, relayed through the gateway. It runs independently of the operating system, so it reaches POST, the firmware menu, boot device selection, and text-mode recovery on a host whose OS is not running.
Discovery and the command path
The gateway runs a discovery sweep at startup and on demand from the dashboard, and reports the results to the cloud. A power command (power on, power off, power cycle, or graceful shutdown) is pushed from the cloud to the gateway over a WebSocket. The gateway executes it against the target controller and returns the result.
Credentials for the target are not stored on the gateway. The cloud issues a short-lived relay token. The gateway exchanges it for the credential, holds the credential in memory for the duration of the command, and discards it afterward. A per-target lease prevents two gateways on the same network from acting on one device at the same time. Each command is attributed to an operator and recorded in an audit log.
Gateway hosting: dedicated device or agent
The dedicated gateway is a Raspberry Pi running a Linux service, connected to the local network and to the cloud on port 443. It runs independently of the hosts it manages, so it continues to operate when those hosts are down.
A regular ET Ducky agent can also serve as the OOB gateway for its network. An organization administrator enables "OOB gateway for this network" in the agent's properties, and the agent begins discovery and relay within one heartbeat. It runs the same gateway code as the dedicated device, authenticated with the agent's existing identity. No separate install, registration token, or hardware is required.
Availability difference between the two
An agent-hosted gateway runs on a managed host, so its out-of-band path is available only while that host is powered on. If the host is off, the OOB path through it is unavailable. A dedicated device does not share this dependency, because it is not one of the managed hosts. The dashboard states this distinction where the role is enabled.
OOB gateways, dedicated or agent-hosted, require a paid subscription. Setup, the eligibility indicators, and the discovery settings are described in the Out-of-Band Management documentation.