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
<1999>
2000
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
<1999>
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|