Thanks Ralph for the explanations, some follow up below:
Then if I also have the cagateway setup for EPICS_CA_ADDR_LIST=localhost also shouldn’t the client for the gateway also end up using the firewall iptables rule? Cant seem to
figure out why the client side of the gateway doesn’t seem to use iptables rule then.
The firewall rule is server-side and only needed on hosts that run multiple servers (IOCs or Gateways). Nowhere else.
If your gateway machine is running a single Gateway instance per network interface the Gateway binds to, it does not need to run the firewall rule.
Yes but for this situation I am running phoebus client (or caget) on the same machine as the IOCs (and gateway). If the gateway is binding to say my local ethernet ip 192.168.0.50 and I have phoebus send out its requests to 192.168.0.50
(instead of putting localhost) does the routing go through that interface and trigger the firewall rule or does it just route locally through the loopback and not trigger the rule?
I would suggest adding the broadcast address of the loopback interface (usually 127.255.255.255)
Try that instead of 127.0.0.1 when configuring the local clients.
What is the difference then between EPICS_CA_ADDR_LIST=192.168.0.255, EPICS_CA_SERVER_PORT=5064 and using the iptables rule of routing all 5064 udp traffic to
192.168.0.255:5064 instead of say localhost:5064?
These two things are not directly related as they are happening on two different machines.
Your environment settings are for a CA client running on the client host, where the firewall rule does not run.
The firewall rule is running on the server (IOC) host and affecting incoming name resolution requests.
Also note that the firewall rule trick does not work for CA clients on the same host as the multiple IOCs.
In my case I am running the CA Client and Gateway on the same machine for now in development (future iterations will separate these out). I think this is similar to what you mentioned above but I would assume if EPICS_CA_AUTO_ADDR_LIST=NO
and EPICS_CA_ADDR_LIST=192.168.0.50 then this still would not trigger the firewall rule if they were running on the same PC?
I am sure you have specific requirements for your setup.
Otherwise, running multiple IOCs, a CA Gateway and the clients on a single host does not make a lot of sense.
What I have done to simulate a distributed setup on a single machine (if that is what you want to do):
- Run the IOCs on loopback, i.e. have them all bind their servers only to the loopback interface (i.e. localhost or 127.0.0.1). Configure their client side to use ADDR_LIST=127.255.255.255 and AUTO_ADDR_LIST=NO to allow cross-IOC connections.
- Run the CA Gateway between loopback (client side of the Gateway) and the regular interface. (Configure the Gateway to use ADDR_LIST=127.255.255.255 and AUTO_ADDR_LIST=NO on its client end and use the regular network IP for the server end.)
- Run your clients without any special configuration (to make them go through the Gateway) or with the same client configuration as the IOCs and the Gateway (to connect to the IOCs directly).
I did have another related question that I am running into with the broadcasts. If I have multiple PCs running IOCs with the same named records, is the best way to stop the broadcasts from going out to another hosts IOCs to use the
IOC access file?
No. Access security will still show the PV as existing; it just limits the access rights.
One of the basic principles of Channel Access: As everything relies on the channel names, these names must be unique.
DO NOT RUN MULTIPLE IOCS WITH THE SAME RECORDS. It is a recipe for trouble.
If you have to do it and you understand what you're doing, separate the name domains by running the appropriate sets of IOCs on different SERVER_PORT numbers. This will make the IOC sets invisible to each other and require the client to be properly configured to connect to the right set.
Cheers,
~Ralph