Large HTTPS POSTs stall and timeout only on 5 GHz band after enabling mesh router packet-aggregation

Environment

Home mesh network: primary router XBrand XR500 (firmware 2.4.18), two satellite nodes XR500-S (firmware 2.4.18), ISP modem in bridge mode, clients include Windows 11 laptop (Intel AX200), iPhone 14 Pro (iOS 17.2). Issue reproduces on 5 GHz SSID only; 2.4 GHz unaffected.

Symptoms

Large HTTPS POSTs (multipart uploads ~30–100 MB) hang or time out after 10–30 seconds only when client is associated to 5 GHz mesh node. Small requests and downloads work; browsing and streaming unaffected. Intermittent successful uploads if client moves into direct range of primary router.

Observations

Wireshark on client shows TCP connection established and POST data sent, but server's final ACKs stop arriving; client reports TLS read timeouts. Captures on router show fragmented MPDUs and aggregated frames with 802.11 A-MPDU present; ICMP 'fragmentation needed' (Type 3 Code 4) from upstream gateway appear but are not reaching client. Disabling 802.11ac aggregation on the node eliminates stalls. MTU on WAN remains 1500; no PPPoE. No abnormal CPU load on devices.

Already attempted

Updated mesh firmware to 2.4.19 beta (no change). Disabled Airtime Fairness and QoS on mesh nodes (no change). Applied MSS clamping (via primary router NAT rules) to 1350 — reduced but did not eliminate timeouts. Forced client to 2.4 GHz — uploads succeed. Replaced Ethernet cable between nodes with verified Cat6 (no change).

Question

What is the likely root cause of large HTTPS uploads stalling only on 5 GHz mesh nodes, and which reversible diagnostic steps and mitigations should I apply before contacting vendor support?

Post timeline

COMMUNITY RESPONSES

Verified community troubleshooting

0 replies

No answers yet..

Showing 0 of 0 community responses

AI DIAGNOSTICS

Incident analysis

Updated 2d ago• Trouble ID

Most likely causes

Mesh node firmware bug in handling A-MPDU/A-MSDU aggregation that drops or fails to forward ICMP 'fragmentation needed' packets. 90%

Incorrect MSS/MTU handling on mesh node when offloading or accelerating wireless frames across backhaul links. 55%

Driver/firmware mismatch on client Wi‑Fi NIC that interacts poorly with aggregated frames leading to lost MTU signals. 25%

Summary

Symptoms point to an MTU/PMTUD failure combined with wireless frame aggregation across mesh hops. The presence of A-MPDU aggregation and lost ICMP 'fragmentation needed' messages indicates that Path MTU Discovery is failing: large TCP segments are being sent but the 'needs-fragmentation' signals are blocked or dropped between the ISP gateway and the wireless client when traversing the mesh node's aggregation logic. Disabling aggregation fixes the problem, suggesting the mesh node or its firmware mishandles fragmented/ICMP messages or reorders frames in a way that prevents the client's TCP stack from reducing MSS. MSS clamping partially helped because it reduced the need for fragmentation.

Suggested Fixes

Diagnostic step 1

Reproduce with packet captures: capture on client Wi‑Fi interface and on mesh node WAN interface simultaneously to confirm where ICMP Type 3 Code 4 messages are lost or dropped.

Diagnostic step 2

Temporarily disable 802.11 A-MPDU/A-MSDU (frame aggregation) on the affected mesh node to confirm mitigation; keep aggregation disabled until fix is applied if stable.

Diagnostic step 3

Keep MSS clamping at 1350–1400 on the router's NAT to work around PMTUD failures (reversible; monitor for broken DNS over HTTPS or VPN MTU implications).