pvagw name resolution issue in v4.2.1

[gilesknap]

I'm seeing the following isssue when using p4p v4.2.1.

When I set EPICS_PVA_ADDR_LIST it works fine for pvxget but fails for pvagw as follows:

$ pvagw /tmp/pvagw.config
INFO:p4p.gw:*** Gateway STARTS now using "/tmp/pvagw.config".
INFO:p4p.gw:Client effective configuration for theclient:
INFO:p4p.gw: EPICS_PVA_ADDR_LIST : bl01t-mo-sim-01 bl01t-di-cam-01 bl01t-ea-fastcs-01
INFO:p4p.gw: EPICS_PVA_AUTO_ADDR_LIST : NO
INFO:p4p.gw: EPICS_PVA_BROADCAST_PORT : 5076
INFO:p4p.gw: EPICS_PVA_SERVER_PORT : 5075
2025-10-01T10:17:10.598392304 ERR pvxs.config EPICS_PVA_ADDR_LIST ignoring invalid 'bl01t-mo-sim-01' : Error resolving "bl01t-mo-sim-01" : nodename nor servname provided, or not known
2025-10-01T10:17:10.598754501 ERR pvxs.config EPICS_PVA_ADDR_LIST ignoring invalid 'bl01t-di-cam-01' : Error resolving "bl01t-di-cam-01" : nodename nor servname provided, or not known
2025-10-01T10:17:10.598816543 ERR pvxs.config EPICS_PVA_ADDR_LIST ignoring invalid 'bl01t-ea-fastcs-01' : Error resolving "bl01t-ea-fastcs-01" : nodename nor servname provided, or not known

pvxinfo/get is OK:

$ pip list | grep p4p
p4p 4.2.1
$ export EPICS_PVA_ADDR_LIST="bl01t-mo-sim-01 bl01t-di-cam-01 bl01t-ea-fastcs-01"
$ pvxinfo BL01T-DI-CAM-01:PVA:OUTPUT
BL01T-DI-CAM-01:PVA:OUTPUT from 10.111.7.5:5075
struct "epics:nt/NTNDArray:1.0" {
...

Downgrading to p4p 4.2.0 fixes the issue.

[mdavidsaver]

Downgrading to p4p 4.2.0 fixes the issue.

This error message is coming from PVXS. Which versions of pvxslibs and epicscorelibs are involved?

[mdavidsaver]

The culprit is clearly epics-base/pvxs@b8a4001 . I can't now remember why I made that change. From context it was something to do with IPv6 (stupid IPv6...).

[kasemir]

I assume evutil_getaddrinfo is just a wrapper for getaddrinfo. As an update to gethostbyname, getaddrinfo handles names "hostname", IPv4 notation "127.0.0.1" as well as IPv6 notation "::1".
When using a hostname, I think you won't know if you'll get an IPv4 or IPv6 address. Maybe that's why you wanted to force use of EVUTIL_AI_NUMERICHOST?

[mdavidsaver]

... just ...

By luck, while looking into this issue I found that there is an undocumented, and probably unintentional additional, requirement in the evutil_getaddrinfo() wrapper for the result pointer to be initially NULL. This is probably unrelated to whatever possessed me to start using EVUTIL_AI_NUMERICHOST. I think I just screwed up this time.

... I think you won't know if you'll get an IPv4 or IPv6 address. ...

Or some of both. Currently, while expanding the address list, each hostname will be resolved to one address. As I think about it, it might be better to populate the list with all IPv4/6 addresses for each hostname.

[mdavidsaver]

The culprit is clearly epics-base/pvxs@b8a4001

Reverted by epics-base/pvxs@6828ea0

[gilesknap]

Thanks @mdavidsaver.

I should have mentioned that I'm using epics-base 7.0 branch commit f4e1019ebe40fb0bb32780fbd1b6bcde7512f3dd and pvxs 1.3.2.

It is unclear to me how to test against master as your fix is in pvxs but downgrading the pip install of p4p to 4.2.0 fixed the issue. I'm not sure if p4p is installing its own version of pvxs?

[AlexanderWells-diamond]

By default pip will look at p4p's dependencies and install the latest stable version of pvxslibs. You can force a particular version by doing something like this:

pip install git+https://github.com/epics-base/p4p.git git+https://github.com/epics-base/pvxs.git git+https://github.com/epics-base/epicscorelibs.git

This is what I do in PythonSoftIOC's CI.

[mdavidsaver]

I'm not sure if p4p is installing its own version of pvxs?

... p4p's dependencies and install the latest stable version of pvxslibs ...

To clarify. The p4p python build depends on PVXS in the form of the pvxslibs python module. This makes the wheels self-contained. imo. this is desirable from a just-works prospective, but potentially confusing from a how-does-it-work prospective.