Early Access ER707-M2 V1 Pre-Release Firmware for SDN Controller 6.2.X.X (Closed)
This Article Applies to
ER707-M2(UN) v1.0
ER707-M2(UN) v1.60
ER707-M2(UN) v1.20
ER707-M2(UN) v1.26
ER707-M2(UN) v1.30
ER707-M2(UN) v1.36
Version Info:
Firmware Version: 1.4.0 Build 20260203 Rel.81971
Minimum FW Version for Update:
UN v1.0: 1.3.1 Build 20251009 Rel.67687 and above
UN v1.60: 1.3.1 Build 20251009 Rel.67687 and above
UN v1.20: 1.3.1 Build 20251009 Rel.67687 and above
UN v1.26: 1.3.1 Build 20251009 Rel.67687 and above
UN v1.30: 1.3.2 Build 20251009 Rel.61468 and above
UN v1.36: 1.3.2 Build 20251009 Rel.61468 and above
For downloading of any firmware version, please refer to Omada Download Center.
Recommended Controller Version: 6.2
Recommended APP Version: No
Release Notes
New Features:
1. Add support for V6plus/DS-Lite dial-up mode.
2. Add support for multi-segment address pool for DHCP server.
3. Add support for DHCP user list to display the current clients with DHCP IP addresses assigned.
4. Add support for multi-channel configuration.
5. Add support for integrated SpeedTest tool.
6. Add support for specifying port for SIP ALG.
Enhancements:
1. Optimized system boot time.
2. Optimized overall system stability.
3. Optimized menu order, adjusted function pages and consolidated related pages for better user experience.
4. Optimized the efficiency of Network configuration delivery.
5. Optimized the resource consumption for traffic statistics.
6. Optimized load balance configuration.
7. Optimized VPN configuration process efficiency.
8. SD-WAN capacity expanded.
Bug Fixed:
1. Fixed the issue that DHCP Option 2 does not support negative value input.
2. Fixed the issue that Gateway does not report SN to Omada Controller.
3. Fixed the issue that ACL rules do not take effect to VPN users.
4. Fixed the issue that no logs shown when DHCP server capacity reaches device limit despite available address pool capacity.
5. Fixed the issue that rules missing while delivering full configuration and associated LAN DNS configuration invalidation when an illegal LAN name is configured on Omada Controller.
6. Fixed the issue that mDNS repeater unable to handle mDNS packets containing NSEC fields, causing functional abnormalities.
7. Fixed the issue that Manrope font displayed incorrectly across the gateway web interface.
8. Fixed the issue that traceroute test occasionally uses backup WAN while primary WAN is online with link backup configured.
9. Fixed the issue that IPv6 dialing interferes IPv4 online detection check.
10. Fixed the issue that switch device unable to obtain IP address from gateway after firmware upgrade.
11. Fixed the issue that Windows built-in L2TP client automatically disconnects after connecting to gateway L2TP server for one minute.
12. Fixed the issue that USB modem in 3G dialing mode not displaying dial-up status on System Status page after reboot.
13. Fixed the issue that the configuration of blocking a client not taking effect when multiple clients are connected after device reboot.
14. Fixed the issue that PADI timeout when PPPoE Profile is configured on Omada Central System.
15. Fixed the issue of LLDP packet anomalies.
16. Fixed the issue of wired client reporting.
17. Fixed the issue that part of LAN IP address unable to access HTTPS website (Port 443 Unreachable) after multiple WAN failover.
18. Fixed the issue of SD-WAN disconnection caused by WAN Alias configuration.
19. Fixed the issue of full device configuration wiped while controller not delivering full device configuration.
20. Fixed the issue that device unable to be adopted by Omada Controller cased by unable to access OpenVPN server in full mode as OpenVPN client.
Firmware Download
Before the Upgrade
(1) Please be sure you have read the Pre-release Firmware Agreement before upgrading the Beta firmware!
(2) You may follow the following guide to upgrade your Omada devices. How to Upgrade/Downgrade Omada Gateways
(3) This firmware upgrade is irreversible. Please contact Omada technical support if downgrade is required.
Firmware Download Link
ER707-M2(UN) V1 1.4.1 Build 20260325 Rel.78146
Notes:
(1) The above firmware is applied to matching hardware.
(2) Your device’s configuration won’t be lost after upgrading.
(3) If you have disabled the HTTPS port, please enable the HTTPS port before upgrading the firmware.
Additional Information
All feedback is welcome, including letting us know about successful device upgrades.
If somehow you encounter an issue during or after the upgrade, it's suggested to contact us with the following info:
- Omada Controller version if you have any.
- Device Firmware version with Build number (previous and current)
If your model gets bricked during the firmware upgrade, you may follow the guide below to recover the firmware.
How to use the Emergency Mode to recover the firmware for Omada Gateways
Update Log
Apr 17th, 2026
Remove the pre-release link. Please go to the official website to download the stable version.
Mar 27th, 2026
Release of this article.
Recommended Threads
Omada_Network_Application_V6.2.x.x Pre-Release Firmware (Released on 11th Feb, 2026)
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
aaaah ok sorry wasn't aware, thought it was pulled back due to issues.
Clear. Thanks!
- Copy Link
- Report Inappropriate Content
https://community.tp-link.com/en/business/forum/topic/857570?replyId=1666984
Heya, when I tried a few weeks later (on pre-release firmware), it worked. Don't know what went wrong the first day, might have been user error(?). Consider this resolved.
- Copy Link
- Report Inappropriate Content
Hi @doeLauw
Thanks for posting here.
In the future, you can find the specific content or reasons for each update by checking the update log section.
- Copy Link
- Report Inappropriate Content
I think I have a bug with this firmware (1.4.1) on my ER707-M2 v1.20 and unfortunately I can't seem to downgrade.
I have a dual-stack IPv4 and IPv6 internet connection.
The DNS service running on the gateway is generating DNS64 addresses for domains which don't have AAAA records, but as there is no NAT64 on my connection this leads to timeouts.
With some LLM assistance, here are the details:
ER707-M2 firmware 1.4.1: `unbound` resolver is configured with `dns64` module, synthesizes `64:ff9b::/96` AAAAs on native dual-stack
After upgrading an ER707-M2 (v1.20) from firmware `1.3.1 Build 20251009 Rel.67687` to `1.4.1 Build 20260325 Rel.78146`, the gateway's internal DNS resolver synthesizes AAAA records in the `64:ff9b::/96` well-known NAT64 prefix (RFC 6052) for IPv4-only domains. This breaks connectivity to IPv4-only hosts for any LAN client using the gateway as its DNS server, because Happy Eyeballs (RFC 8305) prefers the unreachable synthesized IPv6 address.
- Gateway: ER707-M2 v1.20
- Firmware: 1.4.1 Build 20260325 Rel.78146
- Controller: Omada SDN 6.2.x
- WAN: native dual-stack via Aussie Broadband (no V6plus, no DS-Lite, no NAT64 translator on the network)
Root cause evidence (from gateway syslog)
daemon.notice unbound: notice: init module 0: respip daemon.notice unbound: notice: init module 1: dns64 daemon.notice unbound: notice: init module 2: validator daemon.notice unbound: notice: init module 3: iterator daemon.info unbound: info: start of service (unbound 1.18.0).
The `dns64` module is present in unbound's `module-config` on every resolver startup. The default unbound module chain is `validator iterator`; the addition of `dns64` is a TP-Link configuration choice. There is no setting I found in the Omada Controller to disable it.
Reproducer (from any LAN client)
$ dig @10.1.0.1 AAAA github.com +short 64:ff9b::4ed:1626 # github.com only has an A record, AAAA should not exist $ dig @10.1.0.1 AAAA google.com +short 2404:6800:4013:409::66 # real AAAAs pass through correctly
Any LAN client using the gateway's DHCP-advertised DNS server (`10.1.0.1`) receives synthesized AAAAs for IPv4-only hosts and cannot reach them by name (Happy Eyeballs timeout + fallback to A, breaking SSH, HTTP, etc.). On native dual-stack networks with no NAT64 translator, DNS64 synthesis serves no purpose and is actively harmful.
What I tried
- Searched the Omada Controller for any DNS64/NAT64/IPv6 transition toggle — none exists
- Force-reprovisioned from the Controller — the `dns64` module remains in unbound's module-config after reboot
- Inspected the device CLI (enable, configure mode) — no DNS/IPv6 resolver configuration is exposed
- Confirmed via `syslog history` that `unbound` itself is the source (not upstream)
Expected behaviour
The `dns64` module should only be added to unbound's `module-config` when the WAN is configured for an IPv6-transition mode that pairs with a reachable NAT64/AFTR translator (V6plus / DS-Lite / MAP-E / MAP-T / 464XLAT). On dual-stack or IPv4-only WANs, `module-config` should be the default `"validator iterator"`.
Related hypothesis
This release added V6plus/DS-Lite dial-up support (changelog item #1 for 1.4.1). It is likely that `dns64` was added to `unbound.conf` as a prerequisite for those transition modes but was not made conditional on the WAN type.
- Copy Link
- Report Inappropriate Content
@HevyElectricity @VincentTP I experience exactly the same problem.
After installing firmware 1.4.1 my Tesla-app, IMDB-app and some other apps doesn't work anymore when I am connected to my Wifi. I can't downgrade... So.. When will the bug bee fixed? (I have also a dual-stack IPv4 and IPv6 on my network and internet connection).
For now, I have installed dnscrypt-proxy on my Raspberry Pi for bypassing the router. My apps are working now :)
- Copy Link
- Report Inappropriate Content
Thanks for your feedback. We have located the cause and are working on it. Will keep you posted once there is any update.
HevyElectricity wrote
I think I have a bug with this firmware (1.4.1) on my ER707-M2 v1.20 and unfortunately I can't seem to downgrade.
I have a dual-stack IPv4 and IPv6 internet connection.
The DNS service running on the gateway is generating DNS64 addresses for domains which don't have AAAA records, but as there is no NAT64 on my connection this leads to timeouts.
With some LLM assistance, here are the details:
ER707-M2 firmware 1.4.1: `unbound` resolver is configured with `dns64` module, synthesizes `64:ff9b::/96` AAAAs on native dual-stack
After upgrading an ER707-M2 (v1.20) from firmware `1.3.1 Build 20251009 Rel.67687` to `1.4.1 Build 20260325 Rel.78146`, the gateway's internal DNS resolver synthesizes AAAA records in the `64:ff9b::/96` well-known NAT64 prefix (RFC 6052) for IPv4-only domains. This breaks connectivity to IPv4-only hosts for any LAN client using the gateway as its DNS server, because Happy Eyeballs (RFC 8305) prefers the unreachable synthesized IPv6 address.
- Gateway: ER707-M2 v1.20
- Firmware: 1.4.1 Build 20260325 Rel.78146
- Controller: Omada SDN 6.2.x
- WAN: native dual-stack via Aussie Broadband (no V6plus, no DS-Lite, no NAT64 translator on the network)
Root cause evidence (from gateway syslog)
daemon.notice unbound: notice: init module 0: respip daemon.notice unbound: notice: init module 1: dns64 daemon.notice unbound: notice: init module 2: validator daemon.notice unbound: notice: init module 3: iterator daemon.info unbound: info: start of service (unbound 1.18.0).
The `dns64` module is present in unbound's `module-config` on every resolver startup. The default unbound module chain is `validator iterator`; the addition of `dns64` is a TP-Link configuration choice. There is no setting I found in the Omada Controller to disable it.
Reproducer (from any LAN client)
$ dig @10.1.0.1 AAAA github.com +short 64:ff9b::4ed:1626 # github.com only has an A record, AAAA should not exist $ dig @10.1.0.1 AAAA google.com +short 2404:6800:4013:409::66 # real AAAAs pass through correctly
Any LAN client using the gateway's DHCP-advertised DNS server (`10.1.0.1`) receives synthesized AAAAs for IPv4-only hosts and cannot reach them by name (Happy Eyeballs timeout + fallback to A, breaking SSH, HTTP, etc.). On native dual-stack networks with no NAT64 translator, DNS64 synthesis serves no purpose and is actively harmful.
What I tried
- Searched the Omada Controller for any DNS64/NAT64/IPv6 transition toggle — none exists
- Force-reprovisioned from the Controller — the `dns64` module remains in unbound's module-config after reboot
- Inspected the device CLI (enable, configure mode) — no DNS/IPv6 resolver configuration is exposed
- Confirmed via `syslog history` that `unbound` itself is the source (not upstream)
Expected behaviour
The `dns64` module should only be added to unbound's `module-config` when the WAN is configured for an IPv6-transition mode that pairs with a reachable NAT64/AFTR translator (V6plus / DS-Lite / MAP-E / MAP-T / 464XLAT). On dual-stack or IPv4-only WANs, `module-config` should be the default `"validator iterator"`.
Related hypothesis
This release added V6plus/DS-Lite dial-up support (changelog item #1 for 1.4.1). It is likely that `dns64` was added to `unbound.conf` as a prerequisite for those transition modes but was not made conditional on the WAN type.
- Copy Link
- Report Inappropriate Content
Thank you for your quick response and action! I look forward for the new firmware :)
- Copy Link
- Report Inappropriate Content
@Vincent-TP Any ETA for the bugs that are reported with the ER707-M2 ?
- Copy Link
- Report Inappropriate Content
Hi @TheMuk
Thanks for asking.
Around the beginning of next month.
Note: ETA is provisional and actual delivery may vary depending on implementation conditions.
TheMuk wrote
@Vincent-TP Any ETA for the bugs that are reported with the ER707-M2 ?
- Copy Link
- Report Inappropriate Content
Support provided me with a 1.4.2 firmware release to test, and it has solved the DNS problem for me.
- Copy Link
- Report Inappropriate Content
Information
Helpful: 1
Views: 8490
Replies: 53
Voters 0
No one has voted for it yet.