Hi,
I'm thinking about buying the EAP225-Wall. The model has been mentioned in a thread about the EAP225-v3, but it looks like it would be a separate effort:
What are the chances that openwrt support will be available for this router?
Luck has it @Borromini sent me one two weeks ago, so the port is basically done.
I need to clean up the commits, but if you want you can build it already.
2 Likes
How's your MT7621 chops eh? For a crack at that TP-Link EAP235-Wall once they start to sell that for real 
Challenge accepted!
Hopefully it doesn't need any difficult patches like the original EAP AC devices, then it shouldn't be too hard 
1 Like
Hehe Cool!
And by using KEY_LIGHTS_TOGGLE for the LED button, there is a trigger to use for toggling the LED. An example script can be found in the other topic linked below, and should probably go on the wiki if this device gets merged.
They did at least release the EAP230-WALL recently, so are we lucky and will this one be on the list of supported devices as well? I might even help paying the hardware so you guys could get your hands on one.
The EAP-235 is popping up on Amazon for Europe as well now, so here's hoping they might actually be shipping somewhere in December.
17 posts were split to a new topic: Adding support for EAP235-WALL
Hey guys,
I have one of EAP225-WALL v2, while official web page https://openwrt.org/toh/tp-link/eap225 tells me, Qualcomm Atheros QCA9561, Qualcomm Atheros QCA9886.
The 2.4GHZ works fine, but it seems to have QCA9888 for 5GHZ, not QCA9886 like in the description:
$ dmesg | grep -i qca
[ 0.000000] SoC: Qualcomm Atheros QCA956X ver 1 rev 0
[ 44.385556] ath10k_pci 0000:00:00.0: qca9888 hw2.0 target 0x01000000 chip_id 0x00000000 sub 0000:0000
[ 44.767294] ath10k_pci 0000:00:00.0: failed to fetch board data for bus=pci,bmi-chip-id=0,bmi-board-id=20 from ath10k/QCA9888/hw2.0/board-2.bin
[ 45.385639] ath10k_pci 0000:00:00.0: failed to fetch board-2.bin or board.bin from ath10k/QCA9888/hw2.0
As you see in dmesg, the 5GHZ is not working and it is also not in the config now (of course):
$ cat /etc/config/wireless
config wifi-device 'radio0'
option type 'mac80211'
option path 'platform/ahb/18100000.wmac'
option channel '1'
option band '2g'
option htmode 'HT20'
option disabled '1'
config wifi-iface 'default_radio0'
option device 'radio0'
option network 'lan'
option mode 'ap'
option ssid 'OpenWrt'
option encryption 'none'
Can I fix this? Any ideas? If I run stock firmware, the 5GHZ band works really well.
1 Like
Hello.
I bougth EAP225-Wall V2 and I can't install OpenWRT after updating TP-Link firmware to v5.0.3 and following the instructions given on OpenWRT's EAP225 device page for EAP225-Wall.
When trying to upload the "OpenWRT-factory.bin" image to the router, it says "bad file" (PS: I did not SSH'ed to tun the cliclientd stopcs, I directly tried to upload the factory image from the web interface and it fails. Is it the reason of the failure ?).
Could those who managed to install OpenWRT on it could give me a hand, as I help myself a lot of people with installing OpenWRT on Ubiquity EdgeRouter X. Thanks a lot by advance.
Then I had a request regarding the openwrt.org/tp-link/eap225 device page :
When it is written " EAP225 v3+, EAP225-Outdoor, EAP225-Wall " in the install section, does this mean also EAP-225-Outdoor V3+ and EAP225-Wall V3+ ?
Kind regards,
Frédéric.
The instructions to install OpenWrt are already reduced to the smallest number of required steps. Not running cliclientd stopcs would result in exactly what your are seeing (failure to validate the file's signature).
Thank you for answering so rapidly.
It finally worked fine, but I had to Power off and Power on the router, then SSH to run
cliclientd stopcs, and then upgrade via the web interface for the process to work well.
Not powering off and on before upgrading was leading to the upgrade process to an OpenWRT factory image to only reaching 4% before being stopped and hanging up.
Then I have two last small request :
1) Issues with one of the two radio baseband ICs :
- When upgrading to OpenWRT 23.05.5, only one radio baseband is recognized.
- While when using 22.03.7 version, both 2.4G and 5G baseband ICs are recognized normally.
How to quick fix this small problem to have both baseband ICs well recognized with version 23.05.5 ?
2) swconfig still installed and used for OpenWRT 22.03.7 and 23.05.5 builds for EAP225-Wall :
I noted on the OpenWRT 22.03.7 build for EAP225-Wall that the package swconfig is still in use instead of what replaces it for the new DSA architecture. Why ?
With other OpenWRT devices I use, like Ubibuity Edgerouter X or other hardware I use with OpenWRT 22.03.7 or 23.05.5, swconfig is no longer installed and used by default. Why does this change doesn't apply to the EAP225-Wall builds of OpenWRT 22.03.7 and 23.05.5 ? Is it because of the nature of the internal switch IC used ?
Thanks by advance for your answers,
Kind regards,
Frederic.
Hello.
Are there any news on this topic ? I acknowledge the same issue.
It shouldn't be difficult to fix normally if it was working on previous builds for OpenWRT 22.03.7.
I am going to compare the list of all the packages installed on version 22.03.7 and 23.05.5 to look for changes, maybe it's a start to understand why this happening.
Those board data refered in your post, I guess they are witten into some file somewhere. I have not enough experience with building my own OpenWRT images to know where such file is and what it is.
But I'm gonna ask Chat GPT, maybe it has the answer what file it is, or what item to change into the build configuration file. I learned nothing relevant from chat GPT, except that these /lib/firmware/ath10k/QCA9888/hw2.0/board.bin and /lib/firmware/ath10k/QCA9888/hw2.0/board-2.bin files are important for the driver.
Below the relevant dmesg extract from v22.03.7 (OK) :
[ 18.476728] ath10k_pci 0000:00:00.0: qca9888 hw2.0 target 0x01000000 chip_id 0x00000000 sub 0000:0000
[ 18.486308] ath10k_pci 0000:00:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 0
[ 18.505572] ath10k_pci 0000:00:00.0: firmware ver 10.4b-ct-9888-fW-13-5ae337bb1 api 5 features mfp,peer-flow-ctrl,txstatus-noack,wmi-10.x-CT,ratemask-CT,regdump-CT,txrate-CT,flush-all-CT,pingpong-CT,ch-regs-CT,nop-CT,set-special-CT,tx-rc-CT,cust-stats-CT,txrate2-CT,beacon-cb-CT,wmi-block-ack-CT,wmi-bcn-rc-CT crc32 59e741e7
[ 18.839532] ath10k_pci 0000:00:00.0: Loading BDF type 0
[ 18.849709] ath10k_pci 0000:00:00.0: failed to fetch board data for bus=pci,bmi-chip-id=0,bmi-board-id=20 from ath10k/QCA9888/hw2.0/board-2.bin
[ 19.066381] ath10k_pci 0000:00:00.0: board_file api 1 bmi_id 0:20 crc32 9bb0e3be
[ 20.923392] ath10k_pci 0000:00:00.0: 10.4 wmi init: vdevs: 16 peers: 48 tid: 96
[ 20.931175] ath10k_pci 0000:00:00.0: msdu-desc: 2500 skid: 32
[ 20.961320] ath10k_pci 0000:00:00.0: wmi print 'P 48/48 V 16 K 144 PH 176 T 186 msdu-desc: 2500 sw-crypt: 0 ct-sta: 0'
[ 20.972720] ath10k_pci 0000:00:00.0: wmi print 'free: 114572 iram: 12644 sram: 29508'
[ 21.207038] ath10k_pci 0000:00:00.0: htt-ver 2.2 wmi-op 6 htt-op 4 cal pre-cal-file max-sta 32 raw 0 hwcrypto 1
And then v23.05.5 (KO) :
[ 42.224338] ath10k_pci 0000:00:00.0: qca9888 hw2.0 target 0x01000000 chip_id 0x00000000 sub 0000:0000
[ 42.233925] ath10k_pci 0000:00:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 0
[ 42.253201] ath10k_pci 0000:00:00.0: firmware ver 10.4b-ct-9888-fW-13-5ae337bb1 api 5 features mfp,peer-flow-ctrl,txstatus-noack,wmi-10.x-CT,ratemask-CT,regdump-CT,txrate-CT,flush-all-CT,pingpong-CT,ch-regs-CT,nop-CT,set-special-CT,tx-rc-CT,cust-stats-CT,txrate2-CT,beacon-cb-CT,wmi-block-ack-CT,wmi-bcn-rc-CT crc32 59e741e7
[ 42.594356] ath10k_pci 0000:00:00.0: Loading BDF type 0
[ 42.604524] ath10k_pci 0000:00:00.0: failed to fetch board data for bus=pci,bmi-chip-id=0,bmi-board-id=20 from ath10k/QCA9888/hw2.0/board-2.bin
[ 43.227192] ath10k_pci 0000:00:00.0: failed to fetch board-2.bin or board.bin from ath10k/QCA9888/hw2.0
[ 43.236962] ath10k_pci 0000:00:00.0: failed to fetch board file: -12
[ 43.266052] ath10k_pci 0000:00:00.0: could not probe fw (-12)
Could it be a simple access right issue to these files ? Going to check the access rights for both builds :
v22.03.7 :
root@OpenWrt-Wifi3:/lib/firmware/ath10k/QCA9888/hw2.0# ls -al
drwxr-xr-x 1 root root 0 Oct 16 19:00 .
drwxr-xr-x 1 root root 0 Jul 16 00:25 ..
-rw-r--r-- 1 root root 206444 Jul 16 00:25 board-2.bin
lrwxrwxrwx 1 root root 49 Oct 16 19:00 board.bin -> /lib/firmware/ath10k/pre-cal-pci-0000:00:00.0.bin
-rw-r--r-- 1 root root 630784 Jul 16 00:25 firmware-5.bin
root@OpenWrt-Wifi3:/lib/firmware/ath10k# ls -al
drwxr-xr-x 1 root root 0 Oct 16 19:00 .
drwxr-xr-x 1 root root 0 Jul 16 00:25 ..
drwxr-xr-x 1 root root 0 Jul 16 00:25 QCA9888
-rw-r--r-- 1 root root 12064 Oct 16 19:00 pre-cal-pci-0000:00:00.0.bin
v23.05.5 :
root@OpenWrt-Wifi3:/lib/firmware/ath10k/QCA9888/hw2.0# ls -al
drwxr-xr-x 2 root root 73 Sep 23 14:34 .
drwxr-xr-x 3 root root 28 Sep 23 14:34 ..
-rw-r--r-- 1 root root 206444 Sep 23 14:34 board-2.bin
lrwxrwxrwx 1 root root 30 Sep 23 14:34 board.bin -> ../../cal-pci-0000:01:00.0.bin
-rw-r--r-- 1 root root 630784 Sep 23 14:34 firmware-5.bin
root@OpenWrt-Wifi3:/lib/firmware/ath10k# ls -al
drwxr-xr-x 3 root root 30 Sep 23 14:34 .
drwxr-xr-x 3 root root 50 Sep 23 14:34 ..
drwxr-xr-x 3 root root 28 Sep 23 14:34 QCA9888
As you can see, the file pointed by the link is missing in version 23.05.5
Going to try to copy it manually from the 22.03.7 version, even if it's an ugly hack, it could work out fine, by chance. And then we can push investigations deeper.
I'm back : Good news: The hack worked fine.
I copied the missing file from the v22.03.7 version to the router under v23.05.5 and renamed it to fit the link's file name, rebooted, and it worked.
The 5G wifi is now operationnal under v23.05.5.
Now we have to understand where the issue is in these install / build scripts of the v23.05.5 build. There is something wrong there.
Any help welcome to fix it definitively, it's almost done.
Kind regards,
Frédéric.
see:
1 Like
Thanks a lot. As I can read from these threads, if a few patchings technics work well, they seem hard to generalize because of the use of IC serial numbers in these calibration files.
According to Chat GPT (!) this is a problem within a script into OpenWRT builder tool, or a problem within a script of these ath10k install scripts most probably. But it's only chat GPT's weak opinion. Still, I personally think it's something of the kind.
Any idea about why DSA is not activated for this EAP225 Access Point with openWRT versions > 21.x.x ?
Thanks for your help on this other secondary topic.
Because qca8k is:
a) not quite ready for ath79/ big endian
b) ath79 is a huge and pretty diverse target, so getting that changed for all devices is a nightmare
--
feel free to work on a), then b) might find enthusiasts to cover many devices as if by pure magic
1 Like
Hello.
Thank you very much for this high quality educated answer.
May I ask you a last question : Under LUCI, I could see that if DSA is not activated (swconfig being installed, we have the network->switch menu visible in LUCI), we also have the DSA network->interface->device menu from which it is possible to configure the switch the DSA way, while we can also configure it with network->switch. So it's like we have both the old swconfig installed, and the DSA installed too, at least from LUCI point of view.
So my question is : I guess it would be a very bad idea to try to configure both the switch from the network->interface->device menu, and from network->switch menu.
In order to avoid conflict between DSA and swconfig, is it necessary to unconfigure the br-lan device in the menu network->interface->device to ensure no DSA config things is touching the switch, and only use the network->switch menu to configure the switch ?
PS : I asked these questions above to ChatGPT, and here is its weak answer, still interesting :
Yes, you’re absolutely right to think that using both network->interface->device and network->switch menus to configure the switch simultaneously could lead to conflicts, especially in a hybrid situation where both DSA and swconfig appear in LuCI. Mixing configurations between DSA (Device Tree-based switch configuration) and swconfig (legacy switch configuration) may lead to unexpected behavior or configuration conflicts, as each manages the switch in different ways.
Recommendations to Avoid Conflicts
- Use Only One Configuration Method: If
swconfigis available in LuCI and you plan to use it to configure VLANs and switch behavior, it's safer to avoid the network->interface->device menu (the DSA-oriented method). Configure everything related to VLANs, port assignments, and switch logic only from network->switch. - Unconfigure
br-lanin DSA: If you prefer to useswconfigfully, consider removing or not configuring thebr-landevice in network->interface->device. This way, DSA-related configurations won’t interfere withswconfigsettings. Keep all settings in network->switch where you can control VLAN tagging, port assignment, and bridge connections directly underswconfig. - Check LuCI’s Configuration Files: Make sure that
/etc/config/networkaligns withswconfigif you’re using network->switch. If anydevicesections forbr-lanor other DSA-based interfaces appear, they may need to be commented out or adjusted to prevent conflicts withswconfig's configuration. - Monitor Behavior on Reboot: After making adjustments, reboot the device and observe whether the settings persist as expected. Sometimes, misconfigurations become more apparent after a reboot.
Summary
To avoid conflicts, pick one method (either DSA or swconfig) and remove or unconfigure any interfaces or devices associated with the other to prevent cross-interference. This will keep your VLAN and switch configuration clean and predictable.
Hi to all,
I have two other questions :
- It's a couple of days I'm trying to make working a not so complex configuration with the EAP225-Wall under 23.05.5, with the patch for the 5 GHz baseband wifi radio running fine.
My troubles are with the switch configuration.
From the default configuration after reinstalling OpenWRT, I would like to :
-
Activate the first default wifi interface, predefined with the
radio0configuration, just adding "PSK2" cyphering and a passphrase, and changing the lan interface setting foroption protocoltodhcp. It works fine. -
Then I would like to create a second radio interface on
radio0, with another SSID and passphrase with PSK2 cyphering, but cabling it to another firewall zone (lan2) corresponding to another interface (InDHCP clientmode too) and tagged for VLAN 25 on all ports of the switch. It's something easy I used to do very simply in the past, withDSAorswconfig, but here, I fail doing it.
I've been trying and bumping my head on the wall for a week, but I failed to have something working. The interface refuses to get an IP Address, and no data seems transmitted at all on the VLAN 25. I'm using another higher level (main) router also running under OpenWRT, connected to the EAP225-Wall, to serv DHCP requests for the VLAN25 and untagged traffic, and route both to the internet through firewalls rules on this main router. I have other devices that use it fine, but here, it is not working for the VLAN 25 with the EAP225. What's wrong ? It's so simple. It should work straight.
It's like there are some special procedures to apply to create such configuration with an `hybrid DSA + swconfig" OpenWRT 23.05.5. Could you tell me what the workaround is ? Or if there is a limitation with current hybrid situation ?
- Why does the default configuration of the AP after OpenWRT installation doesn't initialize and use "wan" interface as it is normally the case for default configurations ?
Thanks a lot for your attention,
Kind regards,
Frederic.