US Cable Support → Comcast HSI > [Speed] PSA: Slow WiFi on Comcast? May be Comcasts Fault

[Speed] PSA: Slow WiFi on Comcast? May be Comcasts Fault

There is a critical bug in Comcast's network configuration 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. Comcast's 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 can affect any router that uses QoS or WMM(every wireless N router has WMM)

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

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.
Cisco appears to have at some point released new WMM drivers for stock firmware that largely resolve the issue on current stock firmware, 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.

Calling it a "critical bug" on Comcast's end is probably a bit harsh. Nothing should be acting on DSCP markings unless specifically configured to, since their meaning is specific to a given network (or for links between networks by prior agreement). If you're going to act on DSCP, you should clear the markings where the packets enter the network and set them to what your QoS policy dictates (and what your command does).

I don't think that's true, nearly every router will act on it since the WMM protocol on the wireless will almost always use DSCP at least somewhat. It depends somewhat on how aggressively the router responds though. My script clears the markings since I can't stop my WiFi from acting on DSCP.

Look what I found: »www.dd-wrt.com/phpBB2/viewtopic.php?p=773658

At least put it in Quotes.

Or a copy-cat killer.

So if you are using said router with NON STOCK firmware, there may be a bug, that can't be controlled via the router config console for the NON-STOCK firmware?
It's good to give other aheads up warning about the problem in the NON-STOCK firmware, but your title implies ComCast is at fault.
many users just choose to disable WMM or if using stock firmware avoid the problem all togther

Guess it depends what you are doing and your wireless environment for me it's need is borderline at best on a DIR-655 out in the country with few or no overlapping networks. currently I have it off and I'm not seeing any problems from that AND eliminated one streaming glitch.

Fascinating.

I can't get WAN-side captures immediately, but it does appear that on my WLAN, IPv4 packets from the Internet have DSCP 8 and 802.11e priority 1 = "background" = bad. I'm using a Netgear WNDR3700v1 with a trunk/bleeding-edge build of OpenWRT from last month (r37767).

I assume this has something to do with CDV...Comcast obviously needs to prioritize its VoIP traffic over HSI traffic on its HFC network and presumably they use DSCP to do that. Perhaps VoIP gateways (eMTAs or whatever they're called) then typically rewrite the DSCP when routing to the LAN. But I'd think HSI traffic could use "best effort" QoS rather than "background" and VoIP would still win. And it would be nice if, for HSI customers with separate router and modem, the modem would emit DSCP = 0. Maybe the CMTS+modem can't do that though.

I understand the argument that this is a bug in the router, but if it's true that the stock firmware on several popular routers doesn't rewrite the DSCP and then honors it on the wireless side, I feel Comcast should try hard to accommodate them anyway.

Anyway, I know very little about QoS, so I'll have to do more learning/investigation/testing tomorrow.

I absolutely can vouch for what "jhilliar" is saying and am so glad someone has the time / skill to make a fix to prove its Comcast's network.
I have a cisco / linksys e3200 with ddwrt and had encountered the issue several months ago, although for me setting my wifi to wireless g was fine as I don't need the extra speed. However I was well aware of the issue and have read numerous forums where people had relatively new N routers which worked great on fios etc and then went to comcast with the same equipment, only to witness crawling download on wireless. Meanwhile Ethernet would be fine.
I responded to a guy in a post several weeks ago who I think had this problem.
»Slow download speeds with router

Anyways good luck, hope this gets resolved!

I have an N router and never have experienced these issues.

Good point

Any idea what brands/models?

- Removed post

Cisco Linksys are known to have had the problem. unsure if there are more or if they found a solution, and updated since then.

Which is I think the OP's point, these users bought fairly high end (depending on when they were purchased) routers from name brand companies, and now find a significant bug, stimulated by a normal (for comcast) setting.
I'd first be pissed at cisco (who seems to be dropping the ball too frequently recently) and then work on INFORMING ComCast and users rather than accusing them publicly first.

You keep blaming Comcast for what looks to me like a Cisco bug. If you want to do QoS, you clear those bits at your edge as they come in and set them for whatever works in your QoS plan. It you don't want to bother clearing them, you ignore those bits. DSCP values only have local meaning within a network run by the same person or people. Cisco didn't clear the bits but still acted on them.

Comcast could clear the bits potentially to help people who haven't upgraded, but they aren't required to by any means.

My WMM is off, I am not sure what is mandatory about it?

»en.wikipedia.org/wiki/Wireless_M···tensions - I see nothing here to indicate it's "mandatory" one bit...

Do you still have WPA2 working now that u disabled it?
I remember it also takes something important out with it...

It's been working, never stopped.