Setting EPICS_CA_NAME_SERVERS creates an anonymous client TCP circuit

[Andrew Johnson]

Setting EPICS_CA_NAME_SERVERS causes a CA client to open a TCP connection to the given list of servers and to use those sockets for name resolution. If a server is actually an IOC, the same TCP circuit will be reused for all default priority data connections to that IOC, but the IOC is never actually sent the user or host names by the client, so they appear empty in the output from casr. The names are mainly used by the CA Access Security subsystem.

Setting EPICS_CA_NAME_SERVERS might thus a nice way to limit CA clients to connect to a small set of IOCs, but doing so doesn't permit access security to be used properly.

I tested this by starting a softIoc on my workstation tux, then running camonitor thusly:
    tux$ EPICS_CA_NAME_SERVERS='tux' camonitor <pv-name>
Run 'casr 1' on the iocsh console to see the client's host and user-name.

Adding a '-p 10' argument to camonitor causes it to create a new TCP circuit for the data, which *does* have the user and host names. Doing this causes the name resolution TCP circuit to be shown as V4.0, so I wonder if whatever mechanism causes the minor version number to be sent might also be able to be used to send the user and host names.

[mdavidsaver (mdavidsaver)]

The issue is that the decision to send the user+host names is condition on "CA_V41 ( this->minorProtocolVersion )" in tcpiiu::userNameSetRequest() which is called from the tcpiiu ctor. In the case of TCP name servers, the server proto version isn't known when tcpiiu is constructed.

A fix might be to immediately send the client version, then wait for the server version before deciding to send the user+host. Of course I may be assuming details of CA rev. 0 which aren't correct.

Alternately we could deprecate CA rev. 0...

[mdavidsaver (mdavidsaver)]

I rediscovered this issue, which manifests with RTEMS+qemu as

> EPICS_CA_AUTO_ADDR_LIST=NO EPICS_CA_NAME_SERVERS=localhost caget cnt
> Channel connect timed out: 'cnt' not found.
> CA Client Library: Ignored duplicate create channel response from CA server?

As we have now dropped support for CA rev. 0, I'll see about fixing this.

[mdavidsaver (mdavidsaver)]

FYI, packet capture shows no duplicate create channel response, in fact there is no create channel response at all.

[mdavidsaver (mdavidsaver)]

> As we have now dropped support for CA rev. 0, I'll see about fixing this.

right... support for rev 0 clients is dropped, servers are still supported. However, I think it's safe to start by assuming that servers listed in EPICS_CA_NAME_SERVERS support name lookup over TCP. This will be overwritten when the server's version message is processed.

[mdavidsaver (mdavidsaver)]

> EPICS_CA_AUTO_ADDR_LIST=NO EPICS_CA_NAME_SERVERS=localhost caget cnt
> Channel connect timed out: 'cnt' not found.
> CA Client Library: Ignored duplicate create channel response from CA server?

This error is unrelated. It seems that libca has an effective ~1 second timeout after sending a create channel message during which the response must come. My emulator is sometimes slower than this, probably an issue with timer or nic emulation.

[mdavidsaver (mdavidsaver)]

269f8287337ba50bbcd5aed2152cf5ff4fa832f4

Assume that servers listed in EPICS_CA_NAME_SERVERS support at least CA minor version 11.
This will allow the User and Host name messages to be sent. However, until
the server Version message (with minor>=12) is received; no TCP searches will be attempted.