Experimental Physics and
Industrial Control System

"Garrett D. Rinehart" <rinehart> · Thu, 5 Dec 2002 15:23:01 -0600 (CST)

I'm forwarding the summary of this problem to tech-talk so it gets in the 
archive (just in case anyone else comes across this "feature").

-- GR

------------- Begin Forwarded Message -------------

Subject: RE: Channel Access/Linux/R3.13.7
To: "'Garrett D. Rinehart'" <[email protected]>, [email protected], 
[email protected]
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-transfer-encoding: quoted-printable
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal

That's correct, the R3.13 ca client library attempts to translate the
server's IP address to a host name just after it connects to a new
server so that client side tools can call ca_host_name(). The function
that performs this translation may temporarily block the client side
tool depending on the type of host name lookup that is installed. 

On our last major project here we decided to implement a dedicated DNS
server for the control system to reduce these vulnerabilities.

In R3.14 the CA client library host name translation is completed in a
decicated auxiliary thread so that the main threads never block for IP
to host name translation to complete.

Jeff

> -----Original Message-----
> From: Garrett D. Rinehart [mailto:[email protected]]
> Sent: Tuesday, December 03, 2002 9:13 AM
> To: [email protected]; [email protected]; [email protected];
> [email protected]
> Cc: [email protected]
> Subject: RE: Channel Access/Linux/R3.13.7
> 
> Okay, I have an answer, but I'm going to give it to you in the
> form of a
> question: "huh?"
> 
> Just kidding. Here's the real question: How does CA work such
> that it needs a
> host table defined and can only communicate with iocs listed
> there?
> 
> Yes, that's right, John threw together a host table (/etc/hosts)
> and CA
> immediately started working. Silly me, I was trying to get
> everything working
> before I bothered with the trivial stuff like the convenience
> of using names
> instead of numbers. Little did I know CA needed that. Will
> someone please
> explain to me why it does?
> 
> Thank you all very much for your help. I'm sorry to have
> bothered you with what
> turned out to be such a trivial solution. (Of course, in my own
> defense, no one
> on tech-talk mentioned the host table either.)
> 
> -- GR
> 
> > Subject: RE: Channel Access/Linux/R3.13.7
> > To: [email protected], [email protected], [email protected]
> > Cc: [email protected]
> > MIME-version: 1.0
> > Content-MD5: QAJCB4UPFSqWqzzr17TD8Q==
> >
> > Jeff, Janet, John,
> >
> > Jeff's comment about things being ironed out at complie time
> got us thinking
> > maybe ca needed to be built on a machine exactly like it
> would run on. So,
> > yesterday afternoon, I began building all of 3.13.7 on my
> Linux box using the
> > distribution John got from the APS CVS (I believe). After the
> usual issues of
> > finding/installing junk that wasn't on that machine (like gcc
> and g++ for
> > starters), it went along merrily for a long time. I see this
> morning that it
> > finally crashed and burned (again) on some Java stuff. I
> don't know if it
> failed
> > to get some ca-critical thing rebuilt or not. I can say for
> sure that caget
> and
> > caput have new dates/times and neither of them work. I have
> also tried setting
> > EPICS_CA_ADDR_LIST as John does on his version, but the
> results are the same.
> >
> > As for Janet's question about excas, I played with that some
> this morning and
> > everything there seems to work. I've never used ca_test, so I
> don't know if
> the
> > large quantity of info it's spewing is normal or not, but I
> don't see anything
> > that looks like errors. I also get normal responses to cagets
> to fred, jane,
> et
> > al. Does that tell you anything?
> >
> > -- GR
> >
> > > > I just finished rebuilding the R3.13 cvs branch latest on
> two versions
> > > > of red hat Linux, and the resulting R3.13 ca client
> binaries connected
> > > > to the R3.14 example ca server w/o incident using ca_test.
> The
> > > > EPICS_CA_ADDR_LIST environment variable was empty during
> the tests. I
> > > > built and tested on RH 7.0 and RH 8.0.
> > > >
> > > > There are features in the CA client library that
> introspect the local
> > > > host's network interfaces, and then automatically
> configure the CA
> > > > client's search address list. The OS interfaces that are
> involved have
> > > > changed in recent versions of UNIX; however based on my
> tests this
> > > > morning we appear to have ironed out these issues on
> Linux at compile
> > > > time.
> > > >
> > > > Nevertheless, comparing the R3.13 sources with R3.14 I do
> see some
> > > > important differences as follows:
> > > >
> > > > R3.14/epics/base/src/libCom/osi/os/Linux/osdSock.h(88):
> > > > 	#define ifreq_size(pifreq) (sizeof(pifreq->ifr_name))
> > > >
> > > > R3.13/epics/base/src/include/os/Linux/osiSock.h(80):
> > > > 	#define ifreq_size(pifreq) sizeof(*pifreq)
> > > >
> > > > Jeff
> > > >
> > > > > -----Original Message-----
> > > > > From: Garrett D. Rinehart [mailto:[email protected]]
> > > > > Sent: Monday, December 02, 2002 9:19 AM
> > > > > To: [email protected]
> > > > > Subject: Re: Channel Access/Linux/R3.13.7
> > > > >
> > > > > I get no channel access at all. I'm running John's
> build on a
> > > > > RedHat 7.3 box.
> > > > > Network functions seem normal (ping, telnet, ssh, etc
> all work).
> > > > > I've checked
> > > > > that the CA ports 5064 and 5065 are not blocked. My
> linux box
> > > > > and iocs are all
> > > > > on a private network with no routers between them. Even
> setting
> > > > > "EPICS_CA_ADDR_LIST" as John mentions does nothing.
> Medm
> > > > > screens stay white.
> > > > > Tcl/tk scripts cannot connect to channels. Caget/caput
> commands
> > > > > eventually time
> > > > > out. I get no errors other than "invalid channel name"
> > > > > responses from
> > > > > caget/caput.
> > > > >
> > > > > I don't even have any more ideas what to look for. If
> anyone
> > > > > has any ideas at
> > > > > all, please let me know.
> > > > >
> > > > > Thanks.
> > > > >
> > > > > Garrett Rinehart
> > > > > Control and Data Acquisition System Manager
> > > > > Accelerator Operations Group
> > > > > Intense Pulsed Neutron Source
> > > > > Argonne National Laboratory
> > > > > 9700 S. Cass Ave
> > > > > Argonne, IL  60439
> > > > > (630)252-6561
> > > > >
> > > > >
> > > > > > Subject: Channel Access/Linux/R3.13.7
> > > > > > To: 'EPICS Tech-Talk' <[email protected]>
> > > > > > MIME-version: 1.0
> > > > > > List-Help: <http://www.aps.anl.gov/epics/mail.php>
> > > > > >
> > > > > > We are in the process of upgrading from EPICS 3.13.5
> and
> > > > > R3.13.7.
> > > > > > Everything works fine on solaris but on Linux I do
> not get
> > > > > any channel
> > > > > > communication from IOCs unless I specify
> EPICS_CA_ADDR_LIST.
> > > > > This did work
> > > > > > on R3.13.5 without this specification.  My 3.13.5
> > > > > distribution came from a
> > > > > > tar.gz file from APS.  My 3.13.7 came directly from
> APS CVS.
> > > > > Is there a
> > > > > > difference in settings in config files that can cause
> this.
> > > > > >
> > > > > > John Hammonds
> > > >
> > > >
> > > >
> >

------------- End Forwarded Message -------------

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System