Back in 2015, I was working on a project to build PoE-powered embedded x86 computers and digital signage systems. These were full Windows 10 Professional machines running Intel Atom processors, designed to simplify deployment by drawing power directly over Ethernet. Our goal was to eliminate the need to run traditional AC power to these devices, which can be costly and impractical in many deployment scenarios. But unlike typical IoT or low-power devices, these were full-fledged x86 computers that required more power than what the standard PoE (802.3af) could deliver, which maxes out at 15.4W at the PSE (Power Sourcing Equipment), such as a PoE network switch or injector.

Our device required about 23W when fully operational, which pushed us into 802.3at (PoE+) territory. In most client environments their PoE+ switches provided the power we needed with no problem. But some environments had network switches that would not give us the additional power.

PoE Standards Overview (IEEE 802.3)

The problem was that our embedded systems only supported physical‑layer classification which is limited to signaling power requirements through resistive detection and pulsed current signatures during initial PoE handshaking. Only relying on this method can be problematic if the switch is configured to require LLDP for Data Link Layer Classification for devices requiring more than 15.4W. Which is a problem because at minimum our computers required at least 18W in order to boot into the operating system. So our systems would initially start to boot, but then eventually shut off before it got into Windows. We were stuck in a frustrating Catch-22, we needed to send LLDP packets to get more power, but we couldn’t even boot the OS to send them.

So What Do You Do When the OS Can't Help?

We did some testing and measured power draw during various phases of the boot cycle. Fortunately, the system's power needs during initial startup (BIOS/UEFI initialization) were low enough to stay under the 15.4W limit. That gave us a brief window to request more power before booting Windows.

So the challenge became: negotiate higher PoE+ power before Windows starts. The answer was to handle LLDP negotiation at the BIOS level, or more accurately the UEFI (Unified Extensible Firmware Interface) firmware. Through our research we discovered that UEFI supports the TCP/IP protocol and has access to the network stack, enabling communication over Ethernet without an OS.

Our first attempt was to work with the motherboard vendor and AMI (the BIOS provider) for a custom firmware build. We signed NDAs and had multiple discussions, but despite our efforts, they ultimately declined to create a custom BIOS for us. After hitting that roadblock and feeling the frustration of stalled progress, I refused to give up. I dug deeper and came across the concept of UEFI applications.

A UEFI application is a type of software designed to run in the pre-boot environment of a computer, managed entirely by the UEFI firmware. These applications are different from traditional programs that run once an operating system like Windows or Linux has loaded. Instead, UEFI applications operate with the services and resources provided by the firmware itself, bypassing the need for an OS.

They are typically stored on a dedicated partition called the EFI System Partition (ESP) and launched by the UEFI boot manager during the system's boot process. These apps can access low-level system functionality, including networking, file systems, and input/output devices. In our case, that meant we could build a standalone tool to t ransmit LLDP packets before the OS even initialized. This was the perfect solution, because it required no changes to the BIOS/UEFI firmware itself. I just needed to find someone with the embedded firmware expertise to bring it to life.

From Warsaw With Code

After some research, I found Piotr Król, a former BIOS software engineer at Intel who was doing freelance work out of Poland. He understood the problem immediately. We set up remote serial and IP-KVM access to our development hardware, and Piotr got to work.

There were some challenges along the way including lack of vendor support, incomplete firmware tooling, and remote hardware limitations. Our system didn't include bcfg, which meant we couldn't persistently change the boot order through standard UEFI tools. Piotr identified this early and suggested using startup.nsh as a workaround, a shell script that would automatically run our LLDP application when the EFI shell launched.

Four months later, Piotr delivered PoePwrNegotiator: a UEFI application written in C that transmits LLDP-MED (Link Layer Discovery Protocol – Media Endpoint Discovery) packets and requests the higher power levels we needed. No OS required. We deployed this UEFI application on all of our PoE devices in production and it worked flawlessly.

Sharing the Solution

This project began as an attempt to solve a very specific challenge we faced nearly a decade ago. I don’t know how many others have tackled this type of problem or taken this approach, but I wanted to share the work in case it helps someone else.

By open-sourcing PoePwrNegotiator, my goal is to preserve and document a unique solution to a problem that may still be relevant to those building PoE-powered x86 systems. If someone out there is working on a similar challenge, or even just wants to understand how UEFI applications can be used to control networking behavior at boot, I hope this gives them a useful head start.

PoePwrNegotiator is released under the MIT License, one of the most permissive open source licenses available. This means anyone can use, modify, or integrate this code into their own projects, commercial or personal, as long as the original license and copyright notice are included. The goal is to make this as accessible and useful as possible to anyone dealing with power negotiation challenges or looking to learn more about UEFI networking.

GitHub Repo: https://github.com/orbitrod/PoePwrNegotiator

Special Thanks

Carlos, you were instrumental during the testing and the deployment of this application. You were my right hand throughout this project and far beyond it, and your dedication to me and to the work we were doing will never be forgotten. I cannot express enough how much your loyalty and commitment meant to me throughout that entire journey.

Piotr, thank you for being brilliant, resourceful, and incredibly effective. Your deep expertise in firmware helped us solve a problem others wouldn’t touch. I’m grateful for your expertise and contribution to our project, your work solved the last piece of the puzzle.

This project reminded me that innovation often comes from working around limitations, not just within them. PoePwrNegotiator was a solution to a very specific challenge I faced in 2015, but the lessons and approach still feel relevant today. If it sparks ideas, helps someone overcome a similar obstacle, or contributes in any way to future PoE-powered system design, that’s all the reason I need to put it out there.

— Roderick