RE: Channel Access not connecting

["Jeff Hill" <johill@lanl.gov>]

>> 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