EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: [Fwd: Problems with CA in a WAN environment]
From: Geoff Savage <[email protected]>
To: tech-talk <[email protected]>
Date: Tue, 14 Sep 1999 09:43:35 -0500
Hi,

I just resolved a problem where messages from the server did not reach the
client.  In my case the network configuration of the systems did not match.
In particular the netmask and broadcast address needed to be identical for the
IOC and the host.

I tested the connection using ping first.  Then I set EPICS_CA_ADDR_LIST to
the IP address of the IOC.  This worked.  So I used the ifconfig command to
view the network parameters on our Linux and Digital Unix hosts and the ifShow
command on my IOC.  I immediately saw the discrepancy between the netmask and
broadcast addresses.  Now I have to get the system administrators to adjust
the parameters.

Geoff

Jeff Hill wrote:

> Stefan,
>
> It is difficult to determine the cause of your troubles. With the
> information available I do observe that:
>
> 1) CAU client found the PV on the IOC
> 2) IOC server finished its normal PV connect sequence
> 3) IOC server never received a CA get request from the CAU client
> 4) CAU client disconnected (probably because it deleted
>         the channel)
>
> As I recall, the "cau" channel access client side application has a
> short self imposed timeout that it uses when it is waiting for a response
> to its "get" command. This program is probably almost always used on
> a LAN. Perhaps it is timing out before it receives the connect sequence
> response from the server.
>
> To fault isolate you could try the following:
>
> 1) First verify that everything works correctly on the LAN that your
> IOC is connected to.
>
> 2) Recompile "cau" with a longer "ca_pend_io()" timeout. If this solves
> the problem we would be interested in reintegrating your changes into
> the distribution. Alternatively, just try a different CA client which
> is more robust in a WAN environment such as DM/EDD, MEDM, ALH, etc.
> Basically
> any of the clients which allow a channel to reconnect when contact is
> temporarily
> lost with the server will perform well in a WAN environment with long
> propagation delays.
>
> If this does not help then please send additional information such
> as the version of EPICS, and output from the Solaris command
> "snoop between hostXxx IOCyyy". This command will not work well
> unless it is run on a host that is on the same network hub as
> the host that it is watching (network switches will make it more difficult
> to observe network traffic), and you will need to be root. If your host
> is not Solaris then you may find that the similar commands "tcpdump" or
> "etherfind" may be available.
>
> Jeff
>
> >
> > I have a problem with channel access in a WAN environment and would like
> > to ask the experts whether
> > they have an idea on how to trace the problem.
> >
> > I have carefully checked all environment variables and timeouts and my
> > guess is that the messages from
> > the CA server do not reach the CA client (the other direction seems to
> > work).
> >
> > On my CA server box I was setting CASDEBUG to 3.
> > On the client side I was using cau to retrieve an epics record
> > (mpia:tvGuiderY).
> > I tried longer timeouts but without success.
> > Below are the log records.
> >
> > Thanks
> > /Stefan/
> >
> > ========
> > CA client:
> > ========
> > cau> get mpia:tvGuiderY
> >
> > =================
> > CA servers messages:
> > =================
> > 0xce42b4 (CA UDP): CAS: Sending a message of 0 bytes
> > 0xce42b4 (CA UDP): CAS: cast server msg of 32 bytes
> > 0xce42b4 (CA UDP): CAS: from addr 95d928df, port cf26
> > 0xce42b4 (CA UDP): CAS: Parsing 32(decimal) bytes
> > 0xce42b4 (CA UDP): CAS: cmd=6 cid=0 typ=5 cnt=6 psz=16 avail=0
> > 0xce42b4 (CA UDP): CAS:         N=1 paddr=0
> > 0xce42b4 (CA UDP): CAS: Sending a message of 24 bytes
> > 0xce42b4 (CA UDP): CAS: cast server msg of 32 bytes
> > 0xce42b4 (CA UDP): CAS: from addr 95d928df, port cf26
> > 0xce42b4 (CA UDP): CAS: Parsing 32(decimal) bytes
> > 0xce42b4 (CA UDP): CAS: cmd=6 cid=0 typ=5 cnt=6 psz=16 avail=0
> > 0xce42b4 (CA UDP): CAS:         N=1 paddr=0
> > 0xce42b4 (CA UDP): CAS: Sending a message of 24 bytes
> > 0xc486fc (CA client): CAS: Creating new udp client
> > 0xc486fc (CA client): CAS: converting udp client to tcp
> > 0xc486fc (CA client): CAS: Recieved connection request
> > 0xc486fc (CA client): from addr 95d928df, port cd71
> > 0xc486fc (CA client): CAS: Parsing 80(decimal) bytes
> > 0xc486fc (CA client): CAS: cmd=20 cid=0 typ=0 cnt=0 psz=8 avail=0
> > 0xc486fc (CA client): CAS:      N=1 paddr=0
> > 0xc486fc (CA client): CAS: cmd=21 cid=0 typ=0 cnt=0 psz=8 avail=0
> > 0xc486fc (CA client): CAS:      N=2 paddr=0
> > 0xc486fc (CA client): CAS: cmd=18 cid=0 typ=0 cnt=0 psz=16 avail=6
> > 0xc486fc (CA client): CAS:      N=3 paddr=0
> > 0xc486fc (CA client): CAS: Sending a message of 32 bytes
> > 0xc486fc (CA client): CAS: Parsing 16(decimal) bytes
> > 0xc486fc (CA client): CAS: cmd=10 cid=0 typ=0 cnt=0 psz=0 avail=0
> > 0xc486fc (CA client): CAS:      N=1 paddr=0
> > 0xc486fc (CA client): CAS: Sending a message of 16 bytes
> > 0xc486fc (CA client): CAS: nill message disconnect
> > 0xc486fc (CA client): CAS: Connection 5 Terminated
> >
> > ========
> > CA client:
> > ========
> > error on search for mpia:tvGuiderY
> > couldn't open mpia:tvGuiderY
> > CA.Client.Diagnostic..............................................
> >     Message: "Network connection lost"
> >     Severity: "Info" Context: "156.156.156.156"
> > ..................................................................
> >   cau:
> >
> >



Navigate by Date:
Prev: Generic Fieldbus Device Support (GPIB and others) Dirk Zimoch
Next: LeCroy 1458 High voltage mainframe support Coles Sibley
Index: 1994  1995  1996  1997  1998  <19992000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Generic Fieldbus Device Support (GPIB and others) Marty Kraimer
Next: LeCroy 1458 High voltage mainframe support Coles Sibley
Index: 1994  1995  1996  1997  1998  <19992000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·