I'd like to get my EAP 225 Outdoor running with OpenWRT. Is it the same procedure?
Details about the EAP225-Outdoor can be found in the other topic: Anyone working on TP-Link EAP225?
The flashing procedure is what @pdecat quoted, and is the same as on EAP245v3, EAP225v3, and EAP225-Wall. See the respective commit messages for more info.
I haven't heard about anyone having issues the 2.4GHz radio; this is the same on all the EAP-devices. Maybe you could post a dmesg output (or logread) in the other thread if there's any warnings.
1 Like
Good news everyone! EAP245v3 support has been merged 
Links to commit and snapshot images at https://openwrt.org/toh/hwdata/tp-link/tp-link_eap245_v3
3 Likes
How can I contribute to getting the EAP245v1 device supported?
The EAP245v1 is included this pull request:
There are two network driver patches, which might make it take a bit longer to get reviewed. But I already got feedback on those a few weeks ago, so hopefully it can be merged soon-ish.
3 Likes
I'm hoping someone can help. I've got myself in a bit of a "bad place" with my EAP245 v3...
I loaded up OpenWRT. Then something happened and the unit will not boot cleanly anymore.
I tried the reset button and having it pull the TP-Link firmware via tftp. I tried loading the TP-Link Firmware via the Recovery Web Interface (will not take). I can Ctrl-B and then boot OpenWrt with the "bootelf 0x9f0c0000" command.
I have access via UART port to the console. Boot shows me this and goes directly to the Recovery Web Interface....
U-Boot 1.1.4--LSDK-10.2-00082-4 (Mar 19 2018 - 14:55:50)
board956x - Dragonfly 1.0DRAM:
sri
ath_ddr_initial_config(287): (ddr2 init)
ath_ddr_initial_config: DDR_EMR2_ADDRESS=0x180000bc, EMR2 value=0x80
ath_sys_frequency: ref_clk 25000000
ath_sys_frequency: cpu 775 ddr 650 ahb 258
Tap values = (0xf, 0xf, 0xf, 0xf)
128 MB
Top of RAM usable for U-Boot at: 88000000
Reserving 454k for U-Boot at: 87f8c000
Reserving 192k for malloc() at: 87f5c000
Reserving 44 Bytes for Board Info at: 87f5bfd4
Reserving 36 Bytes for Global Data at: 87f5bfb0
Reserving 128k for boot params() at: 87f3bfb0
Stack Pointer at: 87f3bf98
Now running in RAM - U-Boot at: 87f8c000
Flash Manuf Id 0xef, DeviceId0 0x40, DeviceId1 0x18
flash size 16MB, sector count = 256
Flash: 16 MB
*** Warning - bad CRC, using default environment
In: serial
Out: serial
Err: serial
Setting 0x181162c0 to 0x40802100
Hit Ctrl+B to stop autoboot: 0
[NM_Error](nm_api_checkInteger) 00373: factory boot check integer flag is not 1.
Net: ath_gmac_enet_initialize...
No valid address in Flash. Using fixed address
ath_gmac_enet_initialize: reset mask:c02200
athr_mgmt_init ::done
Dragonfly ----> S17 PHY *
athrs17_reg_init: complete
SGMII in forced mode
athr_gmac_sgmii_setup SGMII done
: cfg1 0x80000000 cfg2 0x7114
eth0: 00:03:7f:09:0b:ad
eth0 up
eth0
Trying eth0
dup 1 speed 1000
HTTP server is starting at IP: 192.168.1.1
HTTP server is ready!
If I try and install the TP-Link 2.21.0 (or any of the 3 TP-Link available versions) I get this error in the console...
Firmwave supports EAP245(TP-Link|UN|AC1750-D):3.0, check OK..
Firmware Recovery check ok!
set integer flag to 0.
[NM_Error](nm_updateDataToNvram) 00652: memory malloc failed.
[NM_Error](nm_upgradeFwupFile) 01666: updateDataToNvram failed.
[NM_Error](nm_tpFirmwareRecovery) 01627: upgrade firmware failed!
Web recovery failed type 0.
## Error: HTTP ugrade failed!
Do you know what that "something" is, or did it just suddenly stop working?
A failing malloc sounds pretty bad. But as I understand, you can still boot into OpenWrt (at 0x0c0000) if you skip the second u-boot (at 0x040000)? If so, could you extract the extra-para, factory-uboot, and u-boot partitions?
Last thing I recall is trying to install a newer snapshot sysupgrade.bin via the Luci Web interface.
After the booting issue happened I opened up the unit to do the UART pins and jump the 2 R locations. The unit was never opened before this.
Is this line in the bootlog "normal" after the OpenWrt install ?
[NM_Error](nm_api_checkInteger) 00373: factory boot check integer flag is not 1.
I have exported the 13 MTD blocks (as of last night) and the 2 u-boot blocks look "ok". The extra has the following...
00 00 00 02 00 00 00 00 01 00 FF FF FF FF (then all FF after that).
Here's the output from /proc/mtd when force booted into OpenWrt...
dev: size erasesize name
mtd0: 00040000 00010000 "factory-boot"
mtd1: 00040000 00010000 "u-boot"
mtd2: 00010000 00010000 "partition-table"
mtd3: 00010000 00010000 "info"
mtd4: 00010000 00010000 "art"
mtd5: 00010000 00010000 "extra-para"
mtd6: 00e40000 00010000 "firmware"
mtd7: 0020c8d4 00010000 "kernel"
mtd8: 00c3372c 00010000 "rootfs"
mtd9: 00910000 00010000 "rootfs_data"
mtd10: 00030000 00010000 "config"
mtd11: 00080000 00010000 "mutil-log"
mtd12: 00040000 00010000 "oops"
I've been searching to see if there's a way to go back to the original TP-Link firmware. Going thru the 2 different processes, Recovery Boot Web or Reset button and TFTP EAP245v3_up.bin. Both seem to fail with a memory alloc error (passing the Sig checks). I'm wondering if somehow the MTD block/partition sizes got mashed or if that "factory boot check integer flag is not 1" is causing the issue. Just have no clue where or what that is.
No, that doesn't seem right.
My (older) boot log has:
Hit Ctrl+B to stop autoboot: 0
factory boot check integer ok.
When flashing an upgrade, the firmware sets the first by of extra-para to 01, but that appears to be ok.
These are the MD5 checksums of the partitions I extracted earlier:
75d083f3868449543348bd8d688fb4b1 mtd0.bin
455cc6aeacd0b29e5b8de05b629caec2 mtd1.bin
01ab0ef5eac86b803f2bec63529ffbc0 mtd2.bin
ecf76d18e8c7d2e8259fab88acb18b94 mtd3.bin
f517ee2ca113748b7548c14e788567aa mtd4.bin
8de609f661e2d576a0b676e33d7ae66f mtd5.bin
The 1st 2 [mtd0 and mtd1] u-boot match yours...
mtd3 which is device specific with the base MAC Address and other device specific info should not match yours. But, looking at the raw data I see the correct info.
75d083f3868449543348bd8d688fb4b1 OpenWrt.mtd0.bin
455cc6aeacd0b29e5b8de05b629caec2 OpenWrt.mtd1.bin
2bf5dc1f06de60409b2d9d916e01d780 OpenWrt.mtd2.bin
766dd7519d8cb5e1dd4bfde971fe0933 OpenWrt.mtd3.bin
959ff63492f23bf535860460f2e4cf2a OpenWrt.mtd4.bin
b054b87d319322f92a8c2190dc36a605 OpenWrt.mtd5.bin
I just noticed the raw data on mtd2 (partition-table) looks strange on mine, character flip..
"factroy-boot" instead of "factory-boot"..
Text....
partition factroy-boot base 0x00000 size 0x40000
partition fs-uboot base 0x40000 size 0x40000
partition partition-table base 0x80000 size 0x10000
partition default-mac base 0x90000 size 0x01000
partition support-list base 0x91000 size 0x00100
partition product-info base 0x91100 size 0x00400
partition soft-version base 0x92000 size 0x00100
partition radio base 0xa0000 size 0x10000
partition extra-para base 0xb0000 size 0x10000
partition os-image base 0xc0000 size 0x20c888
partition file-system base 0x2d0000 size 0xb70000
partition config base 0xf00000 size 0x30000
partition mutil-log base 0xf30000 size 0x80000
partition oops base 0xfb0000 size 0x40000
0000
Hex
00 00 02 97 00 00 00 00 00 04 00 00 70 61 72 74 69 74 69 6F 6E 20 66 61 63 74 72 6F 79 2D 62 6F 6F 74 20 62 61 73 65 20 30 78 30 30 30 30 30 20 73 69 7A 65 20 30 78 34 30 30 30 30 0A 70 61 72 74 69 74 69 6F 6E 20 66 73 2D 75 62 6F 6F 74 20 62 61 73 65 20 30 78 34 30 30 30 30 20 73 69 7A 65 20 30 78 34 30 30 30 30 0A 70 61 72 74 69 74 69 6F 6E 20 70 61 72 74 69 74 69 6F 6E 2D 74 61 62 6C 65 20 62 61 73 65 20 30 78 38 30 30 30 30 20 73 69 7A 65 20 30 78 31 30 30 30 30 0A 70 61 72 74 69 74 69 6F 6E 20 64 65 66 61 75 6C 74 2D 6D 61 63 20 62 61 73 65 20 30 78 39 30 30 30 30 20 73 69 7A 65 20 30 78 30 31 30 30 30 0A 70 61 72 74 69 74 69 6F 6E 20 73 75 70 70 6F 72 74 2D 6C 69 73 74 20 62 61 73 65 20 30 78 39 31 30 30 30 20 73 69 7A 65 20 30 78 30 30 31 30 30 0A 70 61 72 74 69 74 69 6F 6E 20 70 72 6F 64 75 63 74 2D 69 6E 66 6F 20 62 61 73 65 20 30 78 39 31 31 30 30 20 73 69 7A 65 20 30 78 30 30 34 30 30 0A 70 61 72 74 69 74 69 6F 6E 20 73 6F 66 74 2D 76 65 72 73 69 6F 6E 20 62 61 73 65 20 30 78 39 32 30 30 30 20 73 69 7A 65 20 30 78 30 30 31 30 30 0A 70 61 72 74 69 74 69 6F 6E 20 72 61 64 69 6F 20 62 61 73 65 20 30 78 61 30 30 30 30 20 73 69 7A 65 20 30 78 31 30 30 30 30 0A 70 61 72 74 69 74 69 6F 6E 20 65 78 74 72 61 2D 70 61 72 61 20 62 61 73 65 20 30 78 62 30 30 30 30 20 73 69 7A 65 20 30 78 31 30 30 30 30 0A 70 61 72 74 69 74 69 6F 6E 20 6F 73 2D 69 6D 61 67 65 20 62 61 73 65 20 30 78 63 30 30 30 30 20 73 69 7A 65 20 30 78 32 30 63 38 38 38 0A 70 61 72 74 69 74 69 6F 6E 20 66 69 6C 65 2D 73 79 73 74 65 6D 20 62 61 73 65 20 30 78 32 64 30 30 30 30 20 73 69 7A 65 20 30 78 62 37 30 30 30 30 0A 70 61 72 74 69 74 69 6F 6E 20 63 6F 6E 66 69 67 20 62 61 73 65 20 30 78 66 30 30 30 30 30 20 73 69 7A 65 20 30 78 33 30 30 30 30 0A 70 61 72 74 69 74 69 6F 6E 20 6D 75 74 69 6C 2D 6C 6F 67 20 62 61 73 65 20 30 78 66 33 30 30 30 30 20 73 69 7A 65 20 30 78 38 30 30 30 30 0A 70 61 72 74 69 74 69 6F 6E 20 6F 6F 70 73 20 62 61 73 65 20 30 78 66 62 30 30 30 30 20 73 69 7A 65 20 30 78 34 30 30 30 30 0A 30 30 30 30 0A 00 FF FF
Not sure why mtd4 and mtd5 are different...
On my device, extra-para has two 01 bytes, which is also what should be in OpenWrt factory images.
Maybe try downloading the extra-para (mtd5) partition, modifying the data to what I have, and writing it back (using the mtd tool in OpenWrt).
00 00 00 02 00 00 00 00 01 01 (last byte 00 to 01)
That worked, getting a clean boot directly to OpenWrt now. But, had to do it the "harder way"...
in OpenWrt when I do the "mtd unlock mtd5" command it barks back that "Could not open mtd device: mtd5". Same if trying to use the name from /proc/mtd of extra-para.
So, I did the Ctrl-B during u-boot and tftp'd the file, then copied it to 0x9f0b0000 (which looks like it lined up with mtd5 area.
Power-cycled a few times and it now directly boots to OpenWrt....
Thank You for the help...
Last question, is there a "clean" way to roll from OpenWrt back to the Original Stock TP-Link firmware ?
- Ctrl-B, start the httpd Web Recovery and upload the TP-Link bin...
- Reset Button and do the tftp renamed TP-Link bin to EAP245v3_up.bin method...
Or, a method for breaking the TP-Link bin up in parts and directly write them to the mtd locations.
1 Like
I think you need to install kmod-mtd-rw first (not tested), before you can use the unlock functionality.
OpenWrt contains the tplink-safeloader tool, which can be used to convert a TP-link firmware file to a sysupgrade file. But you need to compile this tool from source to get it. This extracts the 'os-image' and 'file-system' partitions from the file and creates a sysupgrade file with both blobs at the correct offset in OpenWrt's firmware partition.
If you wanted to break up the firmware file manually, you would need to:
- Find the positions for 'partition-table', 'os-image', and 'file-system' at the start of the firmware file
- Look at 'partition-table' to find the flash offsets of 'os-image' and 'file-system'
- Erase and write 'os-image' at the correct offset
- Erase and write 'file-system' at the correct offset
I would not recommend you try doing it manually.
Sadly, there is no way to force the bootloader to download a file via TFTP to automatically flash. If the EAP245v3 is bricked, it will start a HTTP server as you noticed. But apparently that isn't working as it should either...
1 Like
Did the tplink-safeloader route and created a sysupgrade file from the 2.21.0 Firmware. Flashed it and back to the Stock firmware clean without any issues....
Once again, Thank You for all the help....
Nice work on the release @svanheule thank you for doing this.
btw did you notice any performance difference between the original software and OpenWrt on the EAP245?
Thanks,
Mark
From the throughput tests I did, I did see a bit of a difference. With ath10k-ct and a laptop with an AX200 card, I got 340 Mb/s down, 240Mb/s up. On the TP-Link FW I got 340Mb/s down, 370Mb/s up.
A friend of mine also noticed throughput was terrible, unless transmit power was limited to 18dBm or less.
ah damn, thanks!
I guess it'd be better off to wait until full release to see if speeds get better?
I'm fine with running self-compiled, sometimes buggy software on my Pi, but might not risk it on an AP as of yet, since I'd gain nothing out of OpenWrt as of today.
Might still try it though once I get my usb-ttl cable.
I didn't exactly try to optimise the settings, so you may or may not be able to gain in throughput. I'm also not sure how much improvement there will still come from software updates.
That being said, I think you have to consider the complete picture here. Throughput is one thing, but having extra features like full DFS-channel support, WPA3, freedom in how you configure your VLANs... outweighs the difference in upload speed for me.
2 Likes
Well said 
After doing comparison tests between stock TP-Link 2.21.0 and the OpenWrt snapshots, the throughput difference is very noticeable.
Stock 2.21.0 (5Ghz @ 80Mhz)
UDP Up (outbound from client device) - avg about 600Mb/s
UDP Down (outbound from AP) - avg about 800Mb/s
OpenWrt snapshots (5Ghz @ 80Mhz)
UDP Up (outbound from client device) - avg about 600Mb/s
UDP Down (outbound from AP) - avg about 220Mb/s
I did speedtests on the LAN port side from the AP itself (using OpenWrt) and was able to get 900Mb/s in both directions. So, the bottleneck is within the wireless side.
Over this weekend I plan on looking at the spectrum while testing. Just to see if the TX from the AP is actually using the full 80Mhz width.
1 Like