Dual-Ethernet Mini PC: How to Choose and Verify the Wake-on-LAN Port

The short answer

On a dual-Ethernet mini PC, Wake-on-LAN is verified per port, not per machine. Each jack is a separate Realtek instance with its own MAC and its own arming path, so map the physical jacks to Windows adapters first, run a five-cycle WOL test on the port you plan to manage with, and standardize on that port.

This page documents that process on our Beelink EQi12, which has two Realtek PCIe gigabit jacks. One port carries a complete measured record — jack-to-adapter mapping, a 4 GiB bidirectional throughput run, and 5/5 Wake-on-LAN passes from both S5 and S3 — and the second port illustrates why the mapping step matters even when you never use it. All raw logs are in the EQi12 Measurement Data repository under CC BY 4.0.

Why two jacks make WOL verification harder, not easier

A second Ethernet port sounds like redundancy, but for Wake-on-LAN it doubles the configuration surface:

• Two adapter instances, two MACs. Windows loads the same Realtek driver twice, as Ethernet and Ethernet 2. A magic packet is addressed to a MAC, so a packet sent to the MAC of the idle jack wakes nothing even if the machine “supports WOL”.
• Two arming paths. The driver’s Wake-on-LAN setting, the wake-armed device list (powercfg /devicequery wake_armed) and the BIOS PME option can all be correct for one instance and unset for the other. This is the same per-instance logic behind the single-port symptom “WOL works from shutdown but fails from sleep” described in the state-specific troubleshooting guide — with two ports, you can be debugging the wrong instance without realizing it.
• Ambiguous naming. Neither the adapter name nor the #2 suffix in Device Manager tells you which physical jack you plugged into. Only a mapping test resolves this.

The failure mode is subtle: WOL “works”, then a cable swap or a BIOS reset silently moves the LAN to the other jack, and the machine stops waking. If you have already been through the 12-cause WOL checklist and the adapter settings all look right, an unverified port mapping is cause number thirteen.

What we measured on the EQi12’s two jacks

All measurements are from 2026-07-12 on a Beelink EQi12 (Windows, dual Realtek PCIe GbE). Raw files: EQi12_双物理网口对应与NIC1双向测速结果.txt, EQi12_S5_WOL_5cycles.log, EQi12_S3_WOL_5cycles.log in the measurement repository.

Fact block — dual-port mapping, throughput and wake results (source: eqi12-measurement-data, test date 2026-07-12):

The honest reading of that table: our wake record belongs to jack 1. The second jack passed its mapping test and shares the same driver family, but we have not run an independent five-cycle WOL series against it — and we do not claim it works. That is exactly the discipline this page recommends.

Step 1 — Map the physical jacks to Windows adapters

The MAC address is the only reliable bridge between the physical jack and the adapter instance:

1. List the adapters and their MACs:

Get-NetAdapter | Format-Table Name, InterfaceDescription, MacAddress, Status

2. On the EQi12 this shows Ethernet (Realtek, MAC ending 8E) and Ethernet 2 (Realtek #2, MAC ending 8F).
3. Plug the LAN cable into one jack, confirm which adapter flips to Up, and write the pair down. Repeat for the second jack if you plan to use both.
4. Confirm the active pair with traffic, not just a link light. Our mapping run was a 4 GiB bidirectional iperf test on the 8E jack:

Both directions landed close to real-world gigabit, which confirms two things at once: the mapping is right, and the jack can carry a media-server or backup workload without being the bottleneck. A jack that only negotiates 100 Mbps or drops packets under load is a poor management port even if its WOL works.

Step 2 — Verify WOL on the port you intend to manage with

The verification protocol is the same five-cycle series we use across every WOL article on this site:

1. Arm the adapter instance — in Device Manager, the Realtek instance bound to your chosen jack needs Wake-on-LAN enabled in the Advanced tab and the wake-armed list confirmed:

powercfg /devicequery wake_armed

If the setup details are unfamiliar, follow the Realtek RTL8111 Wake-on-LAN setup guide — it walks the driver, BIOS and sender configuration on this same machine.

2. Send magic packets continuously to the jack’s MAC (we used UDP ports 7 and 9 every 15 seconds from a peer machine on the same LAN).
3. Run five S5 cycles and five S3 cycles, recording powercfg /lastwake, the event log and the service recovery time each round. On the EQi12’s jack 1 the result was 5/5 from S5 (with Wake History Count - 0 every round, as expected after a true soft-off) and 5/5 from S3, with the network stack back in about 3.6 seconds.
4. Verify the workload, not the ping. Our S5 Jellyfin container needed 35.8 to 52.0 seconds to answer HTTP after the wake; a ping-only test would have hidden most of that.

Why five cycles and not one: our first S3 series produced a slow-resume outlier that only appeared on the fifth cycle. The state-verification details — including how Fast Startup can turn your “shutdown” into S4 and corrupt the test — are in Windows Fast Startup and Wake-on-LAN: S4 vs S5.

If you use both jacks, verify both. Same protocol, second MAC, separate record. A port that wakes 5/5 from S5 but fails from S3 is not a failed port — it is a characterized one, and you standardize on the state that passes.

Step 3 — Standardize and document the choice

Once a port passes, freeze it:

• Cable discipline. The management LAN stays on the verified jack. Label the jack physically; a taped label on the chassis beats any documentation file at 2 a.m.
• MAC discipline. Magic-packet senders, router DHCP reservations and any scripts reference the verified MAC (…FF-8E in our case), not an adapter name that Windows may renumber after a driver update.
• Re-verify after changes. A BIOS update, a Realtek driver update or a Windows power-management change can re-arm (or disarm) one instance and not the other — the same re-test trigger rule the Realtek setup guide applies to single-port machines.

If you are deciding the whole power strategy around this port — sleep versus shutdown versus AC-recovery fallback — the state-by-state matrix in Wake from S5: What PME, RTC Alarm and Wake-on-LAN Actually Do covers what each ACPI state does to the NIC, and AC power recovery is the fallback for machines whose WOL cannot be trusted.

Common failure patterns on dual-port machines

Where this fits in the cluster

• State definitions and BIOS-side wake sources: Wake from S5: PME, RTC Alarm and Wake-on-LAN
• Ranked causes of WOL failure: WOL Not Working: 12 Causes
• Driver-level setup for the Realtek instances: Realtek Wake-on-LAN for Windows
• Guided diagnosis instead of a checklist: WOL Troubleshooter tool
• Planning the whole machine around power and wake: Windows Mini PC Home Server Roadmap

The raw dual-port mapping and throughput record — EQi12_双物理网口对应与NIC1双向测速结果.txt — plus both five-cycle WOL logs are published in the EQi12 Measurement Data repository and can be cited freely under CC BY 4.0.