EAP225-Outdoor-CA Bricked

Greetings all!

I have an EAP225-Outdoor with the Canadian firmware. It used to be the US firmware but had flashed it with the stock CA firmware by mistake some time ago. I followed the instructions in this thread which adds the CA certificate into the OpenWRT firmware: TP-Link EAP245 v3 "Bad file." when attempting to flash - #8 by svanheule

I realize that thread references the EAP245 but all this script appears to be doing is moving the signed certificate from the stock bin into the OpenWRT factory bin. At least that was the theory. :slight_smile:

The stock version of firmware used was 1.6.1 Build 20191224.

The version of OpenWRT used was the version downloadable from the device page here: https://openwrt.org/toh/hwdata/tp-link/tp-link_eap225-outdoor_v1

The python script to patch the firmware ran successfully and the stock GUI on the unit flashed it just fine with no error. Unfortunately the unit has never come back online and the LED no longer illuminates when powered.

Any advice on what the next steps might be in troubleshooting?

The wiki is kind of thin when it comes to product details.

Check if there's a TFTP client calling if you do a reset+power on.

If not, serial console is the next step.

I did turn on the TFTP service on the Synology NAS in my network but did not see any requests to it after a few power cycles on the device.

If I understand correctly from the threads I've read here, the serial console requires soldering a UART onto the board directly. That's a bit out of my wheelhouse so I may just have to abandon if there's no other way.

Appreciate the suggestion Frollic.

@svanheule I'm curious if you think there would be anything in that script that you linked in the EAP245 thread that would cause this issue on the EAP225? At the very least, if you do think there's a reason the script would only work on that EAP245 then it may save others with the 225 from bricking.

As far as I know, the script should be able to patch the product-info partition into a firmware file for the EAP225-Outdoor too: it uses the same firmware image format as the other APs in that series. The fact that the AP happily accepted the patched FW image, most likely means it worked as intended.

Can you by chance post the exact command that you used? The FW images you listed appear to be the correct ones, as long as you used an OpenWrt factory image.

That fact that the LED doesn't even turn on any more, doesn't sound very encouraging though... :confused:

Took the exact command from scrollback. I ran this off my Ubuntu 20.04.LTS VM if that has any relevance.

./patch-safeloader.py --factory openwrt-ath79.bin --input EAP225-Outdoor-ca.bin --patch product-info --output factory-ca.bin

I can post all three bin files if that would be useful as well.

On most routers, when the power is first turned on all the LEDs come on for a fraction of a second then most or all of them go out. If they don't do that (either don't come on(*) or come on and stay on) that usually means the bootloader didn't start-- the bootloader code in flash is erased or corrupted. This is rather dire, it will require a SPI chip programmer to recover.

  • of course no LEDs lighting at all also raises the question if the unit is receiving power.

Looks good to me. Like @mk24 noted, if the LED isn't turning on at all, it's going to be either power or a borked bootloader. There is no uboot upgrade in the OpenWrt factory image, so it seems very strange if the upgrade would've touched that.

@svanheule and @mk24 I certainly can't rule anything out as it relates to power. Just so it's said, the unit is PoE exclusively, there is no DC in on this model. It was upgraded while plugged in (of course) with no change to the switch itself. The unit just never came back after the reboot post flash.

But again, we shouldn't rule anything out. I'll pull it down from its mount and attempt to power it from another source and report back.

I've taken the unit down from its mount outside and moved to my kitchen table with a test rig using a Trendnet POE switch and a (working) EAP245 as the test to verify the rig is providing proper power.

Here is the video: https://drive.google.com/file/d/1nXTL0qi6da9q7dJN3IFsIs7rcbMvZCrp/view?usp=sharing

As you can see from the video, the EAP245 powers on and access attempts can be seen on the link lights. When plugging in the EAP225-Outdoor the unit does not show any status change on the LED. There is a link light on the switch but nothing to indicate activity. I've left the 225 plugged in for some time on that rig and left the camera recording just to make sure there wasn't a data attempt that I missed. I'll spare you the uploading of that footage to say that there isn't a change. :slight_smile:

Any next steps from here beyond buying an SPI chip programmer or sending it to the recycling center? Happy to open it and provide an images of the board if there's any use in that.

Appreciate you all being so kind in talking this through even if it goes nowhere.

it does seem bricked,

the only thing i could find on the tp link site that may be helpful is trying to reset it, just to see if that brings it back to some state where you see lights:


Q15: How to manually restore the EAP device to the factory defaults?

