Dear Beelink team,
Thank you for your support so far. I want to add an important clarification so this issue is not treated as “fully solved”:
Even though I found a workaround (forcing a non-DFS 5 GHz channel like 36/40/44/48), I want to be very clear: this is not a real fix and I do not consider the matter closed. I will continue to monitor this and keep following up, because a customer should not need to change router channel settings to achieve normal Wi-Fi performance.
Key point:
- The GTi15 shows a severe throughput drop on DFS 5 GHz channels (example: channel 108), while other devices in the same network/location (e.g. my laptop) did not show comparable issues on the same DFS channel.
- On the GTi15, the Wi-Fi link can still look “good” (strong signal / high negotiated PHY rate), but real download throughput can collapse dramatically until the router is forced to a non-DFS channel.
This means the workaround shifts responsibility to the customer (router configuration), but the underlying issue appears to be GTi15 client-side behavior (platform integration / antenna design / firmware/driver behavior). In my view this should be treated as a product issue, not a router issue.
Request to Beelink:
- Please reproduce this internally with a GTi15 on a DFS channel (e.g. 100–140, such as 108) and compare against a known “good” client device in the same environment.
- Please escalate this to the relevant vendor(s) (Intel and/or other suppliers) and work toward a permanent fix (driver/firmware/BIOS/EC update or validated configuration guidance).
- Please include DFS-channel scenarios in the validation and test plan for current and future products. Users should not need to change router channel settings to get normal Wi-Fi performance.
I’m happy to provide my test results and repeat any measurements you need.
Thank you in advance for taking this seriously and for working on a proper long-term solution.
