Re: Understanding EPICS_CA_ADDR_LIST and caget

[Sean Leavey via Tech-talk <tech-talk at aps.anl.gov>]

Hi Mark,

> However, even when you fix the firewall/router problem this method has a 
> significant limitation.  It will only let you reach one of the IOCs 
> started on that server.  If that server has multiple IOCs then you will 
> not be able to reach any except one of them, usually the last one started.

I read about that in the course of debugging my issues. I think in my 
case it will be ok for now since I only plan to run one IOC. I assume I 
can run a single IOC with records from iocStats as well as others (e.g. 
from Modbus)?

> There are several workarounds for this.  If your IT folks allow it you 
> can enable "directed broadcasts" on the router serving the IOC machine.  
> Then your client can set EPICS_CA_ADDR_LIST to the broadcast address of 
> the IOC subnet.  You will be able to reach all IOCs on any machines on 
> that subnet. >
> If your IT folks won't agree to that then there is an iptables 
> configuration you can use.
> https://epics-controls.org/resources-and-support/documents/howto-documents/channel-access-reach-multiple-soft-iocs-linux/ 
> <https://epics-controls.org/resources-and-support/documents/howto-documents/channel-access-reach-multiple-soft-iocs-linux/>

I haven't yet asked my IT dept about their routers. If I stick to one 
IOC, it sounds like asking them to open ports 5064 and 5065 might be all 
that's needed. But perhaps it's going to be easier long term to just set 
up our own network in the lab where I want to use EPICS and use a 
gateway to connect to the main network... it looks like most EPICS users 
do it this way?

Thanks for your continuing help!
Sean

