From another mailing list with an almost identical problem...
http://ckdake.com/content/2008/disable-gateway-smart-packet-detection.html
showed a feature of "Gateway Smart Packet Detection" in some SMC
cable modems. You can get into the SMC device yourself by going to the
http://10.1.10.1/login.asp
link on the SMC. The username/password are well known as
cusadmin/highspeed.
The current solution is to identify the affected
Comcast
modem, and ask
a Comcast engineer to turn that "IDS" feature off
remotely.
Also, these other fixes have been mentioned:
Switching to a TCP tunnel from a UDP tunnel
Running the cable modem in bridge-only mode
On Mon, May 3, 2010 at 11:51 AM, Jeff Bruns
<jeff.bruns@xxxxxxxxx> wrote:
Sake-
Thanks for the explanation. This has been an ongoing issue, as we've been experiencing what I believe is an abnormally large amount of packet loss. We're part of a business VPN provided by Comcast Cable, with a Cisco 2800 series router as our gatekeeper. I'm just about at the point of calling Comcast and having them take a look, but if you've ever dealt with comcast you understand my hesitation.
We have very few devices connected to the network, none of which should be consuming large amounts of bandwidth. A recent speed test on my network shows 6.21Mb/s down and 3.21Mb/s up. I often use pingtest.net to measure jitter, delay and packet loss, but for some reason I can't get the test to connect from my network. Likewise I've tried using iperf to evaluate my network's bandwidth but most non-standard ports are blocked. I've attached a pcap dump file with an example of the packet loss I'm experiencing. This has been occurring on a daily basis sometimes 5 or 6 times a day.
Based on the dump file, can you find any indication suggesting the source of the problem is inside the network? I've been under the assumption that the data loss is happening before the packets hit my local network, somewhere out in Comcast's network. Any ideas of further diagnosing the source of the data loss?
Thanks again-
Jeff
On Mon, May 3, 2010 at 11:58 AM, Sake Blok
<sake@xxxxxxxxxx> wrote:
On 3 mei 2010, at 17:32, Jeff Bruns wrote:
> Thank you for your reply. As suggested, I've attached the wireshark dump file for the TCP transmission in question.
As you said, this looks like a normal completed TCP session, except for the ending of it.
In frame 16, the client sends the final data to the printer and sets the FIN flag to tell the printer it wants to end the session. That FIN is ACKed in frame 19, the printer has seen the FIN, otherwise it would have sent an ACK of 3898 instead of 3899. In frame 21 it sends its own FIN back to the client, however, this FIN is not ACKed by the client. In frame 22 the printer retransmits it's FIN, but by now, the client does not have the session open any more, so it sends back a RST to the printer.
So what could be the problem? First of all, why does the printer send its FIN 2 seconds after receiving the FIN from the client. This however should not directly be problem. What is a problem is that the client does not send an ACK after receiving the FIN from the printer.
Hope this helps,
Cheers,
Sake
