Still celebrating National IT Professionals Day with 3 months of free Premium Membership. Use Code ITDAY17

x
?
Solved

CRC errors seeing on Windows Vista and Windows 7 machines but not on Windows XP

Posted on 2010-08-12
7
Medium Priority
?
948 Views
Last Modified: 2012-05-10
Hello,

While I was troubleshooting session disconnects and had to capture traffic on my PC, I discovered that in addition to the disconnects, there were CRC errors on the IP packets. Further checking with Cisco's help showed that this condition was present on my two test PCs, one Windows Vista and one Windows 7. When we tested a Window XP we found no CRC errors in the frames.

The Cisco TAC engineer and I checked every single switch port and trunk-port involved in the path between my two VLANs that were traversed and the router ports as well. No input errors, no CRC errors, at all.

Even packets to the text Windows XP, which is in the same subnet as the Vista and 7 machines show the errors.

Please see attached screen capture of the wireshark net capture. The error occurs on every packet sourced from the Vista computer (10.20.0.95)

If you have any idea or there is a know IP condition in Windows Vista and Windows 7, I'd like to know if there is a workaround or solution to this.

This problem is not the cause of my session disconnects. Wireshark capture - from Vista
0
Comment
Question by:xperttech
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 3
  • 3
7 Comments
 
LVL 4

Expert Comment

by:mop_se
ID: 33424831
Normally when I have had crc errors it's because of faulty ethernet cables.
0
 
LVL 6

Expert Comment

by:univision-computers
ID: 33425137
You could try updating the NIC drivers as well, are the Vista and 7 machines the same hardware/model?
0
 
LVL 5

Author Comment

by:xperttech
ID: 33425296
Sorry experts. I forgot to mention I had already changed my Vista cable with a new cat 5e. No change.
The Vista machine is a Dell workstation, and the Windows 7 an HPmini netbook.
Too much coincidence the drivers would be the issue, but I will try that.
0
Plug and play, no additional software required!

The ATEN UE3310 USB3.1 Gen1 Extender Cable allows users to extend the distance between the computer and USB devices up to 10 m (33 ft). The UE3310 is a high-quality, cost-effective solution for professional environments such as hospitals, factories and business facilities.

 
LVL 6

Expert Comment

by:univision-computers
ID: 33425542
I vaguely remember having to change the MTU settings in the registry to fix other network related problems with Vista.  I can't seem to find a related article at the moment though.
0
 
LVL 5

Author Comment

by:xperttech
ID: 33430610
Now I need to add to the affected systems by this condition Windows 2008 R2.

I discard the possibility of this being a local issue to the affected hosts. Now I am finding out that my time-sensitive alerts are being generated to to the disconnects in other systems.

No one has seen this???

It looks like a stack issue, but is this a bug starting at Windows Vista on the IP stack???
0
 
LVL 6

Expert Comment

by:univision-computers
ID: 33431192
This article from Cisco may be helpful, although not exactly your setup perhaps.
https://supportforums.cisco.com/message/1326710
0
 
LVL 5

Accepted Solution

by:
xperttech earned 0 total points
ID: 33475265
The problem has to do with TOE (TCP Offload Engine) present in 1Gb and 10Gb NICs. The TCP checksum calculations are passed on to the NIC's CPU for processing as opposed to being calculated by the driver (computer's CPU) favoring thus the performance.

Wireshark is capturing at the software level when you do this right on the computer generating the traffic. When Wireshark captures the TCP/UDP packets, these don't have the checksum computed yet and that's why they are reported as incorrect. The checksums are calculated right before the packets go out the wire and this is long after Wireshark had already captured them.

Disabling the TCP/UPD checksum offload feature in a NIC is recommended ONLY for testing purposes. Instead, you should disabling the feature at Wireshark to avoid the false-positive warnings.

These articles better explains the condition:
http://wiki.wireshark.org/TCP_Checksum_Verification
http://packetlife.net/blog/2008/aug/23/disabling-checksum-validation-wireshark/
0

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

If you’re involved with your company’s wide area network (WAN), you’ve probably heard about SD-WANs. They’re the “boy wonder” of networking, ostensibly allowing companies to replace expensive MPLS lines with low-cost Internet access. But, are they …
This article explains the fundamentals of industrial networking which ultimately is the backbone network which is providing communications for process devices like robots and other not so interesting stuff.
Internet Business Fax to Email Made Easy - With  eFax Corporate (http://www.enterprise.efax.com), you'll receive a dedicated online fax number, which is used the same way as a typical analog fax number. You'll receive secure faxes in your email, f…
In this video we outline the Physical Segments view of NetCrunch network monitor. By following this brief how-to video, you will be able to learn how NetCrunch visualizes your network, how granular is the information collected, as well as where to f…

722 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question