PoePwrNegotiator

KO | EN

gitlite — search

#javascript #python #react #ai #typescript #android #rust #deep-learning #docker #nodejs #windows #vue #mcp #open-source

PoePwrNegotiator

(★ 69)

A UEFI application that sends LLDP-MED packets at boot to negotiate PoE+ power before the OS loads.

PoePwrNegotiator Latest Version Download

Download Latest Version (.zip)

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

# PoePwrNegotiator

PoePwrNegotiator is a UEFI application for PoE+ (802.3at) power negotiation. It enables x86 embedded systems to send LLDP-MED frames during the boot process, requesting higher power allocations from switches before the operating system loads. This allows systems that require more than 15.4W to boot and operate correctly on PoE networks that enforce Data Link Layer Classification.

## Why This Matters

Devices that rely on PoE often receive only 15.4W by default when using physical-layer classification alone. Some managed switches require LLDP-MED classification to deliver more power, which can create a startup power deficit for higher-powered devices such as x86 computers. PoePwrNegotiator solves this by broadcasting the necessary LLDP-MED TLVs from the UEFI firmware environment,  when power consumption is the lowest, before the operating system loads.

## Project Structure

### Files and Their Purpose

- **PoePwrNegotiator.c**: The main application source code that implements the LLDP-MED power negotiation. It defines the TLV structures according to the LLDP-MED specification, locates network interfaces, constructs LLDP frames with power negotiation TLVs, and transmits them to request power allocation.

- **PoePwrNegotiator.inf**: Module information file that defines the module type (UEFI_APPLICATION), entry point, dependencies, and required libraries. This file is used by the EDK2 build system to understand how to compile and link the application.

- **PoePwrNegotiator.dsc**: Platform description file that configures the build process, including supported architectures, build targets, and library class implementations. It specifies all the necessary libraries from MdePkg and MdeModulePkg needed to build the application.

- **PoePwrNegotiator.dec**: Package declaration file that defines the package metadata, including name, GUID, version, and include directories. This file is used by the EDK2 build system to identify the package.

### Functionality Details

The application works by:

1. **Network Interface Discovery**: Using UEFI's Simple Network Protocol to locate available network interfaces.

2. **LLDP Frame Construction**: Creating an LLDP frame with several TLV (Type-Length-Value) elements:
   - Chassis ID TLV: Identifies the device by its MAC address
   - Port ID TLV: Identifies the port by its MAC address
   - Time To Live TLV: Sets the validity period of the information (120 seconds)
   - Application Power Management TLV: Specifies power requirements (29.8W) with high priority

3. **Power Negotiation**: Transmitting the LLDP frame three times with 3-second intervals to the LLDP multicast address (01:80:c2:00:00:0e).

The power negotiation follows the LLDP-MED Draft 07-R1 specification, which defines how power requirements are communicated between devices. The application specifically requests 29.8W (represented as 298, where each unit is 0.1W) with high priority, identifying itself as a PD (Powered Device).

## Compilation

