Experimental Physics and
Industrial Control System

[email protected] (Jeff Hill) · Fri, 17 Dec 1999 12:43:48 -0700

Hi Noboru,

> Ocasionally, we receive the following message on IOC and some of our WS.
>
> CAC: post_msg(): Corrupt cmd in msg 5
> ../iocinf.c: bad UDP msg from port=5064 addr=172.19.63.255
>
> It is definitely related to a call of ca_search. I (think) there is a
program
> other than CA server which uses the UDP port 5064 to accept connection on
> our network. So, it is not the problem of CA library.

This is possible. Or it is also possible that in extreme situations
that a damaged packet could, despite odds to the contrary, pass through
the Ethernet and IP CRC checksum filters undetected. It is also possible
that
there is an undiscovered bug in CA that causes this. I reported some time
back that I had seen a "bad UDP message" diagnostic when regression testing
R3.14, but I have subsequently discovered that my efforts in R3.14 to make
the CA libraries more robust went too far and I had eliminated support for
an
infrequently used protocol between the CA repeater and the CA client. After
restoring portions of the code that I removed I no longer see this
diagnostic,
and so the cause of these "bad UDP message" diagnostics occasionally seen in
R3.13
remains a mystery.

This diagnostic appears to be quite rare. Any additional information that
other sites in the collaboration can provide about the surrounding
circumstances
that might influence this situation are greatly appreciated.

> Anyway to get more information on this corrupt message, I activated
> debugging message statements in src/ca/service.c
>
> Then the second attempt to read the same channel produces the
> following messages.
>
>
> >>> ca.Get("CO_IOC:COCCC:CLOCK")
> <<unknown host>> Cmd= 13 Type=  0 Count=5064 Size=   0 Avail=7a3313ac
> Cid=     0         addr=127.0.0.1
> <<unknown host>> Cmd= 13 Type=  0 Count=5064 Size=   0 Avail=7c3313ac
> Cid=     0         addr=127.0.0.1
> <<unknown host>> Cmd= 13 Type=  0 Count=5064 Size=   0 Avail=433313ac
> Cid=     0         addr=127.0.0.1
> <<unknown host>> Cmd= 13 Type=  0 Count=5064 Size=   0 Avail=aa3b13ac
> Cid=     0         addr=127.0.0.1
> <<unknown host>> Cmd= 13 Type=  0 Count=5064 Size=   0 Avail=153b13ac
> Cid=     0         addr=127.0.0.1
> <<unknown host>> Cmd= 13 Type=  0 Count=5064 Size=   0 Avail=803b13ac
> Cid=     0         addr=127.0.0.1
> <<unknown host>> Cmd= 13 Type=  0 Count=5064 Size=   0 Avail=183313ac
> Cid=     0         addr=127.0.0.1
> IOCCOCCC:5064 Cmd= 15 Type= 14 Count=   1 Size=  56 Avail=       1
> Cid=16777216  addr=172.19.51.7
> '99/12/03 10:57:14'
>
> I wonders if it is normal to receive many
>
> " CA_PROTO_RSRV_IS_UP     13u     /* CA server has joined the net */ "
>
> messages from the local hosts(127.0.0.1)?

Yes, this is normal. The CA client receives beacon messages
(CA_PROTO_RSRV_IS_UP)
indirectly via the CA repeater daemon running on the local host. These
beacons
occur quite close together in time, but with an exponentially increasing
period,
briefly after an IOC boots.

>
> By the way, we now use a patched iocCore for the (RISC architecture
specific) assertion-error. It
> works just fine on our iocs( Force Powercore 6750/6403, Force CPU-64/40).
We don't see
> that error since then.
>

Thanks for letting us know about your experience with this patch.

Jeff

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System