Thanks to the helpful testing of @klaernie, we've been able to fix two issues:
I can confirm that rebooting works with the latest snapshot! Thanks alot for your efforts!
I tried the latest snapshot on 3 EAP 225 outdoor v3 devices... but after the firmware upgrade is complete, there is no radio/signal and nothing works 
am I missing anything?
This is what I used: https://downloads.openwrt.org/snapshots/targets/ath79/generic/openwrt-ath79-generic-tplink_eap225-outdoor-v3-squashfs-factory.bin
Snapshot images do not contain all the features that normal builds come with. By default, OpenWrt does not come with WiFi enabled, you need to do that yourself.
If you've gone through those steps, and things still don't work the way you expect them to, please be more specific. "Nothing works" is not something we can do much with.
yes, makes sense... thanks for your response. The WiFi was disabled and I enabled it. Sorry, I confused no WiFi with "bricking" the router. But, when I connect to WiFi, there is no internet.. I will try flashing again and check.
That's probably because the device is still set up as a router (i.e. the default OpenWrt setup). You'll probably want to configure your device as a dumb access point.
Anybody tried to use CoovaChilli with the snapshot for EAP 225 outdoor v3? I tried referring to this link (https://openwrt.org/docs/guide-user/services/captive-portal/wireless.hotspot.coova-chilli), but after connecting to the SSID there is no login page / captive portal is not working (basically no internet). Anyone tried CoovaChilli yet?
Anyone tried CoovaChilli with EAP Outdoor V3 yet? Is it working...?
If you're having issues running CoovaChilli, it's best you post your question in #general. Chances of somebody running it on this specific piece of (rather new) hardware are pretty slim.
After quite some reboots my two devices have developed a confusing behaviour:
During the boot (probably around the time br-lan is setup) packages are passed between the wifi interfaces and eth0 (all bridged into br-lan) for just one or two seconds. Afterwards I can still see traffic being sent out eth0 with tcpdump, but it never makes it to the other side, a laptop running tcpdump does not see a single further packet.
For troubleshooting I set the firewall forward chain to policy accept, and also tried different cables, used a pcmcia 100mbit nic on the laptop, sent the traffic through a 100mbit dumb switch. Link detection always works, but the tcpdump results always stayed the same.
The only pattern I've seen from the two devices: the first device that showed this behaviour was rebooted many more times than the second one (order of magnitude: 10-15).
I'm at the end of my Layer 2 knowledge - could there be anything on driver-level? Is there any way to debug I'm not aware of? Is there anything I could test or didn't think of?
I'm also having trouble with the EAP225-Outdoor-v3. Downloaded the latest snapshot from https://downloads.openwrt.org/snapshots/targets/ath79/generic/openwrt-ath79-generic-tplink_eap225-outdoor-v3-squashfs-sysupgrade.bin (version from Thu Jul 14 10:48:42 2022, SHA256 e124608613369a8977cbe8298d920481aab97315c367858a579004027d4ddac8) and installed it (tried another firmware with the same issue before, hence the sysupgrade version). When booting up, it sends the UDP 4919 failsafe packets and a couple of seconds later requests an IP address from the DHCP server (the full 4-way handshake with DISCOVER/OFFER/REQUEST/ACK) but after that it is completely unreachable, doesn't even respond to ARP packets. The Ethernet link is still up though.
It is always possible to go to failsafe mode on the device by pressing the reset button right after getting the 4919 packet. In failsafe mode SSH works fine, already tried doing a reset from there, didn't solve the issue. At least it is possible to do a sysupgrade from failsafe mode, so I'm hoping I can get it working with another upgrade soon.
Any ideas what could be the reason for the missing connectivity right after DHCP? The failsafe mode shows that the Ethernet interface is perfectly working with exactly the same kernel and I have no idea why it loses connectivity later on during the normal boot. Don't really want to open up the device and connect a serial to debug it since I'm planning to install it outdoors (exposed to the rain for the next 5-10 years) and I'm not confident it will still be watertight after opening it up.
Is this issue also present when using the generic phy driver, instead of the Realtek phy driver? You may need to build an image with the REALTEK_PHY symbol disabled for ath79/generic to test this.
I wouldn't worry about the watertightness - the only holes are the antenna connectors, that can be reinstalled quite a lot, since they are sealed with o-rings. Just remove the antennas, peel the secondary rubber stickers, then unscrew the nut around the antenna connector (I used fine tipped tweezers for that), then the entire PCB slides out. Then remove the o-rings, as pushing the PCB back in later will most definitely send them flying across the room and have you searching (ask me how I know...).
I'll try to build openwrt today, the last time I tried I failed utterly, but that was years ago.
And if I don't manage to, I'll try again in August, when I'm back from vacation.
Thanks for the quick response, did the debugging via a serial now. Turned out that the device is requesting an IP address from DHCP and then switching back to a static IP address (192.168.1.1 for the normal OpenWRT or 192.168.42.1 for the Freifunk firmware I actually want to run).
Might be a good idea to change the default for that type of device, a single-port access point should probably default to a DHCP client instead of a static IP. If the current default (static IP address) is kept, the device should at least not request an IP address via DHCP before setting up the static IP address, after seeing the DHCP traffic I just assumed it would actually use this IP address and not something else.
Good news: I managed to actually build openwrt this time.
Bad news: The problem stopped showing when I booted the AP today, even before trying to flash my image. I'll dig in deeper after the vacation.
I still have problem with the latest Snapshot image in terms of EAP 225 v3 Outdoor.
Flashing went fine, but if i set the root passwd (latest snapshot, Aug 10) and rebooting from command line then the device is not responding and cannot SSH into it. Only cold reboot (unplug the power chord on POE) helps!
Do you have any idea how to solve this? ...or do you have a working image compiled?
I found one link in this thread from @Winux to download a firmware file, but the link does not work anyomre.
Hi @Winux. Would it be possible to re-upload the image to anonfiles? Question: is that a working image? As I posted in this thread recently the latest Snapshot image still have problems!
I just got an EAP225-Outdoor-V3 and installed the 8/29 snapshot (factory image). So far it seems to work fine. I changed the password, installed luci, brought up wireless interfaces.
Q: I haven't used snapshot before. What is my best path forward? Install everything I need before the next snapshot is generated and then wait for the next 22.03-rc or final?
i would wait for final.