Comment 13 for bug 1971737

I now understand the problem:

EPICS 3.13 clients do not send a CA_PROTO_VERSION message in their search requests but instead have the CA minor version (which is 8) in the m_count field in the CA_PROTO_SEARCH message (the same location as the CA_PROTO_VERSION would have it).
EPICS 3.14+ clients still have that (in addition to the CA_PROTO_VERSION message). The code even checks the m_count field (and not client->minor_version) in search_reply_udp and search_reply_tcp. Also see the comment in search_reply_udp: "starting with V4.4 the count field is used (abused) to store the minor version number of the client."

But the connect consist of the TCP messages CA_PROTO_CLIENT_NAME, CA_PROTO_HOST_NAME and CA_PROTO_CREATE_CHAN. Again no initial CA_PROTO_VERSION message. Instead the version is embedded in the m_available field of CA_PROTO_CREATE_CHAN message. Thus we cannot test for the version until that message has been received.

Thus the "ignore deprecated clients" check in camessage would need to let the following messages pass without version test: CA_PROTO_VERSION, CA_PROTO_SEARCH, CA_PROTO_CLIENT_NAME, CA_PROTO_HOST_NAME, CA_PROTO_CREATE_CHAN. (The last 3 are TCP only).

What I do not understand is what that code is actually supposed to protect against. What are those "deprecated clients" and what would break if they would not be ignored? The log message just says "ignore CA client version older than v4.4" but not why.