Support for TP-Link EAP225 Outdoor v3

I did run into issues... (8/29 snapshot) When changing DHCP server and firewall config I've now ended up 5x having to resort to failsafe mode. I'm using luci for the config changes and the "reverting back" stuff doesn't do it. I have to power cycle, hit the reset button to get failsafe mode, wait some time, then power cycle again, and then it's back. It does not come back in failsafe mode without this additional power cycle (or two). (edit: I didn't have the 192.168.1.1 address configured anymore, that's why it seemed not to be accessible in failsafe mode)

I have 8 openwrt routers and APs and have not had this much trouble with any of them. I can't tell whether this is an eap225 issue or just a 22.03 snapshot issue...

1 Like

Working on this some more... it seems the ethernet interface doesn't get initialized properly after reboot. I now have a wifi interface set-up with a static IP address so I can connect when the device comes up and doesn't respond on ethernet. My observations:

  • boot log looks OK, it brings the eth device up, no errors
  • ip link and ip addr show the interface up and my static IP address assigned
  • my switch shows the link up @1Gb, but the mac address table does not show any entry for that link
  • ntfables looks OK to me, I have all firewall zones deleted

I'm not sure where to look next. I can post some config and logs if someone can look at them.

Update: I redid the whole install from factory image, step by step, with reboots after each step. Turns out the issue is installing dawn :upside_down_face:

Update 2: I'm going crazy... I have a small number of changes to apply from factory, e.g., ip address/dns, add a vlan, configure wireless with 2 SSIDs, install luci and dawn. At the end if I reboot the device doesn't respond to ethernet anymore.

I can then boot into failsafe, ssh in, mount_root, and reboot (without making any changes). Then the device reboots and ethernet works. I believe if I reboot again it fails again (have only tried once).

I've also saved a backup right before the last config change from which it doesn't come back. Then messed around (trying other combinations), then in failsafe restored the backup and rebooted: it came back!

Hmm, after messing around some more I wonder whether it's random or whether the RX of an ethernet packet at the "right time" kills it (like rebooting from luci and having it probe the device to find out when it rebooted). I don't know how to troubleshoot further.

I can confirm this behavior partly.
I have running the snapshot 20434 from 8/30.
I got only once the device in normal mode, normally I have to switch in failsafe mode.
Even if I go into failsafe mode, mount_root and reboot w/o further modifications, the device is not responding neither on 192.168.1.1 (4 pings only) nor the configured address nor gets an address via dhcp.
Wireless is not working even if its activated in /etc/config/wireless
If I can get the console in failsafe mode, I found these lines in dmesg

[    1.624811] ag71xx 19000000.eth: connected to PHY at mdio.0:06 [uid=001cc916, driver=RTL8211F Gigabit Ethernet]
[    1.635833] eth0: Atheros AG71xx at 0xb9000000, irq 4, mode: sgmii
[    1.642712] i2c /dev entries driver
[    1.648016] NET: Registered protocol family 10
[    1.660004] Segment Routing with IPv6
[    1.663893] NET: Registered protocol family 17
[    1.668621] bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this.

I will try the snapshots in the next days. If I can serve some informations or doing some tests - I´m ready for it.

(whoops, re-reading your post, my response is not the problem you're having, sorry. I'm leaving it for the benefit of anyone else coming here...)
I got spooked by this. I didn't find a precise description of what failsafe mode does. My understanding now is:

  • it boots with a different config that uses 192.168.1.1
  • it doesn't modify your config
  • you can mount_root and fix your config if you want to
  • when you reboot, you're back to your config
  • while in failsafe mode the yellow led blinks pretty fast

So if you boot into failsafe and just run mount_root; reboot then you ned to access the device again with the IP address you configured and not necessarily 192.168.1.1.

good news: I must have reached stable behavior. With snapshot builds from 08/30 and 08/31 the accesspoint restarts as expected and keeps it´s settings. Uff...

JFTR: your description of failsafe mode is right, but my recent observations saying, that the reboot not necessary starts into expected config, but into any else.
I have in etc/config/network

config interface 'lan'
        option device 'br-lan'
        option proto 'dhcp'

but the device asked never for an ip address. As mentioned here it seems openwrt disables the lan chip accidentally.
However, I´m glad that the access point is now running stable and I will wait for the final build of 22.03.0

1 Like

Mine seems pretty stable now too. I avoid making config changes 'cause I fear it will crap out. My main concern now is how do we ensure this gets fixed by someone who knows this stuff?

Unfortunately the changes didn´t find the way in the stable build.
The device is listed in firmware selector as long you choose SNAPSHOT version.
I will try the current snapshot in the next days

Sad news:
I have unpacked the accesspoint, connected it to lan and same behavior as first
the device is booting to anywhere but not in desired state
3 or 4 replies to ping for 192.168.1.1 during boot, during this time you have to press the reset button for boot in failsafe mode
if you connect via ssh to the ap, you can type
mount_root -> works
/etc/init.d/network reload fails with message "failed to connect to ubus"
also failes
/etc/init.d/uhttpd reload with same message

I transferred the latest snapshot to /tmp and did sysupgrade -c openwrt.bin

After this the AP came up with 192.168.1.1 (where´s my configuration?)

A 2nd reboot brings only the state as before: not pingable neither on configured nor standard address

ATM I didn´t have the device full booted. More investigation is necessary

Please is the Firmware OpenWrt snapshot Install listed in https://openwrt.org/toh/hwdata/tp-link/tp-link_eap225-outdoor_v3 safe to use, any experience? Is there any way I could help somehow? I have no openwrt-specific experience but do some kernel work/DT/compiling/etc.

Thanks a lot,

Pavel.

I use it on one unit acting as an dumb AP. it works.

1 Like

Thanks a lot, very useful!

Works really good indeed, thanks!

I tried to install the firmware. Gets an IP from my router through the ethernet port, however cannot access it through ssh. Should I consider it bricked?

i guess not. it still gets and IP.
try factory reset and such...

1 Like

Well, I bought one and installed openwrt. Very easy, a few notes.

I had to be connected via ethernet to Upgrade the firmware.
Openwrt snapshot works,
No DHCP, so had to configure my PC to the subnet of 192.168.1.1 default openwrt ip.
Added this to my ~/.ssh/config

Host *
    HostKeyAlgorithms ssh-rsa
    PubkeyAcceptedKeyTypes ssh-rsa

Connected via ssh: ssh -p22 root@192.168.1.1
Connected to my house internet gateway using these commands and installed luci


Succesfully connected the 5.8GHz interface Client to another wifi. Created another "Access Point" in Master mode in the same interface, but it doesn't show up in my phone. So I'm sharing the connection via the 2.4GHz interface.

With cpe220 I had two networks in the same wifi interface. One was Client, the other Access Point.

1 Like

Just as a quick note, that isn't a good idea to do with Host *, either enable it just for that one connection:

ssh -o 'HostKeyAlgorithms +ssh-rsa' -o 'PubkeyAcceptedKeyTypes +ssh-rsa' root@192.168.1.1

or at least only for Host 192.168.1.1 in ~/.ssh/config.

ssh-rsa was disabled by default for a reason.

You are right, but why does openwrt uses it by default? (offtopic)

First post!

Thank you for this process guide - I successfully installed Luci on my EAP225-Outdoor v3

Looking forward to seeing this unit fully supported in further OpenWRT releases.

2 Likes