Hi @brute4c 

Thanks for reaching out to TP-Link Business Forums and sharing your observations.

To better assist you, I've created a support ticket via your registered email address. The ticket ID is TKID260547082, please check your email box and ensure the support email is well received. Thanks!

  @Gabriel-TP Same issue here with ER7212PC v2 and this firmware. 

KEY UPDATE — likely root cause: management/discovery plane breaks on the x.x.10.0/24 subnet (works on x.x.0.0/24) as a default network.
 

After a long debug, the single variable behind all my trouble is the main network's subnet. With the LAN on x.x.10.0/24 (VLAN 10), EAP adoption fails and mDNS reflection breaks. Move the same network to x.x.0.0/24 and both immediately work. DHCP Option 138 → controller does not rescue the x.x.10.x case — only changing the subnet does.

Backstory

• Setup: ER7212PC (router + built-in Omada SDN controller + PoE switch), 3x EAP615-Wall(EU) v1.0 (fw 1.5.4). Main network on VLAN 10, 10.10.10.0/24, controller 10.10.10.1.
• The first controller upgrade 2.3.1 → 2.4.2 already triggered this; the APs eventually self-adopted after a dozen-plus attempts.
• This time: downgrade to 2.3.1 (unfortunately my backup wouldn't restore on 2.3.1) → re-upgrade to 2.4.2 → restore the 2.4.2 backup. After that, no AP would re-adopt and it did not self-recover.

Symptoms

• APs cycle ADOPTING → ADOPT FAILED ("Device adoption failed because the device does not respond to adopt commands.").
• Controller discovers them (Model, MAC, firmware, uptime) — L2 discovery works.
• AP Controller Connection IP shows the EAP fallback 192.168.0.254 instead of the controller; a static 10.10.10.x set on the AP is overwritten during ADOPTING.
• On the 10.10.10.0/24 segment, mDNS reflection also breaks at the same time (forwarding _googlecast._tcp.local between subnets stops working).

What I tried (and the A/B that isolated it)

• Ruled out DNS/AdGuard (NAS off), rogue DHCP (only the ER7212PC serves DHCP; a laptop on the same port/VLAN gets a correct lease), cabling/port/VLAN (APs wired directly to the ER7212PC PoE ports; native VLAN = the controller's network), credentials (factory-reset APs accept admin/admin), and AP firmware (same version worked before).
• Isolated to a single AP to remove the shared-192.168.0.254 conflict — still failed.
• Logged into the AP standalone, set a static 10.10.10.x — overwritten by the controller during ADOPTING.
• Tried the Omada Discovery Utility and the Access Config "Controller Hostname/IP" field — neither resolved it.
• A/B by subnet (the key test):
  • Factory reset → adopt on 192.168.0.1/24 → success (repeatable).
  • Factory reset → adopt on 10.10.10.1/24 → Adopt Failed (repeatable).
  • Switch back to 192.168.0.1/24 → success.
  • Forget APs → restore 2.4.2 backup → set Option 138 → adopt on 10.10.10.1 → failed; change to 10.10.0.1 → adopted (one immediately, others after retries) and mDNS started working too.
• Separately, the backup/restore was non-deterministic: the same file failed with "Failed to restore because of unexpected errors. Please try again later.", then succeeded on retry; after one reboot all adopted APs were lost; one AP came back as "Managed by Others".

Suggestions / questions

1. Why does adoption + multicast work on x.x.0.0/24 but fail on x.x.10.0/24 (VLAN 10), even with DHCP Option 138 pointing at the controller? Is the device-management / discovery / multicast plane hard-tied to the Default Network, making a tagged or non-.0 management segment effectively unsupported?
2. Make adoption robust on a custom management subnet — don't strand the EAP on its hard-coded 192.168.0.254 fallback during provisioning when a valid management-subnet address is available.
3. Make backup/restore deterministic and idempotent (and please consider moving away from the opaque binary format toward an exportable text/JSON config) — a restore that fails then succeeds on the same file, and silently drops device state, is hard to trust.

Hi @Gilles2516 

To better assist in your case, I've helped created a ticket on your behalf. Please check your mailbox and be sure that the support ticket is well-received. Thanks!