Enterprise Wi-Fi access points are strange little computers. They cost hundreds of dollars new, they run a full Linux system under the hood, and once a company retires them they're often worth almost nothing on the used market - because without an active management license from the vendor, they're locked into a walled garden you can't really use. I picked up an Extreme Networks AP-7562 for cheap with exactly that in mind: could it run OpenWrt instead - open-source router firmware - and become a genuinely useful device again?

This post is the story of that project: getting into the hardware, building Linux support for a board nobody had ever documented, and a multi-week detective story around a flash memory chip that flatly refused to behave the way it was supposed to.

A Quick Note on Legality and Licensing

None of this involves cracking any encryption or breaking into someone else's network - it's my own hardware, and reverse-engineering a device you own to make it interoperate with other software is well-established, legal territory. It's the same basic right that underpins the whole third-party firmware community (OpenWrt, DD-WRT, and friends).

There's also a licensing angle worth spelling out: the AP-7562 runs Linux and U-Boot under the hood, both licensed under the GNU General Public License (GPL). The GPL's core deal is simple - you're free to use, modify, and redistribute the software, but if you distribute a device running it, you're obligated to make the corresponding source code available to whoever receives it. That obligation applies to Extreme Networks here, regardless of whether they've made it easy to find.

Extreme does maintain an open source declaration page, but it's a list of license-attribution PDFs rather than actual source downloads, and it doesn't have an entry for this specific device or WiNG version at all. Getting the real GPL source would mean formally requesting it through their compliance contact - something still on my to-do list, and a good reminder that "open source declaration" pages don't always mean what they sound like.

What's Actually Inside One of These

Cracked open, the AP-7562 is built around a Broadcom BCM53016 - a system-on-chip from Broadcom's "Northstar" family, the same chip family used in some Meraki and D-Link access points. It has:

  • An ARM processor running the show
  • 512MB of NAND flash - the chip that holds the operating system and all its files, similar in spirit to an SSD but much smaller and slower
  • 512MB of RAM
  • A Broadcom BCM43460 Wi-Fi radio
  • A vendor operating system called WiNG, Extreme's proprietary firmware

The goal was to replace WiNG with OpenWrt entirely. That meant getting Linux to boot on hardware nobody outside Extreme Networks had ever written proper support for, and that turned out to be a much longer road than expected.

Step One: Finding a Way In

Most enterprise networking gear has a serial console port on the board itself - a leftover from manufacturing and debugging - that gives you a raw text terminal straight into the boot process, no network required. Finding it meant opening the case, identifying which set of pins were the console (a bit of trial and error with a multimeter and a USB-to-serial adapter), and wiring it up.

Once connected, the payoff was immediate: watching the device boot showed the bootloader in action. A bootloader is the tiny program that runs before the operating system even loads - it initializes the hardware and then decides what to boot into. This device runs U-Boot, a very common open-source bootloader used across all kinds of embedded devices, and - crucially - it turned out to be reachable without a password. Interrupting the boot process at the right moment dropped straight into a U-Boot shell with full read/write access to the hardware.

