Tux's lil' helper
Joined: 01 Aug 2004
Location: Montreal, Canada
|Posted: Mon Nov 16, 2015 12:39 am Post subject: Local wifi (ath9k) transfers stalling [Solved]
|My transfers fail at different points for different files (and even with the same file at different points at different times, although usually (with TCP) they tend to fail consistently at the same point, but not always, and much sooner than UDP). They fail irrespective of the protocol (http, scp, nfs, nc) and even irrespective of TCP vs UDP -- although UDP is able to transfer a lot more, it generally is able to transfer 80%-90% of the data, regardless of the file size -- ie. the wifi connection is able to transfer many megabytes, but something is stopping it from completing any single transfer.
The wifi card / driver that is probably at fault is my Qualcomm Atheros AR5418 Wireless Network Adapter [AR5008E 802.11(a)bgn] (PCI-Express) (rev 01), and it's using the ath9k driver. That's the card that's failing to receive the data. I'm sending it via my Broadcom BCM4318 (b43) equipped machine, but this problem only started with this other ath9k-using machine.
The ath9k machine is able to send me tonnes of data without issues, so the issue is simply with it receiving data -- ie. perhaps some kind of "receive-buffer bug".
I tried fiddling with disabling/enabling the kernel's tcp SACK settings, and the network interfaces' MTU settings (currently set to 1500) -- the problem persists. This bug seems nasty.
Here is a tcpdump, from a transfer done with nc (tcp mode), which was only able to transfer 23168 bytes ... tcp "seq 23169" seems particularly interesting... my b43-using client (B) seems to keep resending that chunk, even though it seems to be sending the chunks after it too (?), and even though my ath9k-using server (a) did ACKnowledge it? I'm not sure exactly what's going on, but it certainly looks fishy :S...
Here is a tcpdump of the same test, but with SACK disabled ... it failed at the exact same byte position -- but this doesn't always happen...
[EDIT: Hmmm, apparently rebooting my laptop (the machine doing the uploading) "resolved" the issue. Spooky.]