Wireshark · Wireshark-users: Re: [Wireshark-users] TCP Dup Ack Issues with Comcast vs. Cablevision

[Alan Emery <ademery@xxxxxxxxxx>]

This may be more related to a setting on the wireless access point. If the wireless AP is not set to a fixed mode such as "g" or "n", and it "hears" the presence of a "b" device associated or not, it will go into a compatibility mode and effectively run at the lower "b" rate. In my SOHO environment, I fix my wireless mode to "g" as that is compatible with all the devices I want to have connected, but if a guest brings in a "b" mode device, they cannot connect, but they don't downgrade the throughput of my existing network. Your 6-9 Mbps throughput is more typical of what I would expect in a "b" environment.

If you can isolate the wireless AP to a switch that will allow you to connect a local target device, or to switch ports on the AP if available, you can look at throughput just going through the AP to a local target device to see if the issue lies with the AP or not.

Alan Emery

IBM Global Solution Center
1177 S Beltline Road, Coppell, TX 75019

William Howard ---02/26/2010 09:32:29 AM---We have been investigating what seems to be an obscure issue with regards to Comcast speeds wired v

From:	William Howard <wghoward@xxxxxxxxxxxxx>
To:	wireshark-users@xxxxxxxxxxxxx
Date:	02/26/2010 09:32 AM
Subject:	[Wireshark-users] TCP Dup Ack Issues with Comcast vs. Cablevision
Sent by:	wireshark-users-bounces@xxxxxxxxxxxxx

---

We have been investigating what seems to be an obscure issue with regards to Comcast speeds wired vs. wireless "G" speeds on a 30/5 circuit.

Here are the symptoms:

Wired (directly to modem): Speeds are what one would expect - 25-30 Mbps down and 4-5 Mbps up.

Wireless: Speeds are in the 6-9 Mbps. We have tried a variety of consumer and higher end APs/Wireless routers. All with the same basic results - the speeds are significantly slower.

• The wireless NIC was connected with a "good" signal at 54 Mbps.
• I verified that wireless interference was not an issue.
• I tried several different laptops to make sure that the particular wireless NIC was an issue.
• The AP/Router were the only items on the circuit. Time of day did not matter as I tried going back and forth between wired and wireless - both produced consistent speeds each time.

What we did discover is that when testing the same equipment on a cablevision/optimum online 30/5 circuit, the problems virtually disappear. Wired speeds are equivalent to Comcast but wireless speeds were in the 15-19 Mbps range.

In order to dig deeper, I captured wireshark traces for both wired/wireless on Comcast and Optimum Online circuits. The biggest difference I could find is that on the Comcast circuit both wired and wireless, there were many: TCP Dup ACK packets (see below for an example)

TCP [TCP Dup ACK 17802#55] http > apc-3052 [ACK] Seq=8154484 Ack=307815 Win=206848 Len=0 SLE=370595 SRE=447975 SLE=331175 SRE=335555

I have seen the "tcp optimizers" and they have produced good results and have improved the Comcast speeds to 12-16 Mbps but it seems very odd that only Comcast seems to suffer from packets arriving out of order (or whatever is causing this) but Cablevision does not. I don't like the idea of having to change a client device when it seems like this problem lies within the Comcast network.

Has anyone seen this before? Is there a solution without changing the client laptop? We would like to have a solution that is hardware based (router or firmware) rather than telling users they must all make registry changes which makes us nervous (liability) and end-users irritated that "it works on other networks without a problem"

Any insight on this would be greatly appreciated.

Will Howard___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
            mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe