There appears to be an implementation related bug in some of my devices or a slowdown on a server, it is the ipv4 that is slow not the ipv6. Has this ever happened before? Is there a way to fix the ipv4 speeds? Is this related to some sort of teredo server being slow or something configured improperly?
This was actually from a comcast connection in Chicago, although the problem appears to be the same for a Boulder, CO connection. There do not appear to be any signal strength issues with either the wifi or modem. This problem seems to be more common on wifi although both of these tests were performed on wifi so I don't think it is a signal issue, maybe some sort of obscure configuration problem?
So far I haven't been able to reproduce this on wired although I'm not sure it hasn't happened. I can't think of any reason the wifi would be different since the local connection speed is easially more than enough and there is clearly enough bandwidth when in ipv6 mode, from my most recent testing the problem is identicle on different hardware halfway accross the country also on a comcast connection, I would guess it is some sort of software bug on the routers but this is something I have never heard of before and so far I can't find any information on the issue at all. The routers are different models but run simmilar software(Tomato by Shibby). My typical testing involves isolating each network component and testing throughput individually but it seems that is not exactly possible due to the conditions this problem appears under. Maybe it is a strange edge condition on the router software.
I'm now fairly certain I know what the underlying issue is, here's the coppy paste of whats going on, it is definetely an edge condition issue with comcast and certain e series linksys/cisco routers.:
Yevgeniy: I ran into your blog post "Got slow download but fast upload speeds over wireless? Here's a fix." I have some info you may find useful.
This happened to me too when I moved to Comcast - but I had DSL running in parallel. The Comcast traffic had this problem but the DSL did not. Also, it affected my Linksys router when it had stock firmware *and* after switching to DD-WRT. Clearly the traffic itself was at issue, so I broke out the packet sniffer.
*All* inbound Comcast traffic (Internet --> client) was tagged with a DSCP value of 8 (Class Selector 1). The DSL traffic had a DSCP value of 0. So Comcast is tagging all traffic to be treated a certain way by QoS: "Priority," which sounds good but is actually the second-*lowest* possible.
WMM, itself a QoS technique, apparently de-prioritizes (drops?) based on the Comcast-supplied value. Turning off WMM worked around it - but since WMM is part of the 802.11n spec, I wanted root cause. Judiciously replacing that set-by-Comcast DSCP value does the trick.
So between my Linksys router and both ISPs, I had a Netscreen firewall. It lets me set DSCP values by policy - so I told it to match the DSL (DSCP 0). This yielded great improvement. However, I was still not getting full speed so even a zero value was not the best for > DSL rates. I set the DSCP value to 46 (Expedited Forwarding) and bingo, up to 20Mbps, almost full provisioned speed (25Mbps).
Why only download issues? Because the only Comcast-tagged packets are the inbound ones: Internet --> you, including those big data packets. When uploading, yes, you get sent ACK packets and such - but they are tiny connection-control packets. I imagine WWM weirds out on them too, but you (usually) wouldn't notice when doing multi-Mbps speed tests.
I am still trying to udnerstand WMM, but this was a big find, and I was lucky to have a firewall that let me packet-tweak. Hope you find the info useful.
This is a critical bug that is likely crippling thousands of routers and pretty much only comcast has this issue. It is an edge case interaction caused by bad DSCP information coming from comcast and poor condition handling by the WMM driver on certain linksys/cisco eseries routers and possibly others as well. This issue can appear on both stock and modded routers. Comcasts network is misconfigured and has been for years and has likely caused many people to needlessly replace fully functional routers, the reason IPv6 worked for me was because DSCP was configured correctly for that but it is incorrect for IPv4. Since the only packets with this bad information are the ones that are being downloaded upload is largely unaffected.
If someone is running custom firmware the work-around I wrote is this:
put this in init scripts section: insmod xt_DSCP.ko
and this in wan up scripts: iptables -t mangle -A PREROUTING -i vlan2 -j DSCP --set-dscp 0
these may need to be modified slightly depending on configuration.
This corrects the bad DSCP header information as soon as a packet hits the WAN interface on a router.
DSCP as received from Comcast's network is 0x08 this is the lowest priority possible which WMM interpertes as being unimportant to transmit quickly.
The scripts listed changes the DSCP on all packets to 0x00 which essentially means unclassified which WMM handles properly. This is how virtually every other ISP uses DSCP and is why the issues is specific to Comcast.
I have confirmed this issue on connections in both Chicago and Boulder, CO and it is likely to be present on Comcast's entire network.
@Jameshilliard : To the extent that I understand this at all, it's really, really interesting relating to a problem I have noticed for several weeks. I'm generally getting ~30/5 performance when running something like Speedtest.net or Speedof.me. However, whenever I use anything relating to Google from a Chromebook, speed falls off a cliff. The exact same Google services on a mid-2012 MacBook run at normal speeds. Worst case scenario, two days ago I was attempting to download a 688 Mb Chrome OS recovery image, and the estimated download time exceeded 24 hours. At a public AP in a coffee shop, the same download on the same Chromebook took 15 minutes. This is new behavior, as a few months ago, Google sites were just as fast as any others.
I have a Linksys WRT400N wireless router, which to the best of my knowledge does not support IPV6 without replacing the firmware with DD-WRT, something I am reluctant to do because the OEM firmware isn't available for download.
Does any of what I have described make sense? Would replacing the router with a newer one that supports IPV6 resolve the problem?
I have this issue as well, definitely related to the E1200 router I'm using. An alternative work around that mitigates the issue is to use G mode only (NOT mixed or N). This limits your local network speeds slightly, but is probably still more than enough for most people, and solves the sub 1 Mb/s speeds I was seeing.