Experimental Physics and
Industrial Control System

Michael Davidsaver via Tech-talk <tech-talk at aps.anl.gov> · Fri, 25 Aug 2023 11:11:56 +0200

On 8/23/23 06:48, Jim Larsson via Tech-talk wrote:

Hello Tech Talk,

We have encountered an issue with pv access when a host running an ioc switch network.

The host is a mini-pc and obtains a new ip from dhcp.

As I understand it, this IOC is being physically moved between subnets.  While I can imagine
why this might be practically useful, this is not a situation which gets much thought or testing
by epics developers.  (it is awkward to test situations like this on a single host)

One of the quirks of the pvAccessCPP server vs. the CA server (RSRV) or PVXS is that it binds
sockets to individual network interface IP addresses.  If these IP addresses change, you would
need to restart the PVA server. As you have found, this can be done without an IOC restart.

You _might_ be able to avoid needing to restart the PVA server by switching to QSRV2 (in PVXS)
as it binds sockets in ways which are more analogous to what the CA server (RSRV) does.

Compare the listening sockets of 'softIocPVA` (QSRV1 / pva2pva)

$ netstat -tulpn|grep 260351

tcp 0 0 0.0.0.0:5064 0.0.0.0:* LISTEN 260351/./bin/linux-

tcp 0 0 0.0.0.0:5075 0.0.0.0:* LISTEN 260351/./bin/linux-

udp 0 0 0.0.0.0:33491 0.0.0.0:* 260351/./bin/linux-

udp 0 0 0.0.0.0:34290 0.0.0.0:* 260351/./bin/linux-

udp 0 0 0.0.0.0:44421 0.0.0.0:* 260351/./bin/linux-

udp 0 0 0.0.0.0:37040 0.0.0.0:* 260351/./bin/linux-

udp 0 0 0.0.0.0:5064 0.0.0.0:* 260351/./bin/linux-

udp 0 0 224.0.0.128:5076 0.0.0.0:* 260351/./bin/linux-

udp 0 0 10.127.127.255:5076 0.0.0.0:* 260351/./bin/linux-

udp 0 0 10.127.127.1:5076 0.0.0.0:* 260351/./bin/linux-

udp 0 0 172.18.121.255:5076 0.0.0.0:* 260351/./bin/linux-

udp 0 0 172.18.120.231:5076 0.0.0.0:* 260351/./bin/linux-

udp 0 0 224.0.0.128:5076 0.0.0.0:* 260351/./bin/linux-

udp 0 0 10.127.127.255:5076 0.0.0.0:* 260351/./bin/linux-

udp 0 0 10.127.127.1:5076 0.0.0.0:* 260351/./bin/linux-

udp 0 0 172.18.121.255:5076 0.0.0.0:* 260351/./bin/linux-

udp 0 0 172.18.120.231:5076 0.0.0.0:* 260351/./bin/linux-

with 'softIocPVX' (QSRV2 / PVXS)

$ netstat -tulpn|grep 260444

tcp 0 0 0.0.0.0:5064 0.0.0.0:* LISTEN 260444/./bin/linux-

tcp6 0 0 :::5075 :::* LISTEN 260444/./bin/linux-

udp 0 0 0.0.0.0:58838 0.0.0.0:* 260444/./bin/linux-

udp 0 0 0.0.0.0:60236 0.0.0.0:* 260444/./bin/linux-

udp 0 0 0.0.0.0:44572 0.0.0.0:* 260444/./bin/linux-

udp 0 0 0.0.0.0:5064 0.0.0.0:* 260444/./bin/linux-

udp 0 0 0.0.0.0:5076 0.0.0.0:* 260444/./bin/linux-

udp6 0 0 :::5076 :::* 260444/./bin/linux-

udp6 0 0 :::38389 :::* 260444/./bin/linux-

shows a shorter list, with none bound to specific IP addresses.

After the switch, the pvs from the ioc are not accessible with pv access, e.g., pvget. However, the pvs can still be obtained with channel access (both before and after switching network).

Some findings after switching network:
  => Pv access works if the ioc is restarted.
  => Pv access works if executing 'stopPVAServer' and 'startPVAServer' in the ioc shell.
  => Pvget locally doesn't work.
  => pvget to an ioc on a different host on the network works.
  => Channel access continuous to work after switching network.

Versions:
pvAccess server v7.1.6
epics-base v7.0.7

# ioc shell
 > pvasr
EPICS_PVAS_INTF_ADDR_LIST = 0.0.0.0:5075
EPICS_PVAS_BEACON_ADDR_LIST =
EPICS_PVAS_AUTO_BEACON_ADDR_LIST = YES
EPICS_PVAS_BEACON_PERIOD = 15
EPICS_PVAS_BROADCAST_PORT = 5076
EPICS_PVAS_SERVER_PORT = 5075
EPICS_PVAS_PROVIDER_NAMES = QSRV local

Has anyone else experienced something similar? Preferably we would like to find a solution so that it is not required to restart the ioc for pv access to work (same as channel access).

Kind regards,
Jim

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System