This was the actual key that unlocked the whole project. From here I could load and run arbitrary code on the device over the network via tftpboot (U-Boot's built-in "fetch a file over the network and boot it directly from RAM" command), without touching anything already stored on the flash.

Step Two: Teaching Linux About This Board

Getting a generic Linux kernel to run on a specific piece of hardware requires a device tree - a file that describes exactly what's connected to the chip: where the UART is, where the network controller lives, what the flash chip looks like, and so on. Since nobody had ever written one for this exact board, that meant building it from scratch, using the closest publicly-documented sibling board (a Meraki access point using the same chip family) as a starting template and adjusting piece by piece until real hardware responded correctly.

The first successful boot was a genuine milestone: a real Linux kernel, running on this specific board, for the first time ever. It came up far enough to load kernel modules and start a shell - but with no working network at all. Debugging that turned into its own little saga: it took three separate, compounding bugs (a mis-configured network switch setting, a missing property that told the kernel how the physical link was wired, and a script that was configuring the wrong network interface entirely) before ping finally worked.

There was also a wonderfully frustrating build-system trap along the way: OpenWrt's build system has a "fast" rebuild command that skips reprocessing certain files if you've only touched the kernel - except one of the fixes lived in exactly one of those skipped files. Every rebuild silently continued to produce the old, broken configuration despite the fix genuinely being in the source tree. Once that was caught, the real fix took effect immediately.

With a real IP address and SSH access working, everything got dramatically faster. Up to that point, every test cycle meant reading text scroll by on a serial terminal at 115200 baud. Now there was a real shell, and a real feedback loop.

Step Three: The Wi-Fi Radio That Nobody Recognized

With basic Linux working, the next target was the onboard Wi-Fi radio. Immediately hit a wall: the chip identified itself as a BCM43460, and that specific chip ID simply isn't in the mainline Linux Wi-Fi driver's list of recognized hardware. The driver would load, scan the PCI bus, see the device... and shrug.

The fix itself was small - a handful of lines added to the driver's internal lookup tables, treating the BCM43460 as a close sibling of a chip generation the driver already understood. After that, the driver successfully recognized the hardware, correctly identified its exact revision, and got all the way to the last step: loading the actual radio firmware file.

And there it hit the real wall. The firmware Linux needed simply didn't exist anywhere accessible - it wasn't bundled with OpenWrt, and it wasn't sitting in an obvious place on the device. The only realistic option left was to go looking for it inside the AP's own flash storage, on the theory that the original vendor firmware must have shipped some file the radio could use, even if it wasn't in a place or format the open-source driver expected by default.

That sent the whole project down a completely different rabbit hole: how do you actually read the NAND flash chip from Linux, on a board where nobody had ever gotten that working either?

Step Four: The NAND Flash Chip That Wouldn't Cooperate

This is where the project turned into a genuine multi-week debugging marathon, so I'll compress it - the full blow-by-blow lives in the project's technical notes if you want the gory details.

A quick primer: talking to a raw NAND flash chip isn't like reading a file. The kernel has a whole subsystem (called MTD, Memory Technology Device) dedicated to it, and the very first thing any NAND driver does is send an "identify yourself" command to the chip and read back its response, the same way a USB device announces its vendor and product ID when you plug it in.

That identify command never completed on this hardware. The chip would sit there, and the specific status bit the driver was waiting for simply never flipped. This wasn't a timing issue or a fluke - it was completely consistent, boot after boot.

Frustratingly, a much simpler, hand-written test program - one that skipped identification entirely and just issued a basic "read this page" command directly - worked perfectly. It could read real, valid data from the flash chip reliably. So the hardware clearly worked. Something about the standard identification handshake specifically was broken on this board.

Writing a Custom Driver (Take One)

The natural next step: skip the standard driver's identification step entirely, hardcode what we already knew about the chip (a 512MB Macronix chip with a known page and block size), and drive the "just read a page" command directly, the same way the working hand-written test did.

This worked... for exactly one read. Every read after the very first one returned the exact same data, no matter what address was actually requested. Reading four completely different files kept getting the same bytes back, byte for byte. Something in the chip's internal "here's the data you asked for" cache was getting stuck, and no combination of register tweaks - clearing status flags, adding memory barriers, matching the reference driver's exact sequence line-for-line - budged it even slightly.

The Breakthrough: A Secret Shortcut

The turning point came from research rather than more debugging. While reading through the source code for a different, unrelated access point that happened to use a closely related chip, I found something interesting: some chips in this family expose a chunk of their flash storage directly into the processor's own memory map - meaning you can read it exactly like reading any other block of memory, no special commands or identification handshake required at all, bypassing the entire broken mechanism.

That specific board didn't use this trick for its NAND flash - it only used it for a small, separate memory chip. But testing the idea against this device's own memory address turned out to be exactly right: reading from that address returned real, meaningful data, and it matched what the broken standard driver had originally managed to read before getting stuck.

The Catch: A Fixed-Size Window, and a Real Crash

The obvious next move was to treat this shortcut as full access to the entire 512MB chip. That did not go well - reading a location deep into the flash immediately crashed the device outright, with the kind of hardware fault that arrives after the fact. Picture a smoke detector that only starts beeping several seconds after the smoke has already cleared - by the time the alarm goes off, there's no reliable way to know which specific action actually caused it. That's roughly what happened here: the processor reported a fault, but too late and too vaguely for software to catch it safely or recover gracefully. The device simply rebooted.

So instead of guessing, I mapped the actual boundary directly: reading known checkpoints at increasing distances, watching carefully at each step, until the safe range was narrowed down precisely. The shortcut turned out to be a fixed 64MB window, not full access to the whole chip - a hardware limitation, not a bug in the approach. The final driver hard-caps every read well inside the confirmed-safe boundary, so there's no way for ordinary use to trigger that crash again.

Proving It Was Real

With a safe, working driver in place, the last step was verifying the data was genuinely what it claimed to be, rather than some coincidental garbage that happened to look plausible. Two independent confirmations landed cleanly:

  • The exact "magic number" that marks the start of a JFFS2 filesystem (a filesystem format designed specifically for raw flash chips) showed up at exactly the byte offset where the root filesystem was expected to start, followed by a real, correctly-formatted directory entry.
  • Reading further in turned up the device's actual running kernel version string, compiler version, and build date, baked right into the firmware image - genuine, recognizable Linux boot text, not noise.

That was enough to back up everything within the safe range and start digging through it for real - confirming the underlying filesystem format, the dual-image failover scheme the device uses for firmware updates, and clues about how the original Wi-Fi driver stack is put together (a separate, older Broadcom driver naming convention entirely - which at least explains why the firmware file was never going to be named or shaped the way the modern open-source driver expected).

Where Things Stand

Right now: OpenWrt boots cleanly on the AP-7562, Ethernet works, there's real SSH access, and roughly an eighth of the flash chip - including the very start of the live filesystem - is readable safely and has been backed up and verified. The Wi-Fi driver itself now correctly recognizes the hardware; it's specifically the firmware file that's still missing, and the search for it continues through the backed-up flash data.

A few things left to chase:

  • Extending safe access further into the flash, to reach the parts of the filesystem more likely to hold the radio firmware
  • Finishing the Wi-Fi bring-up once the firmware is located
  • Formalizing the various kernel patches into something that could realistically be upstreamed for the next person who finds one of these on the used market

It's the kind of project that reinforces something I keep relearning: on real hardware, the official, well-documented path sometimes just doesn't work, and the actual fix is often a strange little side door nobody wrote down anywhere - the trick is being willing to go looking for it.