A: With the device powered on, press and hold the RESET button for about 5 seconds until the LED flashes red/green/yellow alternatively twice, then release the button. The device will restore to factory default settings.

from the threads below, however i think she's DONESKIS. i hope i'm wrong, and i think the first link is you lol:

HA! Indeed it does look like she's pining for the fjords. I'll give these links a shot and report back this evening.

No joy on the reset procedure. I should note that first link is in fact not me. There was a period of time where just searching on Google for "EAP225 Outdoor Firmware" returned the Canadian page and that confused a lot of people, myself included.

you should try to connect to to it via serial, it'd be fun.
who knwos, maybe it has the header already on it

i know the r6800v2 did (netgear)

Finding the serial port will be fun, but it won't be plug-and-play :wink:

This post and the following ones describe how to open the device, and where to find the UART pads:

1 Like

i stand corrected and agree with you lol.

@svanheule thanks for sharing that! I, like the OP of that thread, am also not adept with a soldering iron but I do have a buddy that is. I'll have to buy the beer of course, but it'll be worth a shot. (no pun intended)

The release notes for FW v5.0.3 contain the following:

  1. Fixed the bug that the EAP may reboot abnormally during firmware upgrading and cause the device to brick.

So it sounds like you probably weren't the only one that got bitten by a bricked AP.

1 Like

Oh! Well actually that makes me feel much better frankly. Thanks for passing that along!

It does look like code is fine and the bricked one could be related to the 5.0.x firmware bug - I've managed to get mine to work without issues.

  • Started with 1.6.1 Canadian firmware installed on EAP225-outdoor
  • Patched latest factory image snapshot with patch-safeloader.py using the same 1.6.1 Canadian firmware as input/source of certs
  • Installed using EAP225-outdoor web interface (directly on AP, not through a controller)

No issues, works fine.

Next I'll see if I can get rid of region from /dev/mtd2 and install a recent stock US firmware with tp-linksafeloader.

@svanheule you wouldn't happen to have a copy of mtd2 from a US one laying around would you? (I'm not sure if it contains keys/certs in addition to MACs, like the CA one)

I have a spare EAP225-outdoor that I can risk for science and I won't be breaking any laws by switching from CA firmware - I've moved out of Canada recently.

If you don't mind compiling a small piece of code, you can actually use tplink-safeloader from the OpenWrt sources to extract the different partitions from US firmware from the TP-Link website. The reason you can convert a US device to a CA device, is precisely because the CA image contains information that gets written into the "info" partition (mtd2).

From tplink-safeloader.c

	/** Firmware layout for the EAP225-Outdoor v1 */
		.partitions = {
			{"fs-uboot", 0x00000, 0x20000},
			{"partition-table", 0x20000, 0x02000},
			{"default-mac", 0x30000, 0x01000}, <-- MTD2 STARTS HERE 
			{"support-list", 0x31000, 0x00100},
			{"product-info", 0x31100, 0x00400},
			{"soft-version", 0x32000, 0x00100}, <-- LAST PART OF MTD2
			{"firmware", 0x40000, 0xd80000},
			{"user-config", 0xdc0000, 0x30000},
			{"mutil-log", 0xf30000, 0x80000},
			{"oops", 0xfb0000, 0x40000},
			{"radio", 0xff0000, 0x10000},
			{NULL, 0, 0}

So, (without experimental verification) you would need to start by extracting mtd2 from the device you want to convert to a US-version. Inside this 64kB blob, you need to replace the bytes starting at offset 0x1100 with a modified product-info blob from a CA image. You should be able to do this with dd, but you will need to experiment with the offset and truncation options.

  1. BACK UP ALL PARTITIONS (and hope you don't nuke u-boot if you manage to write data to the wrong place)
  2. Extract mtd2 partition from your device, since it contains the device's MAC address
  3. Download CA image and extract partitions with tplink-safeloader
  4. Modify "product-info" from the CA image with your favourite hex editor
    1. Remove (11) bytes containing "region=CA\r\n"
    2. Update the first four bytes, containing the partition length. E.g. if the unmodified blob has 0x000001FA, then the byte count should be 0x202 (size in header + 8). Since you are removing 11 (0xB) bytes, the new value in this case would be 0x00001ED.
      Bonus: If "region=CA\r\n" is at the end of the partition, it should actually be sufficient to update only the embedded partition length.
  5. Write the modified blob into the extracted mtd2, at offset 0x1100. (Check that this contains similar info as the one you just modified).
  6. Flash the modified mtd2 (check out kmod-mtd-rw)