You mean OpenWrt upgrade?
When a new version of OpenWrt comes out, you might want to upgrade, yes. However, as long as the device support isn't committed upstream, you/I/someone will have to maintain the patches out-of-tree and build images.
1 Like
Alright! What's missing on this device in order to be comitted to upstream?
A review, likely quite some polish on the patches, and patience.
1 Like
Thanks brother, but it's quite ot , but i'd like to share.
I have used your dd method, in order to get an EAP 120 running with OpenWRT. Read out the original firmware, took the sysupgrade and dd'ed using the same offsets, worked absolutely well!!
That's an entirely different device from what's discussed in this thread. The Archer D50 v1 is supported by OpenWrt, so you should start by checking out the info there. If you can't get it working, please open another thread in #general.
yes is compatble. but only with uart and opening, no tftp, i'm looking a way to flash openWRT in normal way from stock
thx for reply
Your device uses a different image format than the one I'm used to with TP-Link devices, so you would have to solder and get a UART anyway.
In any case, posting in this thread won't help you, since there's little chance the people following this thread also have the device you're interested in. Search the forums for an existing device thread in #devel for your device, or create a new thread specifically for the new feature (factory images) you would need/like.
On my device EAP245v3 after the cli command "cliclientd stopcs" via SSH the pad factory firmware file https://github.com/svanheule/openwrt/releases/tag/77f4c61 was'nt accepted by the TP-link firmware web interface. It always returns "Bad file". The directory "/tmp/stopcs" exists and "cliclientd stopcs" succeeds.
All firmware versions 2.2.0, 2.3.0, 2.3.1, 2.4.0 and the newest version 2.2 returns "Bad file".
What can I do?
That's an older build, so it's possible there were actually still issues with it. I'll build a new image based on the latest version of my patches.
Edit: The old build didn't have the device compatibility level yet, so that's probably why it was rejected. Try again with the new factory image.
The new factory image works fine.
1 Like
Thanks @svanheule, upgrading my EAP225-Outdoor from stock 1.5.0 to 1.6.1 then to your late July build worked perfectly.
5G works great in access mode with WPA2 PSK (CCMP) and 802.11r Fast Transition enabled, awesome!
Cannot make 2G work in access mode though, interface stays disabled, not sure why yet.
FWIW, I followed these instructions from another thread:
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