A centralized DHCP server on an ISP network was logging roughly 200 duplicate request packets per second. The culprit: EdgeOS's relay daemon, dhcrelay3, re-relaying packets that had already been relayed once—a direct violation of RFC 2131 section 4.1.1. Across a network running more than 45 EdgeOS routers with multi-level relay paths, one client DISCOVER request could multiply into a steady flood at the center. The fix took eight bytes and an AI assistant.

How DHCP Relay Loops Multiply Packets

DHCP relays exist because broadcasts don't cross subnet boundaries. When a device needs an IP but has none, it broadcasts a DISCOVER that stays on the local datalink. A relay intercepts that broadcast, stamps the packet's giaddr field with its own interface address, and forwards it as unicast to the central server—which then knows which pool to lease from and where to send the reply. RFC 2131 is explicit: once a packet carries a giaddr, other relays should leave it alone. EdgeOS's dhcrelay3 didn't follow that rule. It only skipped re-relaying if the giaddr matched one of its own addresses; every other already-relayed packet got relayed again. The math gets ugly fast. R1 correctly stamps giaddr and forwards once toward the server. R2 incorrectly re-relays it, sending a second copy with hops bumped by one. Now two packets are in flight, each triggering another re-relay at every subsequent affected hop. The copies fan out instead of adding up—until they hit the BOOTP hops cap of 16. Across 45 routers several levels deep around one server, that multiplication totaled about 200 duplicate requests per second. After the patch: zero.

The Fix: Eight Bytes to Do the Right Thing

dhcrelay3 comes from ISC DHCP, the Internet Systems Consortium's long-running suite now end-of-life in favor of Kea. The source fix is one line near the top of do_relay4(): if a packet already carries a giaddr, return immediately instead of relaying it again. But EdgeOS ships stripped MIPS binaries with no supported path to recompile and reinstall on these routers—which are themselves abandoned hardware from Ubiquiti's community forums with no vendor response to bug reports. The patch replaces an interface-flag check with the correct giaddr test. At offset 0xCF38 in the Octeon build, the original code branched based on whether a downstream flag was set. The patched bytes—printf '\x14\xc0\xff\x56\x8f\xbf\x00\x94'—instead check if giaddr (already loaded into register a2 earlier in the function) is non-zero, and if so, jump to the existing return sequence at 0xCC94. The value was already there; the patch just used it. A MediaTek MT7621 variant uses different byte encodings for little-endian architecture but the same logic.

Where AI Fits in Binary Archaeology

The author is upfront about what AI did and didn't do: "I directed the work and owned the result." The model handled mechanical tasks—proposing which code path to target, checking MIPS instruction encodings, drafting analysis docs. Human verification checked everything against actual disassembly, SHA256 hashes, byte-level diffs, and live relay behavior before anything touched production. That division matters more than the hype. Confirming a value stays in the right register at one specific instruction, or hand-encoding a MIPS jump with its delay slot correct—that's the slow, error-prone work that normally makes binary patching a multi-day specialist job. AI compressed that first pass and changed the economics of the fix.

Abandonware Finally Has Hope

"AI-assisted reverse engineering moves that second option within reach of people who would never have opened a disassembler." That's the real story here. Ubiquiti inherited buggy code from end-of-life ISC DHCP, sat on the bug report, and left customers holding orphaned firmware with no supported path forward. Without vendor patches and without practical recompilation options, the choices were live with the duplicates or edit the binary.

Key Takeaways

  • The bug: EdgeOS dhcrelay3 re-relayed packets that already carried a giaddr, violating RFC 2131
  • The scope: 45+ routers with multi-level relay paths caused ~200 duplicate DHCP requests per second at the central server
  • The fix: eight bytes replacing an interface-flag check with a correct giaddr test at offset 0xCF38 (Octeon) or equivalent on MT7621
  • AI's role: accelerating mechanical reverse-engineering tasks, not replacing human judgment on safety verification
  • After deployment: duplicates dropped from ~200/sec to zero across the entire network

The Bottom Line

This is exactly what hacker culture always promised—if you have the source, you can fix it yourself. Now AI makes binary archaeology accessible to mortals who would've bounced off a disassembler before. When vendors abandon their hardware and their bugs, we're no longer stuck waiting or living with broken behavior. Eight bytes and some AI-assisted legwork just moved orphan firmware from "untouchable" to "fixable."