Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Wed, 20 Mar 2002 12:02:02 -0700

Geoff,

The Ethernet hardware layer and also most of the IP protocols include
CRC checksums that detect a limited degree of packet damage. This allows
degraded communication to continue over amazingly poor hardware links
because damaged TCP frames are retransmitted. However, if the number of
bits damaged in a packet is high enough then damaged IP frames can be
passed undetected up through the layers to CA. The UDP protocol also
includes a CRC checksum, but there is an option to turn this off with
certain IP kernels (not recommended).

The ECA_BADTYPE message you are receiving probably results from a sanity
check performed by the CA client library prior to swapping the bytes of
the incoming data. The incoming data type was probably damaged and
therefore out of range so CA passed the ECA_BADTYPE status code up to
the client side tool's call back function. There are many other protocol
sanity checks in CA so this situation would probably occur only in an
environment where the CA client library was discarding (sometimes
silently) many of the other messages from the server because of bad
resource identifiers and other problems. In contrast, the CA server will
disconnect from any client that sends a poorly formed request.

My guess is that you were able to connect because the CA client library
will repeatedly attempt to reconnect in an environment where many of the
frames are damaged and the server disconnects. In contrast, the read
request protocol is not reissued when it fails because CA assumes that
the TCP circuit, once established, is reliable. This is probably a
correct assumption because TCP circuits are reliable except in an
exceptionally poor network hardware environment.

I saw a situation where damaged packets appeared to be getting through
to CA on the LEDA project. I concluded at the time that this must have
been caused by some early 3com 10/100 switch hardware that was not
properly auto negotiating the link speed. After this experience, a new
procedure was initiated where IOCs were powered up after the switches if
the network infrastructure lost power, and this appears to have resolved
the problem.

The R3.13.1 patch release of R3.13 has changes to make the CA server
more robust in an exceptionally poor network hardware environment where
damaged frames are not detected by CRC checksums.

Jeff

> -----Original Message-----
> From: Geoff Savage [mailto:[email protected]]
> Sent: Wednesday, March 20, 2002 10:51 AM
> To: [email protected]
> Subject: ECA_BADTYPE
> 
> Hi,
> 
> We moved a computer in our control room yesterday and the CA clients
are
> returning a status of ECA_BADTYPE for some of the reads.  The record
> being read is one unique to our hardware.  The field is of type
> DBR_LONG.  The switch reports errors on the port to which the host is
> connected.  These errors are Align-Err and FCS-Err.  Why would CA fail
> in this mode?  I could see a problem with connecting but I don't
> understand a problem of performing a number of reads correctly and
then
> a number of reads fail with BADTYPE.
> 
> Thanks for the assistance.
> 
> Geoff

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System