Re: pvxput denied via EPICS_PVA_NAME_SERVERS but works via EPICS_PVA_ADDR_LIST --- (pvxs 1.5.1 / p4p 4.1.7)

[Michael Davidsaver via Tech-talk <tech-talk at aps.anl.gov>]

Hi Ernest,

On 3/6/26 11:41 AM, Williams Jr., Ernest L. via Tech-talk wrote:

...Client Environment

Client tool: pvxs 1.5.1
Gateway implementation: p4p 4.1.7

Is this "stock" PVXS, or the SPVA development branch?

Also, the latest P4P is 4.2.2.  Could you test with this version?

wrt. gateway testing.  What does the "<statusprefix>asTest" RPC call show?  This call should return the identity which p4p.gw would use for ACF decisions.

https ://epics-base.github.io/p4p/gw.html#status-pvs

...

Question

Is it expected that the p4p gateway behaves differently for put authorization depending on whether the PV was resolved through:

• UDP search (EPICS_PVA_ADDR_LIST)
• TCP name-server mode (EPICS_PVA_NAME_SERVERS) ?

No.

In particular, should both mechanisms ultimately route the client through the same gateway path and authorization logic, or is there a known difference in how these endpoints are handled?

This is not expected...  Unless SPVA comes into the picture, and there are legitimately two different TCP ports.  One for plain PVA, and a second for TLS+PVA.

Our longer-term goal is to standardize on EPICS_PVA_NAME_SERVERS, since it works much better for containerized environments and controlled network paths. Before moving forward with that approach, I wanted to confirm whether the behavior I am seeing is expected or if I might be missing something in the gateway configuration.

Maybe relevant, with SPVA development branch, PVXS will understand an extended syntax to specify protocol as well as port.

export EPICS_PVA_NAME_SERVERS="pva://1.2.3.4 pvas://1.2.3.4"

(Yes, I know it the prefix should now be "spva://", but this schema pre-dates that name change)

If helpful, I can also provide packet traces or additional logs from the gateway side.

Thanks very much for any guidance.

Cheers,

Ernest Williams
Dept. Head, Controls Software Engineering
Instrumentation Division, Technology Innovation Directorate
SLAC National Laboratory, Stanford University