Bulk TCP transfers on a records-office SSID crawl even though PHY rates look decent. Captures show data MPDUs without successful Block Ack agreements, so aggregation never stays enabled. What performance conclusion follows?
Select an answer to reveal the explanation.
Short Explanation
Aggregation is packing a moving van once instead of driving one lamp at a time. Without Block Ack, that packing falls apart and TCP crawls. Get BA working again so A-MPDU efficiency can return.
Full Explanation
If Block Ack agreements fail in a municipal bulk-transfer cell, aggregation efficiency collapses and TCP goodput falls sharply because A-MPDU gains depend on working BA. Restore BA and aggregation capability across client, AP, and capability advertisement health to recover MAC efficiency for records uploads or large civic file moves. Claiming TCP always outruns aggregation so Block Ack is optional misunderstands that TCP rides on MAC efficiency; without BA, airtime per byte rises. Treating missing Block Ack as proof the RADIUS shared secret is wrong confuses 802.1X authentication with HT/VHT/HE Block Ack negotiation after association. Disabling TCP window scaling so frames fit single MPDUs without BA intentionally cripples transport rather than fixing BA. Exam caveat: aggregation and BA failures present as slow Wi-Fi despite decent RSSI—inspect BA and A-MPDU statistics. Operational check: compare goodput and BA session state before and after client or AP fixes on a test bulk transfer in the municipal records workflow, and keep driver and firmware baselines that preserve aggregation. In municipal WLAN operations, record the chosen control and the rejected alternatives in the change ticket so on-call staff understand which failure modes were avoided for city services. Re-validate after the next maintenance window that the same control still holds under the current controller code, client mix, and civic event calendar used by the wireless team.