EPICS Home

Experimental Physics and Industrial Control System


 
1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Questions regarding CA protocol specification and phylosophy
From: Ralph Lange <[email protected]>
To: Mark Rivers <[email protected]>
Cc: EPICS Tech Talk <[email protected]>
Date: Thu, 14 Sep 2017 20:55:33 +0200
Hi Mark,

That issue exists, correct.   [I was calling my rule a "general" rule, which is the wrong term. I meant "basic" rule. I.e., the kind that allows exceptions.]

But even in that case, I would claim that Channel Access technically works. It returns errors that the PV is seen on multiple servers (which is not allowed in CA), because it can see the PV being served from different IP addresses, but it connects to one of the addresses, and that connection will work without further issues.
If a client is written in a way that it reports error messages by printing them (like the command line utilities), it will print error messages. Clients that ignore errors (or hide them in an iconified window, like some display managers) will work.

However, this is definitely not the way to run a CA system. Of course not.
You have to configure the system so that the client sees the PV on only one interface.

There are basically two ways to do that within Channel Access:
Either the server (IOC) binds only to one of the available networks. (Done on recent versions of Base by setting EPICS_CAS_INTF_ADDR_LIST.) No client configuration needed.
Or the client only uses one network to resolve PV names. (By setting EPICS_CA_AUTO_ADDR=NO and EPICS_CA_ADDR_LIST=<broadcast or individual IP addresses>.) No server (IOC) configuration needed.

Outside of CA, there are a zillion different ways to use firewalls and packet filtering/rewriting software to make the client only see the PVs on one interface.
Key point: the name resolution request package (UDP from client to port 5065) must reach the IOC on only one interface. Everything else won't matter much.

Cheers and sorry for the confusion,
~Ralph



On Thu, Sep 14, 2017 at 6:22 PM, Mark Rivers <[email protected]> wrote:

Hi Ralph,

 

> General rule of thumb:

> Inside a single local network (broadcast domain), Channel Access works without any configuration.

> A single host is an extremely local network, and the rule of thumb is still true.

 

I don't think that statement is true under the following conditions (at least for base 3.14)

 

- The IOC and the client are on the same computer.

- The computer has more than one network interface.

 

In this case the client will report an error that there are multiple IOCs with each PV, because they appear to be found on both network interfaces.  In this case it is necessary to set:

 

EPICS_CA_AUTO_ADDR_LIST=NO

EPICS_CA_ADDR_LIST= [broadcast address of a single network interface that you want to use for channel access]

 

Has this problem been removed in 3.15 or 3.16?

 

Mark

 

 

From: [email protected] [mailto:tech-talk-bounces@aps.anl.gov] On Behalf Of Ralph Lange
Sent: Thursday, September 14, 2017 10:26 AM
To: EPICS Tech Talk
Subject: Re: Questions regarding CA protocol specification and phylosophy

 

Hi Diego,

 

General rule of thumb:

Inside a single local network (broadcast domain), Channel Access works without any configuration.

A single host is an extremely local network, and the rule of thumb is still true.

 

If you have to use CA configuration to get things working in a local network, it most often hints to an error in your network configuration.

 

Please try your setup without configuring IOCs nor clients. It should just work. [TM]

 

Good luck,
~Ralph

 

 

On Thu, Sep 14, 2017 at 3:49 PM, Diego Sanz <[email protected]> wrote:

Dear guys,

Again, thank you for your support. Still the problem persists. The idea of using "lo" interface is for testing purposes, but anyway, now I am using other ip:

#ifconfig command shows:

enp0s3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.2.15  netmask 255.255.255.0  broadcast 10.0.2.255

So, both IOCs will be configured for using this IP. Just below I put the output of the 2 IOCs just after running:

[IOC 1]:
epicsEnvSet("EPICS_CA_ADDR_LIST","10.0.2.15")
## Load record instances
# dbLoadTemplate "db/userHost.substitutions"
dbLoadRecords "db/devsimulation.db", "user=dsanzHost"
## Set this to see messages from mySub
#var mySubDebug 1
## Run this to trace the stages of iocInit
#traceIocInit
cd "/home/dsanz/Developments/edsTemplate-epics/iocBoot/ioctest"
iocInit
Starting iocInit
############################################################################
## EPICS R3.14.12.6
## EPICS Base built Jan 31 2017
############################################################################
iocRun: All initialization complete
## Start any sequence programs
#seq sncExample, "user=dsanzHost"
epics>
......

[IOC2]:

