Re: CAS: partial (damaged?) UDP msg

["Shen, Guobao" <shen@frib.msu.edu>]

It seems he has two different CAS, one is C#, another is
LabVIEW CAS.
Unclear that whether those 2 run in the same IOC process.

From Yuliang's info, I guess the IOC started properly, and problem happened somewhere in the middle during IOC run.
A wireshark would be helpful to verify where the package was truncated, and when.

Thanks,
Guobao

-------- Original Message --------
Subject: Re: CAS: partial (damaged?) UDP msg
From: Michael Davidsaver
To: Zhang Yuliang ,tech-talk
CC:

I've seen messages like this pop up occasionally with no apparent ill
effects.

What is 10.1.204.140?  Is this host expected to run CA clients?  If so,
which implementation(s)?  Something other than libca or CAJ?

On 04/15/2017 07:27 AM, Zhang Yuliang wrote:
> Hi all,
>
> I found that one soft ioc output the following information:
>
> epics> CAS: partial (damaged?) UDP msg of 8 bytes from 10.1.204.140:54439 ?

The shortest valid CA message is 16 bytes.  So any packet set to UDP
port 5064 with length 8 is clearly invalid.  Practically, CA search
broadcasts will have more than 32 bytes.  A Version message and at least
one Search message with a non-zero payload.

FYI http://www.aps.anl.gov/epics/base/R3-16/0-docs/CAproto/index.html

> CAS: request from 10.1.204.140:54439 => CAS: Missaligned protocol rejected
> CAS: Request from 10.1.204.140:54439 => cmmd=0 cid=0x4143435f type=0 count=3100 postsize=3100
> CAS: Request from 10.1.204.140:54439 =>   available=0x4c524254         N=3 paddr=(nil)

The offending header was:

> 00000c1c 00000c1c 4143435f 4c524254

This looks like bytes 8-24 of a search message with a searchID 0xc1c for
a PV name beginning with "ACC_LRBT".

Very odd.  It appears that a CA search packet is getting split into two
packets at offset 8.  I don't know how this could happen.

...
> At that time, all of our Labview and C# type CA servers hung up(the standard iocs were all ok), no response to the ca search from clients. After we reboot the ca servers, it return to OK.
> It is the first time we saw this and I think the ca server hung up event has relation to the invalid request.

If these are only CA servers, then I suspect that these hangs are an
effect, not the cause.  Probably improper handling of truncated search
messages.