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 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.

What sort of improvements should one expect then?
The article above show how xfinity services are prioritized over other stuff like netflix.
Should one then expect to have a better netflix streaming experience using this fix?

What sort of improvements should one expect then?
The article above show how xfinity services are prioritized over other stuff like netflix.
Should one then expect to have a better netflix streaming experience using this fix?

Click to expand...

Comcast's network doesn't really prioritize traffic for standard internet services, however they are likely using DSCP for internal routing possibly. They may have forgotten to strip DSCP when it reaches the network edge. If your own network doesn't do anything with DSCP this won't make a difference, however it can affect any device/devices that takes DSCP into account when routing which includes nearly every wireless N router to some degree since WMM is a required component, the issue is much more noticeable in these linksys/cisco devices due to how the driver handles WMM but it can affect any of them to some degree.

Can you please explain how to do this? I would like to test this for myself and make sure I have the right vlan and DSCP set for both my home (E4200,E3000) and business (WRT54G-TM) routers. Thanks!

Click to expand...

The "vlan2" is simply what the wan interface on your main router is, you can find it using the ifconfig command(interface that has the public IP address). Note, you only should use this fix on the router that is connected to the modem, it will not help secondary routers since all problematic packets will have already been fixed as soon as they hit the WAN interface on the primary router if the primary is running this fix.

If you get an error along the lines of "No such chain/rule", then you forgot to run either insmod xt_DSCP.ko or modprobe xt_DSCP (which you run is your choice; they do the same thing and if issued repeatedly have no ill effects) prior to the iptables command. The iptables command, however, should only be run one once -- repeated runs will append/add unnecessary rules to your PREROUTING chain in the mangle table.

You can verify the command worked by looking at iptables -t mangle -L PREROUTING -n -v --line-numbers and seeing something like this:

A field value of 0x08 indicates a DSCP/PHB class of CS1 (precedence 1). How this gets used on the Comcast side is unknown, but I do have direct contact ability with folks who work in Comcast's IP networking group who I'm sure could comment further if this was discussed somewhere other than a public forum (i.e. Email).

vlan2 is just my wan interface I'm pretty sure at least seemed to be for default shibby 112 on e2000 and e3000 routers, I just used ifconfig to find the interface that was getting an external IP address, btw should using
`nvram get wan_iface` always get you the wan interface in every custom firmware varient? even dd-wrt or openwrt? from what I was seeing online there may have been a way to do the modprobe from iptables directly but I never got it to work, is that possible? This is what it said:

--modprobe=command
When adding or inserting rules into a chain, use command to load any necessary modules (targets, match extensions, etc).

Click to expand...

If these are in the scripts section you will need to reboot, if you want to just test and see if this fixes the problem simply execute them as commands(generally a good idea to do this first so you know if there are any errors).

FYI I have contacted Comcast about this and they are definitely looking into this although the more that contact them the faster they might fix it on their side. Their sysadmins seemed surprised this was going on so I'm fairly sure it wasn't intentional.

If these are in the scripts section you will need to reboot, if you want to just test and see if this fixes the problem simply execute them as commands(generally a good idea to do this first so you know if there are any errors)

Click to expand...

I tend to set it and forget it on my routers, but love to tinker. Never had a need to put anything in the Scripts section, so this is good info.

FYI I have contacted Comcast about this and they are definitely looking into this although the more that contact them the faster they might fix it on their side. Their sysadmins seemed surprised this was going on so I'm fairly sure it wasn't intentional.

Click to expand...

Not surprised, but hope they actually do fix it. Not holding my breath based on the bandwidth competition of streaming services. Only time will tell...

Have your WiFi internet speedtest's improved at all? This is probably still a good thing to do because otherwise local traffic would have a higher priority than internet traffic so if you internal wifi network is at a high-utilization rate the more important internet traffic would be slowed down a lot.