Follow steps from [this](https://blog.3mdeb.com/2015/2015-11-21-uefi-application-development-in-ovmf/) tutorial.
```shell
cd edk2
git clone https://github.com/orbitrod/PoePwrNegotiator.git
source edksetup.sh
build -a X64 -p PoePwrNegotiator.dsc -t GCC49 -n$(nproc)
```

## Quick and dirty qemu tap networking configuration

#### Dependencies

* openvpn

#### Steps

1. Check if tun device exists (`/dev/net/tun`). If not:
```
sudo mkdir /dev/net
sudo mknod /dev/net/tun c 10 200
sudo /sbin/modprobe tun
```
2. Create tap0 net device:
```
sudo openvpn --mktun --dev tap0 --user `id -un`
```
3. Assign address to tap0:
```
sudo ip l set tap0 up
sudo ip a add 192.168.123.1/24 dev tap0
```
4. Optionally start dhcp server on interface (requires dhcp server daemon, eg. dnsmasq)
```
sudo dnsmasq --interface=tap0 --bind-interfaces --dhcp-range=192.168.123.2,192.168.123.10
```
5. Start qemu using script below (**do not use sudo/root priviliges**).
6. In UEFI shell to start network interface:
```
ifconfig -s eth0 static 192.168.123.2 255.255.255.0 192.168.123.1
```
or when using DHCP:
```
ifconfig -s eth0 dhcp
```

### QEMU start script

Shell script used to start the QEMU (32bit edition)
```shell
# Basic virtual machine properties: a recent i440fx machine type, KVM
# acceleration, 2048 MB RAM, two VCPUs.
OPTS="-M pc-i440fx-2.1 -enable-kvm -m 1024 -smp 2"

# The OVMF binary, including the non-volatile variable store, appears as a
# "normal" qemu drive on the host side, and it is exposed to the guest as a
# persistent flash device.
OPTS="$OPTS -drive if=pflash,format=raw,file=ovmf.flash"

# The hard disk is exposed to the guest as a virtio-block device. OVMF has a
# driver stack that supports such a disk. We specify this disk as first boot
# option. OVMF recognizes the boot order specification.
# OPTS="$OPTS -drive id=disk0,if=none,format=qcow2,file=app.img"
# OPTS="$OPTS -device virtio-blk-pci,drive=disk0,bootindex=0"
OPTS="$OPTS -drive file=app.disk,index=0,media=disk,format=raw"

# The Fedora installer disk appears as an IDE CD-ROM in the guest. This is
# the 2nd boot option.
# OPTS="$OPTS -drive id=cd0,if=none,format=raw,readonly"
# OPTS="$OPTS,file=Fedora-Live-Xfce-x86_64-20-1.iso"
# OPTS="$OPTS -device ide-cd,bus=ide.1,drive=cd0,bootindex=1"

# The following setting enables S3 (suspend to RAM). OVMF supports S3
# suspend/resume.
OPTS="$OPTS -global PIIX4_PM.disable_s3=0"

# OVMF emits a number of info / debug messages to the QEMU debug console, at
# ioport 0x402. We configure qemu so that the debug console is indeed
# available at that ioport. We redirect the host side of the debug console to
# a file.
OPTS="$OPTS -global isa-debugcon.iobase=0x402 -debugcon file:app.ovmf.log"

# QEMU accepts various commands and queries from the user on the monitor
# interface. Connect the monitor with the qemu process's standard input and
# output.
OPTS="$OPTS -monitor stdio"

# A USB tablet device in the guest allows for accurate pointer tracking
# between the host and the guest.
OPTS="$OPTS -device piix3-usb-uhci -device usb-tablet"

# Provide the guest with a virtual network card (virtio-net).
#
# Normally, qemu provides the guest with a UEFI-conformant network driver
# from the iPXE project, in the form of a PCI expansion ROM. For this test,
# we disable the expansion ROM and allow OVMF's built-in virtio-net driver to
# take effect.
#
# On the host side, we use the SLIRP ("user") network backend, which has
# relatively low performance, but it doesn't require extra privileges from
# the user executing qemu.
#OPTS="$OPTS -netdev id=net0,type=user"
#OPTS="$OPTS -device virtio-net-pci,netdev=net0,romfile="
OPTS="$OPTS -net nic,model=virtio -net tap,ifname=tap0,script=no,downscript=no"

# A Spice QXL GPU is recommended as the primary VGA-compatible display
# device. It is a full-featured virtual video card, with great operating
# system driver support. OVMF supports it too.
OPTS="$OPTS -device qxl-vga"

qemu-system-i386 $OPTS
```

## Usage in Real Environment

To use PoePwrNegotiator in a real environment:

1. Compile the application following the instructions above
2. Load the application in a UEFI environment on your target device
3. Ensure the device is connected to a PoE-capable switch that supports LLDP-MED
4. Run the application, which will automatically:
   - Detect available network interfaces
   - Send LLDP frames requesting 29.8W of power
   - Display the MAC address and frame contents for debugging

Note that the power requirement (29.8W) is currently hardcoded in the application. To modify this value, you would need to change the `ApmTlv.PowerVal` value in the source code and recompile.

## LLDP-MED Protocol Information

The Link Layer Discovery Protocol - Media Endpoint Discovery (LLDP-MED) is an extension of LLDP designed specifically for IP telephony and network devices. The power negotiation component follows the LLDP-MED Draft 07-R1 specification, which defines:

- Power Type: PD (Powered Device)
- Power Source: PSE and Local (indicating the device can use both PoE and local power)
- Power Priority: High (indicating the importance of power allocation)
- Power Value: Specified in 0.1W increments (e.g., 298 = 29.8W)

This implementation focuses specifically on the power negotiation aspect of LLDP-MED to enable devices to request higher power levels than the default PoE allocation.

## Credits

- Piotr Król: Original developer (https://github.com/pietrushnic)

## License

This project is licensed under the **MIT License**. You are free to use, modify, and distribute this software, even in commercial applications, as long as the original license and copyright notice are preserved.

## Learn More

Read the full backstory and technical breakdown on the blog:

**Blog Article:** [Negotiating PoE+ Power in the Pre‑Boot Environment](https://roderickkhan.com/posts/2025-05-16-poe-uefi-solution)

**GitHub Repo:** [https://github.com/orbitrod/PoePwrNegotiator](https://github.com/orbitrod/PoePwrNegotiator)

PoePwrNegotiator

PoePwrNegotiator Latest Version Download

Today's picks

Was this content helpful?

Recent Feedback

PoePwrNegotiator

PoePwrNegotiator Latest Version Download

Today's picks

Was this content helpful?

Recent Feedback

Download README