Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019 
<== Date ==> <== Thread ==>

Subject: Re: Channel Access not connecting
From: Bruce Hill <bhill@slac.stanford.edu>
To: Jeff Hill <johill@lanl.gov>, Mark Rivers <rivers@cars.uchicago.edu>
Cc: "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Date: Wed, 18 May 2011 01:02:18 -0700
Turns out Mark's suggestion of a firewall problem was right on.

Using -v with iptables revealed:
# /sbin/iptables -v -L INPUT
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination        
5943K 2524M ACCEPT     all  --  any    any     anywhere             anywhere            state RELATED,ESTABLISHED
  694 56906 ACCEPT     icmp --  any    any     anywhere             anywhere           
21212 1082K ACCEPT     all  --  lo     any     anywhere             anywhere           
  178 10020 ACCEPT     tcp  --  any    any     anywhere             anywhere            state NEW tcp dpt:ssh
   40  1988 ACCEPT     tcp  --  any    any     anywhere             anywhere            state NEW tcp dpt:mysql
 559K   79M REJECT     all  --  any    any     anywhere             anywhere            reject-with icmp-host-prohibited


Looks like whoever setup this firewall only allowed NEW tcp packets
for the ssh and mysql destination ports only.    However, they allow
any packets from the lo interface, so the quick workaround was to set:
EPICS_CA_AUTO_ADDR_LIST=NO
EPICS_CA_ADDR_LIST=127.0.0.1

This wouldn't work if we needed to see PV's on other computers,
but in this particular case it meets the need while waiting for
answers from whoever setup this firewall.

Thanks all!
- Bruce



On 5/17/2011 4:24 PM, Jeff Hill wrote:
>> The IOC's server is not yet impacted by the 
>> EPICS_CA_INTF_ADDR_LIST configuration.
> 

> How about the caget client?

The EPICS_CA_INTF_ADDR_LIST is only used to configure  servers.

 

>Here's netstat -nr output:

 

Looks ok. Connecting on the same host requires that an interface sees the loopback of its broadcast, but that always seems to work.

 

So perhaps it _is_ a firewall issue.

 

BTW: We see the opposite issue here. When caget runs on the same host as the soft IOC we see the message about the same PV name on multiple servers because of the soft interface for virtualized OS  that is typically installed in the new Linux versions (named typically virbr0 in the our systems). I could possibly cause this virbr0 to be left out of the autoconfiguration if I discriminate against the hardware address?

 

Jeff
______________________________________________________
Jeffrey O. Hill           Email       
johill@lanl.gov
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107

 

Message content: TSPA

 

With sufficient thrust, pigs fly just fine. However, this is

not necessarily a good idea. It is hard to be sure where they

are going to land, and it could be dangerous sitting under them

as they fly overhead. -- RFC 1925

 

From: Bruce Hill [mailto:bhill@slac.stanford.edu]
Sent: Tuesday, May 17, 2011 2:55 PM
To: Jeff Hill
Cc: 'Claude Saunders'; 'Mark Rivers'; tech-talk@aps.anl.gov
Subject: Re: Channel Access not connecting

 

On 05/17/2011 08:47 AM, Jeff Hill wrote:

oops, yes I said that backwards, its typically broadcasts that are received
by all servers (on the same host), and unicasts that are received by only by
one of multiple servers (on the same host).
  
I'm running with defaults for the EPICS_CA* and EPICS_CAS* env
variables, but have also played with EPICS_CA_ADDR_LIST,
EPICS_CA_AUTO_ADDR_LIST, and EPICS_CA_INTF_ADDR_LIST with no success.
    
The IOC's server is not yet impacted by the EPICS_CA_INTF_ADDR_LIST
configuration.
  

How about the caget client?

I've been having trouble with one linux machine where my IOC's
appear to be running correctly, dbgf works from iocsh, but caget
from another window on the same machine fails to connect.
    
Sounds like a routing level issue. The output from "netstat -r" might be
interesting.
 
Jeff

Here's netstat -nr output:
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
192.168.254.0   0.0.0.0         255.255.255.0   U         0 0          0 eth2
134.79.32.0     0.0.0.0         255.255.252.0   U         0 0          0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eth2
0.0.0.0         134.79.35.1     0.0.0.0         UG        0 0          0 eth0

Mark suggested a firewall issue.   I'm looking into that now.   This
isn't our normal deployment system.   It's for an experimental chamber that's
currently in a different building at SLAC that wanted to run the same EPICS
motor control as they do when their chamber is installed in the hutch.   That
machine is visible from the internet, and I don't administer it, so I'll need
to find the sysadmin for this machine before making any changes.

This system, kernel 2.6.26.3-29.fc9.x86_64, does have a package called system-config-firewall
installed that says the firewall is enabled.   iptables shows:
# /sbin/iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination        
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED
ACCEPT     icmp --  anywhere             anywhere           
ACCEPT     all  --  anywhere             anywhere           
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:ssh
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:mysql
REJECT     all  --  anywhere             anywhere            reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination        
REJECT     all  --  anywhere             anywhere            reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination        


Thanks,
- Bruce


References:
Channel Access not connecting Bruce Hill
Re: Channel Access not connecting Claude Saunders
RE: Channel Access not connecting Mark Rivers
Re: Channel Access not connecting Claude Saunders
RE: Channel Access not connecting Jeff Hill
Re: Channel Access not connecting Bruce Hill
RE: Channel Access not connecting Jeff Hill

Navigate by Date:
Prev: Re: Channel Access not connecting Stephen Lewis
Next: caGateway crashes / use of *MustSucceed functions Dirk Zimoch
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019 
Navigate by Thread:
Prev: Re: Channel Access not connecting Stephen Lewis
Next: Re: Channel Access not connecting Bruce Hill
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·