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
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
I've seen the RX use 80MHz, but the TX never seems to go above 40MHz. If you want to dig deeper into this, maybe create a separate topic. I guess other devices with the same or similar radios might have the same issues. And maybe more knowledgeable people will see your post. 
Something similar happens to my TP-Link Archer C6. It use ath10k too, the outbound from the client reachs 530 Mbps but the outbound from the router sometime reachs 430 Mbps, others 330, others 220... i think it never goes lower than 220 but the speed fluctuates in seconds being near the router. I tried changing everything wich is available in luci, but i don't think this issue is related with any setting. I tried 19.07.4 and latest master but nothing change.
So, I think I'll need to post up to the Tech or Dev groups on this...
Been doing a bunch of testing and trying all kinds of different debugging and settings. End result, the TX from the AP radio never goes above 40Mhz using VTH modes. Beacons, Settings and debugging all show VTH-80 is enabled and all settings are correct. It just never tries..
I've tried the current commit of the ath10k-ct drivers and firmware. Latest Master commit of driver and firmware (which gave a little better performance. But, still only TX at VHT-40 rates). Tried the Kernel sourced ath10k drivers and Firmware (which the TX never went into VHT or HT modes, stayed at Basic rates 20Mhz. Clients still went into VHT-80 Modes and the AP handled the RX at those modes and rates without issue).
I went from the wpad basic to Full wpad and even tried Full hostapd. No differences at all other then having better settings and debug functionality.
Best results so far is compiling and using the latest Master commit of atk10k-ct driver and firmware with Full hostapd w/ Wolfssl.
Was getting a consistent 900Mb/s from Client (RX on AP) and 450Mb/s from AP (TX on AP). But, the AP shows it's TX at 40Mhz with VTH rates.
Looking at the Spectrum I see the Client TX'ing at the correct full 80Mhz width. The AP is TX'ing at the correct 40Mhz width based on the channel used. It shifts and uses the correct 40Mhz width (either upper or lower depending on channel) as if it's either ramped back or set to 40Mhz. Not using the correct 80Mhz center and only TX'ing at 40Mhz.
I'm starting to wonder if it's specific to the Qualcomm Atheros QCA9982 chip the AP uses. I would think if it was an overall QCA99x0 issue, more models would be having similar issues.
The QCA9982 is only use by one other device, but they didn't see any issues so far. This radio also isn't really listed anywhere as 'supported'. The PCI IDs are the same as for the QCA9990, but the firmware just worked, so I didn't think much of it.
Interesting tests you're doing by the way. I just noticed that on my EAP245v1, with a QCA9880 radio, 80MHz AP to station does happen, so at least it is supported by the software stack.
I just submitted a bug report for the issue... Task ID 3405
It seems right now the best "true" combo is..
kmod-ath10k
ath10k-firmware-qca99x0-ct
Even though Luci, 'iw dev wlan0 station dump' and 'hostapd_cli all_sta' show TX mode for all clients as 6Mb/s 20Mhz. In reality it is actually TX'ing at 80Mhz and higher VHT modes when you look at it with an external spectrum analyzer. The bug with kmod-ath10k looks to be just the TX mode reporting, RX mode is correct.
The bug with kmod-ath10k-ct is it is actually limiting TX mode to 40Mhz. But, it is reporting this correctly.
Hi
i tried installing openwrt latest snapshot as per page on openwrt regarding EAP245
i waited for several minutes after flash and nothing happened, so i decided to power cycle the unit. Now it seems to be bricked in some way, the LED flashes GREEN-ORANGE-GREEN, then after around 15 secs starts fast green blinking that lasts around 5secs and slighly slower green blinking that lasts around 15 secs. Then LED is solid green.
If i press reset button during the first fast 5 seconds blinking, it start to blink fast orange led and stays like that until power off.
Before i go further and try TFTP or other methods, can someone please provide guidelines at this point?
It doesn't sound like it's bricked, it sounds like it's functioning as intended. The fast-slow-solid green indicates the device is booting and then running in normal operation. The fast orange blinking indicates that you entered failsafe mode (by pressing the reset button).
The default OpenWrt config will configure address 192.168.1.1 on the interface. That address should be reachable after the initial flash.
