Take the 2-minute tour ×

The problem

Note: First I'd like to understand WHY this is happening. Ofcourse, a solution would be nice too. :)

When downloading a large file over HTTP at high-speeds, my wireless traffic basically stops: I can't open webpages and the download itself pauses. It pauses pretty much immediately after starting it; sometimes at 800 KB, sometimes at a few MB. After some time, the download (and other traffic) resumes, but the problem keeps reoccurring during the same download.

The problem does not occur when using a wired connection through the same router (Linskys WRT120N). Also note that the connection is not dropped when this happens. It's just that the traffic stops and I can't browse to web pages, etc. (SYN packets are sent but nothing is received, etc.)

Inspection with Wireshark shows that the following happens:

  1. Server sends data packets which are acknowledged by client
  2. Server sends a packet, but SEQ indicates some packets were lost (6 packets in one occurrence).
  3. Server sends a few more packets and client acknowledges these using "selective acknowledgement"
  4. Server stops sending data for a while (since the lost packets were not acknowledged or the router stops forwarding them?)
  5. Eventually, server does a "retransmission" and traffic resumes as normal.

This all seems normal behavior to me when packet loss occurs. It's the consistent packet loss throughout a large, high-speed download that puzzles me.

What might cause this?

My own idea is the following: My internet is pretty fast (100 mbps), so when starting a large-file download, the router buffers the incoming data (since wireless introduces some slight delay / lower speed, in part due to other networks), but the buffer overflows and the router drops packets to regulate traffic (and because it has no choice).

But how could that happen? Doesn't the TCP window size limit the amount of data that can go unacknowledged? So how can the router's buffer overflow if there can only be like 64 KB waiting to be acknowledged?

Note: I've disabled TCP window scaling and dynamic window size through netsh options, in an attempt to fix this, but it doesn't seem to matter.

Also, Wireshark shows a pattern of the server sending 2 packets (of 1514 bytes) and the client sending an ACK, so does that rule out a possible buffer overflow? And a few more subsequent packets are received...

I'm at a loss here. Thanks for any insights.

Things that are (probably) NOT the cause / I have experimented with

  • The browser
  • Various TCP options in Windows 7 (netsh etc.)
  • Router settings such as MTU, beacon interval, UPnP, ...
share|improve this question

1 Answer 1

up vote 1 down vote accepted

The solution

The solution was to simply disable WMM support in the router config. Apparently, the Linksys WRT120N WMM support doesn't play nice with Windows 7 wireless for some reason.

Some more details

Often when the problem occurred, traffic would eventually resume (for the same connection), as if packets were queued by the router for some time. These pauses would usually last 40 seconds or more. It still puzzles me to be honest.

During this time, no other (TCP) connections could be made: When trying to browse to a web page or so, the laptop would send SYN packets, but there would be no response. However, DNS and ARP requests were processed normally.

share|improve this answer

Your Answer


