|
The trick there is to test with multiple
PCs on both ends of the circuit to eliminate possible driver/NIC/OS issues;
that should almost always be the first step of troubleshooting, to start at the
ends and work your way to the middle. I will tell you, we’re currently on
our second test server since we started to develop errors on the first one that
we traced to either a NIC or driver issue. Thanks, Network Engineer Data Access/Datapatch,
Inc. (201) 843-5468 x7032 From: John Traynor
[mailto:John.Traynor@xxxxxxx] Pardon my intrusion, but I've had a very
similar problem within out small office network. Are you certain that the
problem lies on the internet side? I have spent hours trying to track
down the issue and have now concluded that it is an errant driver on one
machine that is causing the problem. Initially I suspected several other
things, but persistent testing has pinpointed our problem to a single PC.
File copies of a 100MB file FROM that machine to any other machine takes well
over 5 minutes. In safe mode with only two nodes active that same copy
takes about 15 seconds. I have additional testing ahead to try to
identify the specific driver, but I believe the end is in sight and its not
what I originally believed it would be. Good luck. From: wireshark-users-bounces@xxxxxxxxxxxxx
[mailto:wireshark-users-bounces@xxxxxxxxxxxxx] On Behalf Of I have a couple of customers that have
been complaining of issues on their circuits, an issue that causes them to have
problems with large file transfers. The only noteworthy problems in their data
streams seem to be TCP Dup Acks – I’ve seen as many as sixty, or
over a hundred, in file transfers of 100 MB test files. However, as near as I
can determine, these errors are being introduced in the Internet, outside of
our network (the customers use VPNs over internet circuits with major carriers
for these file transfers). As I said, we’ve tested our own
network thoroughly, but I’m at a loss as to where to go with this issue.
Obviously, telling the customer, “It’s not our fault” is
unacceptable, as that doesn’t move them any closer to error-free file
transfers. On the other hand, I’m not sure where to tell the
carriers’ help desk technicians to look for the source of this issue. Has
anyone seen this before on Internet circuits, and is there some way I can use
Wireshark to help pinpoint the issue more specifically than telling the
carrier, “It’s in your cloud”? Thanks, Network Engineer Data Access/Datapatch,
Inc. (201) 843-5468 x7032 |
- References:
- [Wireshark-users] TCP Dup Ack
- From: Roland Volz
- Re: [Wireshark-users] TCP Dup Ack
- From: John Traynor
- [Wireshark-users] TCP Dup Ack
- Prev by Date: [Wireshark-users] No H.225 (H.323 messages) in "Decode as"
- Next by Date: [Wireshark-users] missing NTP packets
- Previous by thread: Re: [Wireshark-users] TCP Dup Ack
- Next by thread: Re: [Wireshark-users] TCP Dup Ack
- Index(es):