> Mark
>
>
> ------------------------------------------------------------------------
> *From:* Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Sean 
> Leavey via Tech-talk <tech-talk at aps.anl.gov>
> *Sent:* Thursday, September 8, 2022 7:52 AM
> *To:* tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
> *Subject:* Re: Understanding EPICS_CA_ADDR_LIST and caget
> Hi Jörn and Jure,
>
> Thanks a lot for your input - it's helped me understand what the problem
> is. As you guessed, the reason I was looking into this was because caget
> was not managing to talk to my IOC, and it looks from the commands you
> pointed me to that some router/firewall is indeed trapping the connection.
>
> Cheers,
> Sean
>
> On 08/09/2022 10:40, Jörn Dreyer via Tech-talk wrote:
> > Hi Sean,
> >
> > some more suggestions on the network issue. Normally between two subnets there
> > is a firewall setup that blocks all traffic besides some ports and all
> > broadcasts. To figure out if you can reach the IOC you could use nmap like
> > this:
> >
> > nmap -p 5064  195.194.120.115
> >
> > If that does not find the port to be in open state, you will either need to ask
> > your IT to open that port on the firewall, or set up an EPICS gateway on a PC
> > that has two NICs into the two subnets.
> > Issue the nmap command on both machines. At least on the machine running the
> > IOC the port should be reported to be open.
> > This would be my first tests in such a case.
> >
> > Regards
> >
> > Jörn
> >
> > Am Donnerstag, 8. September 2022, 11:23:37 CEST schrieb Jure Varlec via Tech-
> > talk:
> > > Hello Sean,
> > >
> > > As long as you have EPICS_CA_AUTO_ADDR_LIST set to YES, broadcast searches
> > > will be done in addition to what you have specified in EPICS_CA_ADDR_LIST.
> > > In other words, both broadcast searches to broadcast-capable interfaces and
> > > unicast searches to explicitly listed addresses will happen. More
> > > information on how this works is available in the CA Reference Manual,
> > > which is linked at the bottom of the page that you referenced in your
> > > message. And also below 🙂
> >   
> > > https://epics.anl.gov/base/R3-14/12-docs/CAref.html#EPICS 
> <https://epics.anl.gov/base/R3-14/12-docs/CAref.html#EPICS>
> > > This explains why you still see broadcast searches done on your first
> > > interface. You should also see broadcasts on the other interfaces, and
> > > unicast searches as well. But you do not, because tcpdump will only listen
> > > on the first interface by default. You should tell it to listen on any
> > > interface, it will give you a wider picture of what's going on.
> >   
> > > Best,
> > > Jure
> > > ________________________________
> > > From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Sean Leavey via
> > > Tech-talk <tech-talk at aps.anl.gov>
> >    Sent: Thursday, September 8, 2022 10:20
> > > To: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
> > > Subject: Understanding EPICS_CA_ADDR_LIST and caget
> > >
> > > Caution: This email originated from outside of Cosylab.
> > >
> > >
> > > Hi tech talkers,
> > >
> > > I don't seem to be able to change the behaviour of caget using
> > > EPICS_CA_ADDR_LIST. I'm probably misunderstanding something.
> > >
> > > I've got EPICS Base installed on my machine. In one terminal I've got
> > > tcpdump monitoring port 5064. In another terminal I run caget with a
> > > made-up channel. Here's their output after I run caget:
> > >
> > > $ caget FAKE:CHANNEL
> > > Channel connect timed out: 'FAKE:FAKE' not found.
> > >
> > > $ tcpdump port 5064
> > > tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
> > > listening on wlan0, link-type EN10MB (Ethernet), snapshot length 262144
> > > bytes
> > > 09:11:07.345310 IP totoro.41026 > 172.16.15.255.ca-1: UDP, length 48
> > > 09:11:07.377158 IP totoro.41026 > 172.16.15.255.ca-1: UDP, length 48
> > > 09:11:07.441438 IP totoro.41026 > 172.16.15.255.ca-1: UDP, length 48
> > > 09:11:07.569269 IP totoro.41026 > 172.16.15.255.ca-1: UDP, length 48
> > > 09:11:07.825253 IP totoro.41026 > 172.16.15.255.ca-1: UDP, length 48
> > >
> > > So far, so good? Looks like caget is sending 5 broadcast packets then
> > > giving up. 172.16.15.255 is my link's broadcast address, verified with
> > > `ip addr`.
> > >
> > > But what if I know the IP of the IOC that hosts a channel, and want to
> > > specify it directly? I read in [1]:
> > >
> > >
> > >    > To reach IOCs on one or more additional subnets, the environment
> > >
> > > variable EPICS_CA_ADDR_LIST needs to be configured. It can list either
> > > the specific IP addresses of each IOC, or the broadcast address of their
> > > subnet. Note, however, that routers will often not forward broadcast
> > > requests, which suggests using specific IP addresses.
> > >
> > > This sounds useful to me because my IOC is in a different subnet. From
> > > the quoted text above, I understand that, by setting EPICS_CA_ADDR_LIST
> > > to the IP of my IOC, caget should talk directly to it. But apparently
> > > this is not the case. Keeping tcpdump open, and running the caget
> > > command again but this time with the address of my IOC set in
> > > EPICS_CA_ADDR_LIST, I get the same output:
> > >
> > > $ EPICS_CA_ADDR_LIST=195.194.120.115 caget FAKE:FAKE
> > > Channel connect timed out: 'FAKE:FAKE' not found.
> > >
> > > $ tcpdump port 5064
> > > [...]
> > > 09:14:18.995465 IP totoro.35942 > 172.16.15.255.ca-1: UDP, length 48
> > > 09:14:19.027341 IP totoro.35942 > 172.16.15.255.ca-1: UDP, length 48
> > > 09:14:19.091486 IP totoro.35942 > 172.16.15.255.ca-1: UDP, length 48
> > > 09:14:19.219462 IP totoro.35942 > 172.16.15.255.ca-1: UDP, length 48
> > > 09:14:19.475597 IP totoro.35942 > 172.16.15.255.ca-1: UDP, length 48
> > >
> > > Clearly I'm misunderstanding how all of this works. Can someone shed
> > > some light on what EPICS_CA_ADDR_LIST does in the context of caget, if
> > > anything?
> > >
> > > Cheers,
> > > Sean
> > >
> > > [1]
> > > https://epics-controls.org/resources-and-support/documents/howto-documents/c 
> <https://epics-controls.org/resources-and-support/documents/howto-documents/c>
> > > onfigure-channel-access/#IOCs_on_different_subnets
> >   
> > > This email and any attachments are intended solely for the use of the named
> > > recipients. If you are not the intended recipient you must not use,
> > > disclose, copy or distribute this email or any of its attachments and
> > > should notify the sender immediately and delete this email from your
> > > system. UK Research and Innovation (UKRI) has taken every reasonable
> > > precaution to minimise risk of this email or any attachments containing
> > > viruses or malware but the recipient should carry out its own virus and
> > > malware checks before opening the attachments. UKRI does not accept any
> > > liability for any losses or damages which the recipient may sustain due to
> > > presence of any viruses.
>
> This email and any attachments are intended solely for the use of the 
> named recipients. If you are not the intended recipient you must not 
> use, disclose, copy or distribute this email or any of its attachments 
> and should notify the sender immediately and delete this email from your 
> system. UK Research and Innovation (UKRI) has taken every reasonable 
> precaution to minimise risk of this email or any attachments containing 
> viruses or malware but the recipient should carry out its own virus and 
> malware checks before opening the attachments. UKRI does not accept any 
> liability for any losses or damages which the recipient may sustain due 
> to presence of any viruses.

This email and any attachments are intended solely for the use of the named recipients. If you are not the intended recipient you must not use, disclose, copy or distribute this email or any of its attachments and should notify the sender immediately and delete this email from your system. UK Research and Innovation (UKRI) has taken every reasonable precaution to minimise risk of this email or any attachments containing viruses or malware but the recipient should carry out its own virus and malware checks before opening the attachments. UKRI does not accept any liability for any losses or damages which the recipient may sustain due to presence of any viruses.