To be honest, my speed tests always exceeded my plans rated speeds both wired (Gigabit) and wireless (5GHz N). I have Comcast 50/10 service and regularly get ~57/~11, but surprisingly, when I switched over to my 2.4GHz channel (Mixed B,G,N), I got the same ~57/~11 results! I have never seen these results on the 2.4 channel as it was always ~30/~11. Although, now that I think about it, I haven't thoroughly tested 2.4 since I swapped out my E3000 (Toastman 1.28.7483) for the E4200 (Shibby 112) recently. Could be that or the patch. I'll have to check this out.

vlan2 is just my wan interface I'm pretty sure at least seemed to be for default shibby 112 on e2000 and e3000 routers, I just used ifconfig to find the interface that was getting an external IP address, btw should using
`nvram get wan_iface` always get you the wan interface in every custom firmware varient? even dd-wrt or openwrt? from what I was seeing online there may have been a way to do the modprobe from iptables directly but I never got it to work, is that possible? This is what it said: {snip}

Click to expand...

OpenWRT documents all their necessary variables/etc., and have moved many of them out of NVRAM to JFFS-based config files instead. If you want to support this for OpenWRT, you need to talk to the OpenWRT folks or read their docs.

The same goes for DD-WRT, although they rely heavily on NVRAM like Tomato. The NVRAM variable may be named something different however. Ask them. Just remember respectfully that this is a Tomato-focused forum, not OpenWRT or DD-WRT.

As for the iptables command you mentioned, re: --modprobe: please read everything I have written below.

You do not want to mess with --modprobe, because the built-in command used for loading modules already works correctly. That command just overrides it, and you don't want that given the below circumstances.

There are also netfilter extension modules (which is a type of kernel module but differs in how it's used and how it fits into netfilter/iptables) usable via -m, but you have to know what exact string to give it and it varies per module. Let me expand: there are two actual DSCP-related modules available:

1. /lib/modules/2.6.22.19/kernel/net/netfilter/xt_DSCP.ko (which is what you're insmod/modprobe'ing manually) -- the description of this module is "x_tables DSCP modification module" (note the word modification). It provides the --set-dscp iptables command as well as the DSCP chain name (which is what you're -j'ing to), and is specific to the mangle table (because it modifies packet headers, and mangle is where that happens).

2. /lib/modules/2.6.22.19/kernel/net/netfilter/xt_dscp.ko (note lowercase) -- the description of this module is "x_tables DSCP matching module" (note the word matching) and provides the --dscp and --dscp-class commands. It does not provide --set-dscp nor does it provide the DSCP chain name. The --dscp and --dscp-class commands are described as follows:

Code:

DSCP match v1.3.8 options
[!] --dscp value Match DSCP codepoint with numerical value
This value can be in decimal (ex: 32)
or in hex (ex: 0x20)
[!] --dscp-class name Match the DiffServ class. This value may
be any of the BE,EF, AFxx or CSx classes
These two options are mutually exclusive !

You can access/use xt_dscp.ko (lowercase) by using -m dscp in your iptables command, however it will not introduce the DSCP chain nor the --set-dscp command, as I said above. You cannot use -m DSCP or -m xt_DSCP or any other kind of command to "trick" it. I have experimented excessively with these two modules at this point and that's that as I see it.

The bottom line is just to run modprobe xt_DSCP as mentioned above (which will load xt_DSCP.ko into kernel space and affect netfilter/iptables as a whole), and then do your iptables commands as needed. Repeated runs of modprobe xt_DSCP will not harm the system (only one copy of the module will be ever loaded).

The author of these modules is the same individual: Harald Welte <laforge@netfilter.org>. You're welcome to contact him if you wish to hash out any details.

Edit: I should note the versions of xt_dscp and xt_DSCP I've linked to above are actually different (possibly newer?) than what we use in Tomato. I can tell because the Description strings differ slightly between what we have and what is on that site, and the code differs as well.

1. A "shim" interface/ABI for which source code is available -- all this does is act as a medium between the Linux kernel's networking layer (including the 802.11 MAC layer) and the binary blob driver, referring to symbol names blindly. I don't remember the name of this file but I can go digging if needed -- someone else here probably remembers the name,

2. A binary blob driver (kernel module wl.ko) which contains the actual proprietary closed-source code written by Broadcom, and may also contain firmware microcode (since on some wireless NICs you actually have to upload code that runs on the NIC itself before you can use it). They have no plans on making this available to the public, AFAIK, ever. Broadcom is one of those excessively-IP-and-lawyer-driven companies that does stuff like this, and you're legally not allowed to reverse-engineer it (the driver).

For the firmware to work for third parties, i.e. router vendors such as Asus, the vendors have a closed-door relationship with Broadcom. Broadcom gives them the shim code and the binary blob driver that is "supposed" to be compatible with the version of the Linux kernel they're using (for Tomato that's 2.6.22 patchlevel 19) and Asus crosses their fingers and hopes for the best. RMerlin can probably talk more about this, as he's actually chatted with Asus in the past about their stuff.

