Board index » cppbuilder » TCP/IP CRC Checking Question....

TCP/IP CRC Checking Question....


2006-10-13 12:52:46 AM
cppbuilder114
Hi,
Here's a question for those of you in the know. Does the TCP/IP checksum
field protect against corruption of the data portion, or does it only
protect the TCP/IP header? And is the answer to this different if you use
Win32, Linux, etc?
The reason for the question is that we have been testing robustness of our
systems using a network emulator, and we are able to get corrupt data being
delivered to the application.
Some material on the web implies that the data portion is protected, other
sites (including microsoft) imply the header is only included in the
checksum (and that the UDP checksum is optional?).
Regards
Paul
 
 

Re:TCP/IP CRC Checking Question....

"Paul at NCF" <not XXXX@XXXXX.COM >wrote:
Quote
Here's a question for those of you in the know. Does the TCP/IP checksum
field protect against corruption of the data portion, or does it only
protect the TCP/IP header?
Some material on the web implies that the data portion is protected, other
sites (including microsoft) imply the header is only included in the
checksum (and that the UDP checksum is optional?).
Depends on what layer you are looking at.
www.tcpipguide.com/free/t_toc.htm
www.tcpipguide.com/free/t_IPDatagramGeneralFormat.htm
IPv4 has a Header CRC, doesn't cover data.
www.tcpipguide.com/free/t_IPv6DatagramOverviewandGeneralStructure.htm
IPv6 does away with the Header CRC.
www.tcpipguide.com/free/t_IPDatagramEncapsulation.htm
Farther down, closer to the actual transmission, the packet is placed
in a frame. The frame has a footer wich contains a Frame CRC (FCS)
which does cover the data.
www.tcpipguide.com/free/t_PPPGeneralFrameFormat.htm
Quote
And is the answer to this different if you use Win32, Linux, etc?
The protocols are supposed to be agnostic. That's the whole idea.
 

Re:TCP/IP CRC Checking Question....

So, is it possible in your opinion with Server/Client architecure using
Sockets (TCP/IP) that if I transmit a block of data from A to B, that the
data can arrive corrupted (because thats what we seem to see and achieve
using the Network Emulator whilst inducing a bit error).
"Bob Gonder" < XXXX@XXXXX.COM >wrote in message
Quote
"Paul at NCF" <not XXXX@XXXXX.COM >wrote:

>Here's a question for those of you in the know. Does the TCP/IP checksum
>field protect against corruption of the data portion, or does it only
>protect the TCP/IP header?

>Some material on the web implies that the data portion is protected, other
>sites (including microsoft) imply the header is only included in the
>checksum (and that the UDP checksum is optional?).

Depends on what layer you are looking at.
www.tcpipguide.com/free/t_toc.htm

www.tcpipguide.com/free/t_IPDatagramGeneralFormat.htm
IPv4 has a Header CRC, doesn't cover data.

www.tcpipguide.com/free/t_IPv6DatagramOverviewandGeneralStructure.htm
IPv6 does away with the Header CRC.

www.tcpipguide.com/free/t_IPDatagramEncapsulation.htm
Farther down, closer to the actual transmission, the packet is placed
in a frame. The frame has a footer wich contains a Frame CRC (FCS)
which does cover the data.
www.tcpipguide.com/free/t_PPPGeneralFrameFormat.htm

>And is the answer to this different if you use Win32, Linux, etc?

The protocols are supposed to be agnostic. That's the whole idea.




 

{smallsort}

Re:TCP/IP CRC Checking Question....

"Paul at NCF" <not XXXX@XXXXX.COM >wrote:
Quote
So, is it possible in your opinion with Server/Client architecure using
Sockets (TCP/IP) that if I transmit a block of data from A to B, that the
data can arrive corrupted (because thats what we seem to see and achieve
using the Network Emulator whilst inducing a bit error).
Depends on how you are introducing this bit error.
It seems to me that you would need to splice into the wire, and clamp
the data to ground for one bit-time, precisely during the data segment
of the packet.
Or maybe your Network Emulator allows for non-conforming mid-stream
bit twiddling, as store-modify-forward should entail a new FCS.
Also, be aware that the CRCs are rudimentary in nature, meant to be
fast, not accurate.
If you need bullet-proof transmission, you should add your own ECC to
your data, and add a re-transmit protocol to your c/s code in case the
ECC doesn't correct.
 

Re:TCP/IP CRC Checking Question....

The Network Emulator is a hardware specialised piece of kit by PacketStorm,
I've no idea how it does it, but it does.
www.packetstorm.com/2600e.php
We will be looking in to data integrity checking now that the TCP/IP layer
can't be relied up on.
Thanks for the help.
"Bob Gonder" < XXXX@XXXXX.COM >wrote in message
Quote
Depends on how you are introducing this bit error.
It seems to me that you would need to splice into the wire, and clamp
the data to ground for one bit-time, precisely during the data segment
of the packet.
Or maybe your Network Emulator allows for non-conforming mid-stream
bit twiddling, as store-modify-forward should entail a new FCS.