There 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, IPv6 speeds always worked for me 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 not affected nearly as badly.

There 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, IPv6 speeds always worked for me 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 not affected nearly as badly.

This is the fix I made and used on an e2000 and e3000 running shibby 112:

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.

Cisco appears to have at some point released new WMM drivers for stock firmware that largely resolve the issue, otherwise implementing my temp fix as a GUI option would probably be a good idea for the affected routers. The ability to assign DSCP to all traffic on chosen interfaces also might be a good thing to add anyways.

Haha, you think any of have that type of choice, anyways after I implemented my temp fix speeds are great on wifi, never really had any reliability problems on the connection itself…their customer service and billing, now that's a whole different story. This was just some sysadmin making a multimillion dollar mistake that went undiagnosed.

James, thank you so much for figuring this out! I just deployed an e1500 for a client to use for secure and guest wifi in a restaurant. Without this I was stuck with horrendous download speeds but great upload speeds. I knew it most likely had something to do with incorrect DSCP headers from Comcast thanks to a blog post by Yevgeniy Brikman but was at a loss as to how to overcome it using the Tomato GUI.

For anyone else in the same boat, the WAN up command has two dashes before the set-dscp 0. Copying and pasting it did not work for me and I needed to figure that out by trial and error. The whole line that should be able to copy and paste is below: