Experimental Physics and
Industrial Control System

Dirk Zimoch via Tech-talk <[email protected]> · Tue, 9 Apr 2019 17:18:01 +0200

I had not thought of the multiple IOC problem. In this case it is a

Fedora Linux VME IOC. Unlikely to run multiple IOCs but not impossible.

I tried it and naively accessing records on IOC 2 does not work when the

firewall is up. I get 'CAC: Unable to connect because "No route to

host"' on the client (caget) even when using the broadcast address.

The iptables solution described on

https://wiki-ext.aps.anl.gov/epics/index.php does not even apply in this

case because I did not use unicast.

The firewall would need to allow the dynamically assigned TCP port of

the second IOC. Unfortunately the second IOC only prints the port on the

screen but it is not available e.g. in an environment variable. If so

this would allow to execute a program (e.g. iptables or firewall-cmd) to

open the port. (Closing it when the IOC dies unexpectedly is far more

difficult. One would have to monitor the process externally.)

There is nothing built into firewalld to work on executables instead of

port numbers (i.e. allow all ports opened by softIoc), is it?

Another solution would be to run a channel access gateway on the host as

the one and only access point from the outside world (using port 5064)

and broadcast on localhost to the IOCs. I am not sure about the

performance implications though.

I think I rather disable the firewall for the time being.

Thanks for your replies.
Dirk

On 08.04.19 17:28, Benjamin Franksen via Tech-talk wrote:

Am 05.04.19 um 14:28 schrieb Dirk Zimoch via Tech-talk:

I Installed it (without ca-2/tcp) and it work fine.

We found that such firewall rules do not work well in combination with
multiple soft IOCs on Linux. The problem is that for multiple CA servers
on the same machine to work as expected, it is necessary to add certain
iptables rules (see
https://wiki-ext.aps.anl.gov/epics/index.php/How_to_Make_Channel_Access_Reach_Multiple_Soft_IOCs_on_a_Linux_Host)
that convert incoming UDP unicasts (name resolution requests) to
broadcasts, internally. Unicasts will be sent when the client sets
EPICS_CA_ADDR_LIST to request a specific server.

The iptables solution is quite elegant but has an unfortunate
side-effect: the source port of the response packets will be re-written
to some randomly chosen ephemeral port. And that port doesn't match the
ports configured for the firewall, so the firewall doesn't let them
through. It is hard to find documentation for this behavior of iptables
on the internet. The keyword here is "implicit source port mapping".

We have been thinking about this problem for a while. I think the only
clean solution is for EPICS to offer something similar to the already
existing caRepeater, only for the server side. Let me call this thing
the "casRepeater". Similar to the CA client with the caRepeater, each CA
server would on startup try to locate a running instance of the
casRepeater, or else start a new one, then register with it. The task of
the casRepeater is to listen on port 5065 for unicasts and then forward
them to all registered CA servers.

Cheers
Ben

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System