Re: Help in debugging ACF connection issue

[Érico Nogueira Rolim via Tech-talk <tech-talk at aps.anl.gov>]

Hi, everyone!

Thank you very much, Yong and Stephen, for the relevant pointers.

I was able to use network-online.target to make sure the IOCs were only launched after network interfaces had been properly setup, and the CA connections can now be established successfully after every reboot. It took some trial and error, because these were Debian servers, where the default for headless setups is ifupdown, which doesn't provide a proper 'wait-online' implementation [1]. In the end, I switched to systemd-networkd, which has been performing well.

systemd also provides online docs about "waiting for network" [2], where, despite documenting the necessary unit setup, they also mention that modern software "should be able to handle dynamic configuration changes". I believe on Linux, for example, that would be possible by using netlink to listen for network interface changes.

While it might be too much work to implement this for libCA, does PVXS support dynamic discovery of network interfaces?

[1] https:// bugs-devel.debian.org/cgi-bin/bugreport.cgi?bug=943934

[2] https:// systemd.io/NETWORK_ONLINE/

Cheers,

Érico

On 3/9/26 13:01, Stephen Dann - STFC UKRI wrote:

You don't often get email from stephen.dann at stfc.ac.uk. Learn why this is important

Hi Érico,

 

Try “After=network-online.target” and “Wants=network-online.target” instead. That’s what I’ve used in the past. “After=network.target” doesn’t do much, according to the docs (man systemd.special).

 

Regards,

Stephen

 

From: Tech-talk <tech-talk-bounces at aps.anl.gov> On Behalf Of Érico Nogueira Rolim via Tech-talk
Sent: 09 March 2026 14:54
To: Hu, Yong <yhu at bnl.gov>
Cc: EPICS Tech Talk <tech-talk at aps.anl.gov>
Subject: Re: Help in debugging ACF connection issue

 

Hi Yong!

 

Thank you very much for the thorough investigation of our issue, and even managing to reproduce it! I greatly appreciate it.

 

We are indeed using systemd, so I will try to use the After=network.target directive first. I hope to be able to test this tomorrow, so I will let you know about the results then.

 

Cheers,

Érico

 

PS: I noticed that the systemd-softioc repository has been archived. Are you using something else now?

 

On 3/6/26 20:02, Hu, Yong wrote:

You don't often get email from yhu at bnl.gov. Learn why this is important

Hi Michael,

 

I did the whole test again after adding a CA link to "myCommand:just4TestACF" in my first softIOC. Both dbCa and asCa cannot connect if my network is turned off at the beginning. 

 

You mentioned that EPICS_CA_AUTO_ADDR_LIST (and EPICS_CA_ADDR_LIST) is evaluated once at startup. That is a very point. So, I did one more test by setting EPICS_CA_ADDR_LIST to a broadcast IP, i.e. 192.168.12.255 (EPICS_CA_AUTO_ADDR_LIST seems Okay with either YES or NO)

$ softIoc -d test.db -a default.acf

asSetFilename: Warning - relative paths won't usually work

Starting iocInit

############################################################################

## EPICS R7.0.5

## Rev. 2021-05-13T07:10-0400

############################################################################

CAC: error = "Network is unreachable" sending UDP msg to 192.168.12.255:5064

Warning: RSRV has empty beacon address list

iocRun: All initialization complete

...

epics> epicsParamShow

EPICS_CA_ADDR_LIST: 192.168.12.255

EPICS_CA_CONN_TMO: 30.0

EPICS_CA_AUTO_ADDR_LIST: YES

 

 

Now, both dbCa and asCa automatically connect once my network is turned on.

epics> ascar

1 channels 0 not connected

 

epics> dbcar

CA links in all records

Total 4 CA links; 4 connected, 0 not connected.

    0 can't read, 0 can't write.  (0 disconnects, 0 writes prohibited)

 

epics> casr 1

Channel Access Server V4.13

1 client connected:

    TCP client at 192.168.12.44:61165 'wps-168932.lan':

      User 'yonghu', V4.13, Priority = 0, 1 Channel

CAS-TCP server on 0.0.0.0:5064 with

    CAS-UDP name server on 0.0.0.0:5064

Sending CAS-beacons to 0 addresses:

 

 

Érico, you have two ways to fix the ACF connection issue: add EPICS_CA_ADDR_LIST to your IOC's environment variable; OR make sure your network is ready before your IOCs start up.

 

Cheers,

Yong

 

From: Michael Davidsaver <mdavidsaver at gmail.com>
Date: Friday, March 6, 2026 at 4:51 PM

 

Hi Yong,

 

 

On 3/6/26 2:59 PM, Hu, Yong wrote:

...

3.  Manually start the first softIOC 'bpm-fron':  it has an ACF which reads a PV (myCommand:just4TestACF) that is provided by the second softIOC 'bpm-rear' .

Could you also add a record with a CA link to "myCommand:just4TestACF"?

I would be interested to know if you have a situation where dbCa can connect, but asCa can not.

also, with https ://github.com/mdavidsaver/cashark the "tshark" CLI can give more meaningful output than "tcpdump".

...

 

Conclusion: just as I mentioned below, most likely your IOCs start before your server's network is fully functional (valid IP address). 

 

To CA developers: Is this a feature or a bug in the Access security Channel Access (asCa)?

This may be related to the behavior of EPICS_CA_AUTO_ADDR_LIST=YES, which is evaluated once at startup using the list of interfaces configured at that time.

 

 

 

Aviso Legal: Esta mensagem e seus anexos podem conter informações confidenciais e/ou de uso restrito. Observe atentamente seu conteúdo e considere eventual consulta ao remetente antes de copiá-la, divulgá-la ou distribuí-la. Se você recebeu esta mensagem por engano, por favor avise o remetente e apague-a imediatamente.

Disclaimer: This email and its attachments may contain confidential and/or privileged information. Observe its content carefully and consider possible querying to the sender before copying, disclosing or distributing it. If you have received this email by mistake, please notify the sender and delete it immediately.