@Joseph-TP @Asmodeus83
I did some testing with older firmware and the speeds are not coming back.

That's why i asked for a test from TP-Link so we know where to begin.

I think it has something to do with Android 16 and/or Samsung's update on that.

Will try more testing.

I am now back to be800v1-up-all-ver1-2-4-P1[20250414-rel18315]_sign_2025-04-14_14.54.22.bin

Edit:

Connections > WiFi > 3-dots menu: Intelligent Wi-Fi > Connectivity labs > Wi-Fi 7 mode: OFF (then reconnect to Wi-Fi network)
= Wi-Fi 6E mode and the upload goes to 1500 Mbps

Edit 2:
Back to Wi-Fi 7 mode: ON = max up to 900 Mbps again.

Still could be an issue at both devices, very hard to investigate. But i am leaning towards Samsung (Android) being faulty.

Edit 3:
Samsung S22 Ultra also is very slow on Wi-Fi 6E 6 GHz upload speed :(

Also Android 16.

https://www.youtube.com/watch?v=-5o_Qu3XToQ

Just in general:
Samsung S24 Ultra One Uit 8.5 update still has the same issue.

@Joseph-TP any news from the developers on this?

Post update:
Speedtest on my wifi 6 isp modem itself. Link speed 2400 Mbps:

https://www.speedtest.net/my-result/a/11625795187

BE800, wifi 7. Link speed 5764 Mbps:
https://www.speedtest.net/my-result/a/11625799208

It just won't do multiple data sessions and/or a long session.

Speedtest 'thinks' this is a slow session, so the session is short and does not speed up.

Edit2:
Also WiFiman internal speedtest shows the same. Download perfect, upload horrible.
What a **** show. And for so long no updates. Last time buying TP-Link here.

  @Joseph-TP 

Or you just show me a screenshot of a Samsung S24 Ultra doing 3000+ / 3000+ Mbps on a WiFi 7 speedtest.

Then i might help. You have reproduced nothing. Because you didn't try. I can't imagine TP-Link not being able to find someone with a S24 Ultra.

Stop gaslighting. But thanks for the reply. I will stop bothering you and look elsewhere.

  @Joseph-TP 

I agree with 5Guru. I provided tech support with all the detailed information about the problem, its causes, and reproduction methods. The fact that you allegedly can't reproduce it rather speaks to a lack of interest. I highly doubt this is due to incompetence, but rather a lack of interest. Personally, no one has ever asked me for remote access. My last email to support went unanswered, and the issue is still open.

You don't have to be a professor to assemble a mini-network of 3 devices with different physical connection speeds and reproduce the problem.

Even a quick look at YouTube videos shows that this is a common issue on various high-end TP-Link devices. I'd appreciate your feedback on this.

P.S. The forum password saver still isn't working. I have to log in again every time. Apparently, this is another high-level task...

  @Joseph-TP 

I originally planned to test intermediate link speeds of 2.5 Gbps and 5 Gbps, but due to hardware limitations with my SFP+ modules, I could only test 1 Gbps and 10 Gbps. As I mentioned before, everything works flawlessly on a physical 1 Gbps link. The issue exclusively happens at a 10 Gbps link.

Regarding your inability to reproduce the issue in the lab: you won't be able to reproduce it if you are using a software bottleneck or enterprise switches with deep buffers. If you simply apply a software rate limit (shaping) down to 1 Gbps, the software queues will easily absorb the microbursts, and you won't see any packet drops. To actually catch the bug, you need to create a physical link speed mismatch on a device with shallow hardware buffers (typical of consumer/edge equipment). Connect the BE800's 10G WAN to a 10G port on an intermediate switch or ONT, and then route that traffic out through a physical 1 Gbps, 2.5 Gbps, or 5 Gbps port. It is exactly at this physical egress port with its shallow ASIC buffers that the 10 Gbps microbursts from the BE800 will cause immediate overflows and tail drops.

The root cause is the lack of hardware pacing. The BE800 forwards data from a Wi-Fi 7 client at the full 10 Gbps rate without proper intervals. The downstream equipment cannot push these bursts through a slower physical interface, the buffers overflow, the TCP window collapses, and the upload speed tanks.

As for 5Guru's feedback, we are experiencing the exact same problem. The only differences are the client devices used (Samsung vs. my Xiaomi 15 Ultra and Intel BE200) and the physical speed of our respective downstream bottlenecks. The symptoms and the core issue are completely identical.

Finally, about the beta firmware and QoS: enabling QoS is a workaround, not a structural fix. It forces the router to use software queues (which absorb the bursts), but this inherently disables Hardware NAT and routes traffic through the main CPU. It is highly unlikely that TP-Link has implemented L3 HW Offloading for these specific QoS queues. Plus, requiring users to manually hardcode their ISP speed is unacceptable for dynamic ISP plans. A flagship device must handle packet pacing at the hardware switch-chip level without sacrificing HW NAT.

Please escalate this directly to the R&D engineers so they can investigate a proper, non-software-bound resolution.

  @Asmodeus83 for your info:

https://www.tp-link.com/us/support/download/archer-be800/v1/#Firmware

1.4.1 Build 20260401 rel.14784(4555) is still broken. Still same behavior.

- 1. Newly upgrade the wireless driver to enhance system security and stability.

They have no idea what they are doing.

Samsung S24 Ultra was the first Wi-Fi 7 phone and it doesn't work anymore.

I am so curious why it did work before. I wonder who broke what.

Download seems a bit slower with the new firmware. Not yet sure if speedtest server or it got worse.