Experimental Physics and Industrial Control System
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
- Replies:
- Re: Corrupt cmd message Noboru Yamamoto
- Navigate by Date:
- Prev:
Re: GreenSpring IP488 Industry Pack Support and New Focus 8732 Controller (fwd) zhang hao
- Next:
RE: zombie problem at UNIX IOC Jeff Hill
- Index:
1994
1995
1996
1997
1998
<1999>
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: GreenSpring IP488 Industry Pack Support and New Focus 8732 Controller (fwd) zhang hao
- Next:
Re: Corrupt cmd message Noboru Yamamoto
- Index:
1994
1995
1996
1997
1998
<1999>
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024