Thanks for the clarification. In the meantime, I am working on unpacking the firmware to better understand how we can help to ensure your products can be supported by the community at large.

@Solla-topee

 

Will this be possible? 

 

Allowing your community and your customers to manage and continue supporting the products that have been abandoned would be the most beneficial thing you could do and I guarantee you'd have a thriving community of followers/supporters. The hardware in most of your devices is so wildly underutilized, its almost criminal.

@XWEBNetwork 

This is the best idea that I've ever heard.

I can start with all of the outdated software components on your Top Tier equipment....BE85. Also on XE75 Pro.

 

Tested firmware: XE75 Pro 1-3-1-P1[20251023-rel47884] (Oct 2025), BE85 1-2-1-P1[20250731-rel15505] (Aug 2025).

 

Outdated software components
- OpenSSL 1.0.2d — released July 2015, EOL from upstream December 2019. Used by the seven cloud daemons and the HTTPS web UI.
- Linux kernel 4.4.60 on XE75 Pro — released April 2017, kernel 4.4 LTS branch EOL February 2022. 5.4.164 on BE85, near end of LTS.
- busybox 1.22.1 (January 2014). Provides most of userland.
- GCC 5.2.0 toolchain (September 2015). Old compilers can't enable modern hardening even when configured to.
- dnsmasq 2.83 with several known CVEs.
- hostapd 2.10-devel (pre-stable) with the SAE / WPS / DPP CVE cluster.
- Avira AV bundle dated May 2022 — last update ~3 years old.

 

This is all packed into their "latest" firmware releases.

 

And there's waayyyyy more from Kernel hardening failures to scripting bugs to insecure operational defaults....

Hi @Solla-topee

I would like to make a constructive suggestion regarding the recent open-source firmware discussion and the ongoing XE75 / XE75 Pro beta firmware feedback.

 

I do not think the community is only asking TP-Link to “open-source everything” in a vague way. A more realistic and useful first step would be transparency: publish a proper SBOM, list the main firmware components and versions, explain which CVEs are patched through backports, and clarify the long-term maintenance roadmap for kernel, wireless stack, security libraries and userland packages.

 

This matters because users are not only asking for new features. We are also seeing recurring evidence that firmware quality, regression testing and long-term maintainability need stronger visibility.

 

For instance:

In the XE75 / XE75 Pro 1.4.999 beta thread, several users have reported real-world issues across different setups:

- 2.4 GHz IoT devices becoming unavailable after firmware updates.

- Smart TVs failing to connect or losing internet access.

- Connection Preference not behaving as expected.

- Devices showing incorrect connection type.

- Samsung and other legacy or non-Wi-Fi 6 clients connecting but getting almost unusable throughput.

- A later beta seemingly improving part of that issue, while introducing a new performance regression on modern Wi-Fi 6 / 6E clients that were previously working correctly.

- Continued uncertainty around 2.4 GHz channel width, High Capacity mode, 2.4 GHz backhaul behavior and what each firmware version actually changes.

 

From my own testing on Deco XE75 V2, the first beta caused severe throughput issues on several older or non-Wi-Fi 6 clients. After the updated beta, some modern Wi-Fi 6 / 6E clients that previously reached around 850-900 Mbps were suddenly limited to roughly 200-250 Mbps under similar conditions. That is not a minor edge case, it suggests a broader regression in Wi-Fi performance or client compatibility.

 

The difficult part is that these beta firmwares are not always easy or safe for an average user to test. The announcement itself warns that the beta cannot be directly downgraded to previous official versions. So the user is taking the risk, installing firmware on their main home network, collecting evidence, testing different clients, changing settings, submitting logs, and then waiting to see whether the issue can be reproduced in a lab.

That process may be normal for engineering, but it is not normal for a consumer product experience.

The average user buys Deco as a reliable home networking solution. In the modern world, people expect to connect the device, configure it once, and have it work. They do not expect to repeatedly test beta firmware, rebuild their home network, isolate every client, generate logs, compare regressions between builds, and wait until TP-Link can reproduce the problem internally.

 

At some point, this becomes an unfair burden on customers. Community feedback is valuable, but it should not become a substitute for TP-Link’s own quality control, regression testing and compatibility validation.

 

So... my suggestion is:

1. Publish a firmware component transparency report or SBOM for Deco products.

2. Clearly document whether old components are still maintained through TP-Link backports.

3. Provide a visible firmware maintenance roadmap for supported models.

4. Publish clearer changelogs between beta builds, not only generic “minor refinements”.

5. Add safer rollback options for beta testers.

6. Expand real-world QA scenarios, especially wired backhaul, mixed Wi-Fi 5 / Wi-Fi 6 / Wi-Fi 6E clients, Samsung devices, smart TVs, 2.4 GHz IoT, AP mode, router mode, IPv6 and high-density home networks.

7. Treat repeated community reports as evidence of a product-level regression, not isolated user-side incidents until individually reproduced.

 

Many of us are here because we like the hardware and want Deco firmware to become better. But the current pattern makes it feel like customers are doing unpaid QA for issues that should have been caught before release.

 

A more transparent firmware maintenance process would help TP-Link, the engineering team and the community at the same time. 

 

I hope my thoughts are clear and, again, constructive.

 

Thanks.