epicsEnvSet("EPICS_CA_ADDR_LIST","10.0.2.15")
## Load record instances
dbLoadTemplate "db/userHost.substitutions"
dbLoadRecords "db/dbSubExample.db", "user=dsanzHost"
## Set this to see messages from mySub
#var mySubDebug 1
## Run this to trace the stages of iocInit
#traceIocInit
cd "/home/dsanz/Developments/checkEpics/iocBoot/iocthis"
iocInit
Starting iocInit
############################################################################
## EPICS R3.14.12.6
## EPICS Base built Jan 31 2017
############################################################################
cas warning: Configured TCP port was unavailable.
cas warning: Using dynamically assigned TCP port 37633,
cas warning: but now two or more servers share the same UDP port.
cas warning: Depending on your IP kernel this server may not be
cas warning: reachable with UDP unicast (a host's IP in EPICS_CA_ADDR_LIST)
iocRun: All initialization complete
## Start any sequence programs
#seq sncExample, "user=dsanzHost"
epics>
.....

regarding the EPICS client, the EPICS_CA_ADDR_LIST is configured with the boradcast address, and then, I try to read one PV from each of the IOCs..:

[dsanz@localhost ~]$ set | grep EPICS_CA_ADDR
EPICS_CA_ADDR_LIST=10.0.2.255
[dsanz@localhost ~]$ caget pcounter
Warning: Duplicate EPICS CA Address list entry "10.0.2.255:5064" discarded
Channel connect timed out: 'pcounter' not found.
[dsanz@localhost ~]$ caget dsanzHost:ai1
Warning: Duplicate EPICS CA Address list entry "10.0.2.255:5064" discarded
Channel connect timed out: 'dsanzHost:ai1' not found.

This configuration, does not let me to read from any IOC. Regarding the Warning mentioned... I suppose is normal due to both IOCs are listening in the Ca-1 UDP port....

If this configuration should work, then I will study the new (for me) version of the CA protocol description http://www.aps.anl.gov/epics/base/R3-16/0-docs/CAproto/index.htm

that Michael mentioned before, to try to understand this issue.

Thank you very much again

Regards

Diego

 

 

 

 

2017-09-13 17:45 GMT+02:00 Michael Davidsaver <[email protected]>:

On 09/13/2017 10:05 AM, Diego Sanz wrote:
> First of all, thanks a lot
>
> Starting for the configuration: the 2 IOCs and the EPICS client is in
> the same Host, no firewall...
> If I understood correctly, every IOC, shall be working in different IPs
> on different subnetworks? e.g.,
>
> IOC1 on 192.168.0.2
>
> IOC2 on 192.168.1.3
>
> and client shall have access to booth IPs....
>
> So then, the configuration as follows is not correct:
>
> all of them working on 127.0.0.1

FYI, by default 127.0.0.1 (aka. the loopback interface) isn't used.  By
this I mean that beacons and searches will not be sent to 127.0.0.1.
However, by default listening sockets are bound to 0.0.0.0 (aka wildcard
interface) which will receive UDP traffic sent to 127.0.0.1.

For this reason you'll sometimes see EPICS_CA_ADDR_LIST=127.0.0.1 given
as a workaround for CA issues when client and IOC are on the same host.
This sends unicast searches to localhost.  As this is unicast, it works
with only one IOC on the host (typical developer scenario).

A linux specific trick EPICS_CA_ADDR_LIST=127.255.255.255 works for many
IOC.  On linux the loopback interface supports broadcasts but doesn't
set the IFF_BROADCAST flag to advertise this fact.


> Is well understood?
>
> Thanks a lot
>
> Diego
>
>
>
> 2017-09-13 16:26 GMT+02:00 Dirk Zimoch <[email protected]
> <mailto:[email protected]>>:

>
>     On 13.09.2017 16:03, Kasemir, Kay wrote:
>
>         The main issue here is not TCP but UDP.
>
>
>     Just for completeness: TCP can be an issue as well if you have a
>     firewall between client and IOC. Even if if you tell the firewall to
>     allow the CA ports for UDP and TCP then the search broadcast may
>     pass, maybe even the reply reaches the client, but you still may not
>     be able to connect to the dynamically assigned TCP port of the
>     second IOC.
>
>     Dirk
>
>

 

 



Replies:
Re: Questions regarding CA protocol specification and phylosophy Ralph Lange
References:
Questions regarding CA protocol specification and phylosophy Diego Sanz
Re: Questions regarding CA protocol specification and phylosophy Kasemir, Kay
Re: Questions regarding CA protocol specification and phylosophy Dirk Zimoch
Re: Questions regarding CA protocol specification and phylosophy Diego Sanz
Re: Questions regarding CA protocol specification and phylosophy Michael Davidsaver
Re: Questions regarding CA protocol specification and phylosophy Diego Sanz
Re: Questions regarding CA protocol specification and phylosophy Ralph Lange
RE: Questions regarding CA protocol specification and phylosophy Mark Rivers

Navigate by Date:
Prev: Re: Questions regarding CA protocol specification and phylosophy Kasemir, Kay
Next: Re: Questions regarding CA protocol specification and phylosophy Ralph Lange
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: Questions regarding CA protocol specification and phylosophy Mark Rivers
Next: Re: Questions regarding CA protocol specification and phylosophy Ralph Lange
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024