The binary blob driver also varies per router model, if I remember right (jerrm or RMerlin can correct me here if I'm wrong). It's also very difficult to determine if there are actual changes to the driver itself; MD5/SHA1 checksums sometimes vary while version numbers (shown in dmesg, or shown via wl ver) do not change.

The situation is very similar with the Ethernet switch driver (et.ko).

This is interesting, because as far as I can tell the e3000 wl module is fully open source, however the e2000 does appear to be in binary format. et.ko does appear to be binary only on everything I have seen so far, I'm still looking though.
Edit: I am wrong about this, both have some binary only components.

If Broadcom changed their stance with certain models of routers, that wouldn't surprise me either. It doesn't change the fact that the situation varies per model though (in other words, you have your work cut out for you, sadly).

Ok, looks like there were binary blobs for the most part, but I'm pretty sure I've isolated the changes by comparing the source from before and after the change, I think the drivers Shibby and everyone else are using are outdated, I have the updated drivers but I don't really know how to compile tomato.

Is this actually helping people with WRT54G's? I was thinking the issue is WMM related and isn't that mainly wireless N?

Click to expand...

Not sure, but on mine WMM is an option and I have it enabled. Wireless speed does seem more stable and consistent though, and it certainly seemed to improve things on the 2.4GHz channel on other models.

I've recompiled shibby tomato with the newer fixed driver(rt-n) for the e2000 and it seems to have fixed the issue, however I don't have Comcast anymore so I was only able to test by having the router WAN interface set DSCP to 8 itself. I just recompiled from the tomato-shibby-RT-AC head and from the src-rt folder with the e2000 option. http://sourceforge.net/projects/rou...K-1.28.--defMIPSR2-Max-newdriver.bin/download
I haven't done much stability testing but so far everything seems fine, the older driver needs to be deprecated since it is causing these issues.

I've got Comcast's 50/10 down/up service, and I, too, never got greater than ~30Mbps down on any wireless device no matter my wi-fi configuration. I did a packet trace and confirmed DSCP headers other than 0x00, so ran the two scripts on my E3000 running v1.28.7500 MIPSR2Toastman-RT K26 USB VPN, and lo and behold--I'm hitting ~57Mbps down on my iPhone and iPad!

I've recompiled shibby tomato with the newer fixed driver(rt-n) for the e2000 and it seems to have fixed the issue, however I don't have Comcast anymore so I was only able to test by having the router WAN interface set DSCP to 8 itself. I just recompiled from the tomato-shibby-RT-AC head and from the src-rt folder with the e2000 option. http://sourceforge.net/projects/rou...K-1.28.--defMIPSR2-Max-newdriver.bin/download
I haven't done much stability testing but so far everything seems fine, the older driver needs to be deprecated since it is causing these issues.

Click to expand...

I came across this thread when I was looking into buying a new router and someone mentioned this bug in a review.

Question: If I flash my E2000 router with this fixed driver Tomato version, will I still be able to update to the latest version of Shibby released November 21st without affecting the driver? (I'm a novice when it comes this stuff.)

I'm also curious if anyone else has installed this and had it work well for them.

If the fix is all you want, it takes ~30 seconds to enter and apply the scripts to the router vs. the amount of time it takes to reset NVRAM, flash firmware, reset NVRAM, reset all your router settings, etc.

If the fix is all you want, it takes ~30 seconds to enter and apply the scripts to the router vs. the amount of time it takes to reset NVRAM, flash firmware, reset NVRAM, reset all your router settings, etc.

Click to expand...

True, but I've been meaning to try a different flavor of Tomato anyway since I've been using the original all this time.

The only other choice is to disable WMM under Advanced / Wireless and cease use of the iptables rule. I'd recommend rebooting the router (via GUI) after saving and doing that; the wireless driver sometimes acts wonky after changing some settings in that menu.

The rule stopped working or is no longer there? What is the result of "iptables -vnL -t mangle" when it stops working? Where are you saving the commands?

Various things will cause tomato to reset/reload the firewall rules. Wanup is probably the wrong place to add the rule. The only way to make sure your own iptables rule(s) will be re-loaded for any firewall reset is to place it in the admin firewall script area or in a .fire autorun script.

I'm not sure how I'd decipher whether the rule stopped working or was no longer there. I can tell you the output of that command when it is working is like this:
Chain PREROUTING (policy ACCEPT 3878K packets, 3694M bytes)
num pkts bytes target prot opt in out source destination
1 2688K 3673M DSCP all -- vlan2 * 0.0.0.0/0 0.0.0.0/0 DSCP set 0x00
2 2622K 3584M DSCP all -- vlan2 * 0.0.0.0/0 0.0.0.0/0 DSCP set 0x00

That is to say, it appears to stop setting the DSCP IP header to 0 on incoming WAN packets. Rerunning the commands appears to re-enable it. At the moment, it's been working properly for the past ~13hrs or so.

It looks to me like there is something else touching/screwing with your iptables rules behind-the-scenes causing you this problem. There is definitely something about your setup/configuration which you haven't disclosed.

These commands ***are*** persistent if placed appropriately into Scripts/Firewall, otherwise they are lost at reboot. If you have something else going on under the hood (something else in Scripts, etc.) that tinkers, then I am not surprised in the least. I say they are persistent because they have remained working for many people (including myself) without issues. However people with more customised or complex environments may need to adjust things appropriately, and respectfully it is not my responsibility to cover every usage case. I wouldn't be surprised if the issue turned out to be someone using VPNs or having their WAN go up and down or the like.

The scripts are still working fine at the moment, so we're going on ~36hrs now.

I do have some firewall scripts that are commented out it appears. I don't even recall putting these in, so I'm not sure if they're default Tomato or Toastman scripts or ones I was playing with in the past and just forgot:

Just reporting back that it's still working. I wish I knew what caused it to initially break after a day or so. Maybe WAN IP address change with new lease? But if my iptables script is in WAN UP, wouldn't it reapply that after getting a new WAN IP?

Just reporting back that it's still working. I wish I knew what caused it to initially break after a day or so. Maybe WAN IP address change with new lease? But if my iptables script is in WAN UP, wouldn't it reapply that after getting a new WAN IP?

I can't think of a reason for rules to be flushed like this unless you're messing around in the GUI, sticking scripts into WAN Up (rather than Firewall), or have some other customisations going on. You didn't provide a thorough description of all the configuration settings you change from defaults, or other things about your router, so those trying to help are stuck guessing / grasping at straws.

I also see that in your initial example you have two DSCP setting lines (two rules), which is amusing in itself. This implies something is amiss as well.

If this was a universal problem I would expect other people would be complaining.

Case in point: I have no such problems using tomato-K26USB-1.28.0503.5MIPSR2Toastman-RT-N-Ext.trx on my RT-N16:

What @jerrm said is correct -- said rules need to go into Scripts / Firewall, not Scripts / WAN Up. Therein lies the source of at least one problem (bare minimum the doubling of DSCP set rules). I even covered this in my earlier post, quote: "The iptables command, however, should only be run one once -- repeated runs will append/add unnecessary rules to your PREROUTING chain in the mangle table."

You did follow directions as best they were provided though, @bripab007; the initial post does say to stick one in Init and the other in WAN Up, which is incorrect. Both the modprobe and the iptables command should end up in Firewall under most circumstances.

There are exceptions to this situation, but those would only apply if someone was running a very customised environment (see other threads on this forum for all the crazy stuff people are doing with their routers, making a big mess ); possibly use of VLANs, or WAN connections with PPPoE or PPPoA could need some adjustment.

I've got the rule running and noticed a near doubling of my WiFi speeds to about 57 Mbps.
The only downside is when downloading at that speeds on my E3000 running Toastman's firmware, the CPU usage spikes to around 90%, even over Ethernet. That's with downloads maxing at about 60 Mpbs with an IPV4 speed test. With An IPV6 speed test the CPU maxes out at about 40%.

With Comcast supposedly doubling download speeds by March, I'm don't think the router will be able to handle changing the DSCP without maxing out the CPU.

Edit:

Actually I'm not sure the script is making that big a difference CPU-wise. I deleted the iptable rule using the -d parameter and re-ran a speed test and it was still pretty close to 90% CPU (85%). I didn't reboot so whatever the modprobe command did wasn't undid. I don't know if having the kernel driver loaded alone without the iptable rule would cause an increase in CPU usage.

Anyway when I deleted the iptable rule I could still get 47 Mbps on my iPhone 5S when I tested close to my router. My speeds dropped off dramatically the farther away I got from my router. When I reapplied the iptable rule my speeds increased from 12 Mbps about 30 feet from my router to 40 Mbps (5.2 MHz 802.11n).

@Morac -- You can determine if the module injection is affecting performance by unloading it. Remove the DSCP-related iptables rules then simply rmmod xt_DSCP and re-do any tests. It's that simple.

IMO, your issue sounds completely unrelated to the module. But the concerns over CPU usage (speaking on a general level) given what the mangle table does are justified. It's just another example of the fact that these routers were not designed for massively high throughput, since ~98% of the IP layer is pure software in the kernel. Not much can be done about that. These residential routers pack absolutely no where near the amount of CPU power as a desktop system.

Thanks for all the tips and insight, folks. This does provide a noticeable speed benefit in many circumstances on my wireless devices. Pity it sounds like we'll need to look at stronger routers sometime in the near future, as I've otherwise quite liked the E3000.

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 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.

My Internet went down today. I rebooted my modem and router, but modem was down (it gave router a dummy IP address). When it came back up, I had 3 PREROUTING DSCP rules, which obviously was wrong. I manually removed 2 of them. I was setting the rule in FIREWALL script, so apparently that ran 3 times without removing the iptable rules.

My Internet went down today. I rebooted my modem and router, but modem was down (it gave router a dummy IP address). When it came back up, I had 3 PREROUTING DSCP rules, which obviously was wrong. I manually removed 2 of them. I was setting the rule in FIREWALL script, so apparently that ran 3 times without removing the iptable rules.

Click to expand...

Doesn't surprise me. There are certain situations/conditions where certain parts of the built-in "services" (that's what it's called, and it's hard to explain without actually showing people source code) will re-run the Firewall scripting section.

The workaround is simple: instead of using modprobe xt_DSCP + iptables -t mangle -A PREROUTING ..., use the below instead (which will only run the rule insertion if there isn't an existing rule already found):

tested and no sirq increase, I'm very interested to know Morac's evaluation.. a check box it's always a doubt question for beginners .. the switch it's in the code.

Click to expand...

I don't know if it's that specifically or just Tomato in general, but I have the rule added and when running speed tests on the 100 Mbps speed tier my E3000's CPU usage shoots up over 90% (for ipv4 only for some reason, ipv6 uses much less CPU). Comcast' slowest download speeds are now 50 Mbps.

A checkbox is fine with me, even if it's just used to test the effect of these changes on different routers

Click to expand...

.. Since both of you are more than beginners and great know how, why you don't contribute with your code for the switch function?... help us! , I saw 11 clicks in the link ... http://goo.gl/FHUkrq .. tomato is a teamwork!

By looking at what you changed. You added code to issue the mod change and add the iotable rule when the firewall processing runs when the box is checked. It does nothing if the user had the box checked and then unchecked it.

By looking at what you changed. You added code to issue the mod change and add the iotable rule when the firewall processing runs when the box is checked. It does nothing if the user had the box checked and then unchecked it.

Click to expand...

Other than by hitting the 'Save' button it rebuilds the iptables rules. If in doubt, test, I have provided a sample.

Other than by hitting the 'Save' button it rebuilds the iptables rules. If in doubt, test, I have provided a sample.

Click to expand...

correct, see my comment in your merge request and suggested code to use corner case easier... iptables are flushed. Could you test?, I put the condition before to save work, no need to follow when value not equal to 1. Thanks for your help

I am behind on my firmware updates (3 years) and came across this thread as I was about to update to a recent victek or shibby release. . I am a comcast customer and have noticed relatively slow wifi speeds on my e3000.

Question is have any of the newest releases applied a fix for this comcast issue or a check box that allows me to turn on the fix, or do I still have to figure out how to appl the script sshown above? Thanks

I am behind on my firmware updates (3 years) and came across this thread as I was about to update to a recent victek or shibby release. . I am a comcast customer and have noticed relatively slow wifi speeds on my e3000.

Question is have any of the newest releases applied a fix for this comcast issue or a check box that allows me to turn on the fix, or do I still have to figure out how to appl the script sshown above? Thanks

Click to expand...

With the latest shibby and Raf they should both have the fix and automatically turned on.
You can check whether it's enabled in Advanced -> Firewall.

Unless I'm reading it wrong, koitsu's script (his 2nd to last post in this thread) should work even on systems with the fix implemented - it just won't trigger the script's payload. Just paste it into firewall tab under Administration->Scripts.

Where was the capture done on? The router's WAN interface, or capturing traffic on the local workstation? It needs to be done on the router's WAN interface (tcpdump -p -i vlan2 ...).

The screenshot is also intentionally omitting source and destination -- whether this is an inbound or outbound packet matters. In the future please don't post "snippet" screenshots like this, they're unhelpful in that form. For example, with xt_DSCP in use with --set-dscp 0x00, outbound packets will have a DSCP class of CS0 (Default), but inbound packets from Comcast (at least for me) have a value of 0x08 (CS1). I've attached a capture showing that fact (see IPv4 header, Differentiated Services Field, in the initial SYN (outbound) and the SYN+ACK response (inbound)). This capture was done on the WAN interface of the router. If I was to have done a capture on the workstation doing the HTTP request itself, the response packets from Comcast should (given the way the fix works) use CS0.

1. iptables only processes IPv4 packets (ip6tables is for IPv6),
2. The xt_dscp.ko netfilter module only is for IPv4 (there is no IPv6 version built),
3. The DSCP rule (specifically --set-dscp 0) causes the value to be set to 0 (Class Selector 0).

Of the raw byte, bits 0 and 1 are for ECN and aren't controlled here. So usually when adjusting the DS field, it's the upper 6 bits you're controlling. When you give a value of something like --set-dscp 12 (0x0C in hex, %00001100 in binary), the values don't actually map 1:1 to each raw bit of the full byte -- they actually only affect the upper 6 bits of the DSCP value. In other words, the bits are shifted left by 2. So a value of 12 decimal would actually become %001100xx in the DSCP byte, which would set Priority, Low Delay, Normal Throughput, and Normal Reliability. The DSCP class for this is called AF12.

My general/strong opinion is that the wireless WMM implementation on some Linksys/Cisco routers is ultimately what's responsible for this problem. The workaround in question is to keep the WMM portion of the wireless driver from behaving like an idiot.

The DSCP value is 0x08 on IPv4 (and apparently IPv6) from Comcast. All the DSCP rule on TomatoUSB does (for IPv4, because there's no IPv6 module equivalent built right now) is "mangle" inbound packets (from Comcast to the router's WAN IP, before they get forwarded/NAT'd and shoved through the wireless driver and sent to the appropriate LAN IP), setting DSCP to 0x00. This works around whatever idiocy there is in the wireless drivers relating to WMM for specific models of routers.

I think the core issue is within the wireless driver and only affects specific models of chips/routers. For example, I get the same throughput and performance out of my RT-N16 as well as RT-N66U, from wireless clients on my LAN (a couple laptops, a Nintendo 3DS XL, and a Motorola MotoG phone), both with and without the "DSCP fix". But the OP stated clearly it fixes something for him on Linksys E2000 and E3000 routers, which almost certainly have a completely different set of code (compared to RT-N16 and RT-N66U) being used within the wireless driver. The wireless driver is big and fat and monolithic and has tons of code written for many different chips and revisions of chips. It's closed-source so nobody knows what exactly is going on.

It also could be be that the affected wireless drivers only are inspecting IPv4 packets and instead just "pass through" IPv6 (which in effect would mean the WMM isn't really used when IPv6 is involved).

I have to point out, of course, that I'm sure some people have experienced "problems" that they then say the above fix "magically solves" -- but for all we know they implemented it in Scripts/Init and rebooted the router, which causes the entire wireless driver and hardware to be reset. Meaning: it's very possible just a simple reboot (no DSCP fix) would have alleviated their issues. Really it's one of those things where speed tests have to be done before and after with someone applying and removing the iptables rule in real-time.

Okay, but IPv6 doesn't appear affected? Do you have a way to turn off the entire IPv4 stack on your iPhone, or exclusively use IPv6 somehow (maybe even some kind of firewall rule that just blocks all IPv4 packets to a specific client?), and run a speed test/whatever it is you ran that confirmed the DSCP fix improved things for you? I mention this because there's a lot online that "falls back" to IPv4 in certain circumstances, so you'd really have to make sure that all your tests are truly using IPv6 (through packet captures, etc.).

If pure IPv6 tests are consistent in behaviour/speed/etc., then to me that means the wireless driver is not inspecting IPv6 DSCP fields, hence IPv6 is immune to the problem.

I had a chance to retest 802.11n speeds with the DSCP fix on and off. I had it on, ran the speed test on my laptop (plugged into AC) over WiFi-N and then deleted the iptables rule (no other changes) and ran it again. Here's the results.

With fix:

Without fix:

As you can see the IPv4 speeds dropped by about 75%, while the IPv6 speed actually went up slightly (within margin of error), so the DSCP fix doesn't appear to be needed for IPv6. At least not on a Linksys E3000.

That said, as far as I'm aware the DSCP fix simply makes it so that the 802.11n traffic isn't categorized as low priority. It's possible that there's so little IPv6 traffic that low priority IPv6 isn't throttled.

If I get a chance I can try that. As far as I'm aware the bug only affects the 5.4 GHz band. I can actually get faster speeds with the fix turned off if I'm within about 7 feet of my router, but speeds drop dramatically the farther I get away. Before I found out about the fix, I used to just think 5.4 Ghz had horrible range, but that wasn't the case. I ran the tests above about 25 to 30 feet away from the router.

I, too, can confirm this Comcast and WMM related issue affects me quite dramatically on my E3000 router. Without the fix I'm locked in to ~29Mbps downstream for any of my iDevices. Implementing the fix bumps it up to ~55Mbps.

I had a chance to retest 802.11n speeds with the DSCP fix on and off. I had it on, ran the speed test on my laptop (plugged into AC) over WiFi-N and then deleted the iptables rule (no other changes) and ran it again. Here's the results.

With fix:

Without fix:

As you can see the IPv4 speeds dropped by about 75%, while the IPv6 speed actually went up slightly (within margin of error), so the DSCP fix doesn't appear to be needed for IPv6. At least not on a Linksys E3000.

That said, as far as I'm aware the DSCP fix simply makes it so that the 802.11n traffic isn't categorized as low priority. It's possible that there's so little IPv6 traffic that low priority IPv6 isn't throttled.

Click to expand...

how did you apply the fix to IPv6 packets? the needed module shouldn't be built for tomato? or maybe ip6tables needs to be used.