TCP/IP CRC Checking Question....

Thread View: borland.public.cppbuilder.internet.socket

5 messages

[T] Back to Threads [V] Tree View [G] Group Articles

5 total messages Started by Paul at NCF Thu, 12 Oct 2006 16:52

#1856

Author: Paul at NCF
Date: Thu, 12 Oct 2006 16:52

18 lines
1541 bytes

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....

#1858

Author: Bob Gonder
Date: Thu, 12 Oct 2006 18:33

28 lines
2124 bytes

"Paul at NCF" <not plmacca@clara.co.uk> 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.
http://www.tcpipguide.com/free/t_toc.htm

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

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

http://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.
http://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.

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

#1859

Author: Paul at NCF
Date: Thu, 12 Oct 2006 19:07

40 lines
2687 bytes

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" <notbg@notmindspring.invalid> wrote in message 
news:511ti29hn8m5vipvi8hqlaajp9gqfs5da3@4ax.com...
> "Paul at NCF" <not plmacca@clara.co.uk> 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.
> http://www.tcpipguide.com/free/t_toc.htm
>
> http://www.tcpipguide.com/free/t_IPDatagramGeneralFormat.htm
> IPv4 has a Header CRC, doesn't cover data.
>
> http://www.tcpipguide.com/free/t_IPv6DatagramOverviewandGeneralStructure.htm
> IPv6 does away with the Header CRC.
>
> http://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.
> http://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.
>
>
>
>

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

#1860

Author: Bob Gonder
Date: Thu, 12 Oct 2006 22:19

19 lines
2006 bytes

"Paul at NCF" <not plmacca@clara.co.uk> wrote:

>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....

#1866

Author: Paul at NCF
Date: Sat, 14 Oct 2006 08:32

19 lines
1990 bytes

The Network Emulator is a hardware specialised piece of kit by PacketStorm, 
I've no idea how it does it, but it does.

http://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" <notbg@notmindspring.invalid> wrote in message 
news:tfeti2lsedhn069clj0r6455rahk9233vb@4ax.com...
> 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.

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads