ath79-generic: add support for TP-Link EAP225-Outdoor v3

[T-X]

• Must be flashable from vendor firmware
  • Web interface
  • Note: direct vendor firmware to Gluon untested, device was originally flashed from vendor fw to vanilla OpenWrt
  • TFTP: untested
  • Other:
• Must support upgrade mechanism
  • Must have working sysupgrade
    • Must keep/forget configuration (sysupgrade [-n], firstboot)
  • Gluon profile name matches autoupdater image name
    (lua -e 'print(require("platform_info").get_image_name())')
• Reset/WPS/... button must return device into config mode
• Primary MAC address should match address on device label (or packaging)
  (https://gluon.readthedocs.io/en/latest/dev/hardware.html#hardware-support-in-packages)
  • When re-adding a device that was supported by an earlier version of Gluon, a
    factory reset must be performed before checking the primary MAC address, as
    the setting from the old version is not reset otherwise.
• Wired network
  • should support all network ports on the device
  • must have correct port assignment (WAN/LAN)
    • if there are multiple ports but no WAN port:
      • the PoE input should be WAN, all other ports LAN
      • otherwise the first port should be declared as WAN, all other ports LAN
• Wireless network (if applicable)
  • Association with AP must be possible on all radios
  • Association with 802.11s mesh must work on all radios
  • AP+mesh mode must work in parallel on all radios
• LED mapping
  • Power/system LED
    • Lit while the device is on
    • Should display config mode blink sequence
      (https://gluon.readthedocs.io/en/latest/features/configmode.html)
  • Radio LEDs No radio LED available
    • Should map to their respective radio
    • Should show activity
  • Switch port LEDs No switch LED available
    • Should map to their respective port (or switch, if only one led present)
    • Should show link state and activity
• Outdoor devices only:
  • Added board name to is_outdoor_device function in package/gluon-core/luasrc/usr/lib/lua/gluon/platform.lua
• Cellular devices only:
  • Added board name to is_cellular_device function in package/gluon-core/luasrc/usr/lib/lua/gluon/platform.lua
  • Added board name with modem setup function setup_ncm_qmi to package/gluon-core/luasrc/lib/gluon/upgrade/250-cellular
• Docs:
  • Added Device to docs/user/supported_devices.rst

[T-X]

Kudos to @yksflip for creating the excellent OpenWrt support for this device.

[herbetom]

I've only got experience with the v1. Hoewer, as far as I can tell they are identical (except for the ethernet phy chipset).

With the v1 there were huge problems with the 5 GHz WLAN:

• ipq40xx: switch QCA4019 firmware to -ct #2541
• ipq40xx: issue with WiFi Mesh since v2022.1.x #2692
• Revert "ipq40xx: switch Wave2 firmware to -ct (#2541)" #2799
• ath79-generic: out of memory on EAP225 outdoor v1 #2827
• ath79-generic: switch Wave2 firmware to -ct #2848

And the current -ct variant we're using isn't without issues. The WiFi randomly stops working with it. At least it doesn't take the whole device into OOM, but it's not stable.

And as far as i was told it might be possible to work arround the issues with some kind of watchdog, but an upstream fix is extremely unlikely.

I think this device should only be added as broken.

[blocktrron]

@herbetom marking a single device because of a clear platform issue is arbitrary in this context.

It's clear the platform has issues, I'm on the same boat as you are. Thus the way forward is to make out a path how to handle the underlying issue.

Not advocating for a specific direction, but this could either be

a) Limiting maxassoc
b) Disabling 5GHz radio altogether by default
c) Flagging devices using said radio as broken
d) Investigate why the ath10k recovery mechanism is not working

[herbetom]

I don't think it's arbitrary to say that now, that we're aware of issues with the platform, until further developments, no new devices using the platform should be added (at least as non-broken). That way we we don't increase the size of the problem.

I do agree that the listed options should be evaluated and a universal way forward be found. After that it's possible to reevaluate the addition of new devices / unbreaking this one if it's merged "now".

However, the broken flag isn't particularly granular and there isn't a good way to permanently "revoke" a decision of non-broken. Installed devices would just don't get further updates. For those existing decices a "workaround" would be better. But if that happens to be for example disabling 5 GHz, it would mean that, strictly speaking, the device will no longer pass the checklist. Therefore I do think this shouldn't be merged as is.