Re: Help interpreting CA protocol

[Torsten Bögershausen via Tech-talk <tech-talk at aps.anl.gov>]

On 2025-02-26 22:27, Nicholas Devenish via Tech-talk wrote:
> Hi All,
>
> I've been studying the CA protocol documentation (https://urldefense.us/v3/__https://docs.epics-__;!!G_uCfscf7eWS!aTxesKNErFhWzZqoLtXYQ8n_u91GJ65NU3FGdt4j1xWVPRiV1zx1wb2q2CXeYdmuVQx9btN1vd6qzL2py3g$  
> controls.org/en/latest/internal/ca_protocol.html <https://urldefense.us/v3/__https://urldefense.us/__;!!G_uCfscf7eWS!aTxesKNErFhWzZqoLtXYQ8n_u91GJ65NU3FGdt4j1xWVPRiV1zx1wb2q2CXeYdmuVQx9btN1vd6q2lCvDsw$  
> v3/__https://urldefense.us/v3/__https://docs.epics-controls.org/en/latest/internal/__;!!G_uCfscf7eWS!aTxesKNErFhWzZqoLtXYQ8n_u91GJ65NU3FGdt4j1xWVPRiV1zx1wb2q2CXeYdmuVQx9btN1vd6q0PvYOvE$  
> ca_protocol.html__;!!G_uCfscf7eWS! 
> dwV8pgHJV9rl9EbL0tQjbRZmXIAOZQbpf_OA3nJ3y3qqIB7xeyGF9oAUWJXSx8EjIYWd4Bt6SDxTRokN0N_oGUA$>), attempting to implement the
> CA protocol as a learning exercise to become more familiar with EPICS. I've
> found a few points of confusion that I'd appreciate help resolving - I 
> think in
> other places the source is referred to as the final word, but I've not 
> yet gotten
> good at finding things/navigating through the code base, (so tips on 
> that/documented structure would also be welcomed).
> Apologies for several large questions:
>
> -----
>
> CA_READ / CA_READ_NOTIFY Responses
>
> The response is listed (for both responses) as parameter1 being "Server 
> ID": https://urldefense.us/v3/__https://docs.epics-controls.org/en/latest/internal/__;!!G_uCfscf7eWS!aTxesKNErFhWzZqoLtXYQ8n_u91GJ65NU3FGdt4j1xWVPRiV1zx1wb2q2CXeYdmuVQx9btN1vd6q0PvYOvE$  
> ca_protocol.html#id23 <https://urldefense.us/v3/__https://docs.epics- 
> controls.org/en/latest/internal/ca_protocol.html*id23__;Iw!! 
> G_uCfscf7eWS! 
> dwV8pgHJV9rl9EbL0tQjbRZmXIAOZQbpf_OA3nJ3y3qqIB7xeyGF9oAUWJXSx8EjIYWd4Bt6SDxTRokNNQZMe98$>, however in the "ECA Error/Status codes section", it explicitly mentions that return codes are sent in CA_PROTO_READ_NOTIFY, and the (invaluable) Wiresharks EPICS plugin at https://urldefense.us/v3/__https://github.com/mdavidsaver/cashark__;!!G_uCfscf7eWS!aTxesKNErFhWzZqoLtXYQ8n_u91GJ65NU3FGdt4j1xWVPRiV1zx1wb2q2CXeYdmuVQx9btN1vd6q1k8xnnw$  <https://urldefense.us/v3/__https://github.com/mdavidsaver/cashark__;!!G_uCfscf7eWS!dwV8pgHJV9rl9EbL0tQjbRZmXIAOZQbpf_OA3nJ3y3qqIB7xeyGF9oAUWJXSx8EjIYWd4Bt6SDxTRokNbHHCeDo$> does indeed list parameter1 as being the ECA return code.
> Is this just a typo in the protocol documentation, and this field should 
> indeed be the Status code instead of the Server ID? If not, presumably I 
> send a CA_PROTO_ERROR instead of the expected response?
> -----
>
> CA_PROTO_SEARCH:
>
> In the "comments" section `CA_PROTO_SEARCH` rather definitively says:
>
>      > It is illegal to specify `DO_REPLY` flag whenever the message is 
> sending as UDP datagram, regardless of whether broadcast or multicast is 
> used."
> However, immediately below it says:
>
>      > Reply flag will be __generally__ DONT_REPLY when searching using 
> broadcast
> The choice of "generally" seems to imply that it can be set on a UDP 
> search? In addition, the description for CA_PROTO_NOT_FOUND response 
> says that it _is_ sent over UDP:
>      > Sent in response to CA_PROTO_SEARCH, but only when its DO_REPLY 
> flag was set. Sent over UDP.
> Is this supposed to be sent if searching via UDP, and the notify flag is 
> set, or ignored?
> -----
>
> Shorter questions:
>
> - CA_VERSION lists several fields as "Must be 0". However, whilst 
> sniffing the broadcast packets on our beamline network, I see quite a 
> lot of searches where these fields have data in (and version is listed 
> as 13). Are these malformed and should be ignored, or pragmatically 
> replied to?
I suspect that this is the minor version of the ca protocol:

epics/base/modules/ca/src/client/nciu.h

Version 4 is the major version.
In order to distinguish major version 1..4 different port numbers
had been used.  5064 is/was the port for version 4.
I don't know if anybody still uses older versions ? Most probably not.

Anyway, the minor version is for example used here:
For an IPv4 beacon we see:
  m_cmmd           CA_PROTO_RSRV_IS_UP
  m_postsize       0 for IPv4
  m_dataType       CA_MINOR_PROTOCOL_REVISION
  m_count          ca_server_port
  m_cid            beaconCounter++
  m_available      IPv4 address of the server

More information can be found in the source code:
epics/base/modules/ca/src/client/caProto.h


I once made a version of EPICS base that has lots of debug prints in the
ca code. Please let me know, if you are intetested.

As said elsewhere, updates to the documentation are wellcome.
And more questions of course.






> - The ECA Error-status-code-table at https://urldefense.us/v3/__https://docs.epics-controls.org/en/__;!!G_uCfscf7eWS!aTxesKNErFhWzZqoLtXYQ8n_u91GJ65NU3FGdt4j1xWVPRiV1zx1wb2q2CXeYdmuVQx9btN1vd6qZ7lw57E$  
> latest/internal/ca_protocol.html#eca-error-status-codes <https:// 
> urldefense.us/v3/__https://urldefense.us/v3/__https://docs.epics-controls.org/en/latest/internal/__;!!G_uCfscf7eWS!aTxesKNErFhWzZqoLtXYQ8n_u91GJ65NU3FGdt4j1xWVPRiV1zx1wb2q2CXeYdmuVQx9btN1vd6q0PvYOvE$  
> ca_protocol.html*eca-error-status-codes__;Iw!!G_uCfscf7eWS! 
> dwV8pgHJV9rl9EbL0tQjbRZmXIAOZQbpf_OA3nJ3y3qqIB7xeyGF9oAUWJXSx8EjIYWd4Bt6SDxTRokNMvMDmZQ$> lists `ECA_INTERNAL` as Severity "`CA_K_FATAL`". But this doesn't seem to be a valid severity (any more?). Should this read `CA_K_SEVERE`, or there is another (higher) value not documented by the severity code table?
> Thanks,
>
> Nick Devenish
> (Diamond Light Source)