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 | 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 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: Channel Access not connecting |
From: | Bruce Hill <[email protected]> |
To: | Mark Rivers <[email protected]> |
Cc: | "[email protected]" <[email protected]> |
Date: | Tue, 17 May 2011 13:09:29 -0700 |
Thanks all for the suggestions! I was giving a tour this morning, so I'm just getting back to this problem. I did have 3 soft IOC's running on that host, along with caRepeater. Our common pattern is to use a host script to use procServ to launch caRepeater and each soft IOC. However, I just tried killing all of them and running just one soft IOC, both with and without caRepeater being run explicitly. When I don't run caRepeater, it gets started automatically as a child of my soft IOC after caget tries to connect, so that much at least seems to be working right. Unfortunately, I still get: % caget SXR:RCI:MMS:05 Channel connect timed out: 'SXR:RCI:MMS:05' not found. I was hoping that just running one soft IOC was the key to the casr output: UDP Server: UDP 0.0.0.0:0(): User="", V4.0, 0 Channels, Priority=0 but that didn't change. - Bruce On 05/17/2011 07:38 AM, Mark Rivers wrote: I'm a bit confused here. I run multiple IOCs on my Linux server all the time, without doing anything special with the ports. I do see this message after iocInit() when starting IOCs after the first one: ********************************** cas warning: Configured TCP port was unavailable. cas warning: Using dynamically assigned TCP port 58629, cas warning: but now two or more servers share the same UDP port. cas warning: Depending on your IP kernel this server may not be cas warning: reachable with UDP unicast (a host's IP in EPICS_CA_ADDR_LIST) ********************************** However, channel access clients have no trouble connecting to PVs in any of those IOCs. This is Fedora Core 9. Do more recent Linux kernels have a problem with this? Mark -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Claude Saunders Sent: Tuesday, May 17, 2011 9:02 AM To: [email protected] Subject: Re: Channel Access not connecting Hi Bruce, From your first sentence, I see "IOC's" (plural) and "linux". I recently had what I believe is the same problem, which Andrew Johnson kindly helped me understand. If you are running two iocs on one linux host, using default ports, you wind up with two processes listening on the same udp port. I gather with linux, the network stack will only deliver an incoming (pv search) broadcast UDP packet to one of those processes. If it happens to be the one without the PV you're looking for, then the ca_search fails, even though the other IOC process contains the PV. - Claude On 05/17/2011 12:12 AM, Bruce Hill wrote: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. I suspect it has something to do with how the multiple interfaces on this machine are configured,but so far have been unable to find a solution. # ifconfig eth0 Link encap:Ethernet HWaddr 00:1E:68:79:5C:4E inet addr:134.79.32.161 Bcast:134.79.35.255 Mask:255.255.252.0 inet6 addr: fe80::21e:68ff:fe79:5c4e/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:190759 errors:0 dropped:0 overruns:0 frame:0 TX packets:43567 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:18427912 (17.5 MiB) TX bytes:9772031 (9.3 MiB) Interrupt:19 eth2 Link encap:Ethernet HWaddr 00:1E:68:79:5C:50 inet addr:192.168.254.2 Bcast:192.168.254.255 Mask:255.255.255.0 inet6 addr: fe80::21e:68ff:fe79:5c50/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1238443 errors:0 dropped:0 overruns:0 frame:0 TX packets:879202 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:80539799 (76.8 MiB) TX bytes:64420869 (61.4 MiB) Interrupt:20 Base address:0x4000 Gateway is 134.79.35.1 I'm running with defaults for the EPICS_CA* and EPICS_CAS* envvariables,but have also played with EPICS_CA_ADDR_LIST, EPICS_CA_AUTO_ADDR_LIST, and EPICS_CA_INTF_ADDR_LIST with no success. See attached files for casr, epicsEnvShow, ifconfig, and netstatoutputfor more configuration details. We're running base 3.14.9 everywhere, but this is the only machine showing this problem. The casr output includes: UDP Server: UDP 0.0.0.0:0(): User="", V4.0, 0 Channels, Priority=0 This looks wrong to me, as my working IOC's show a valid UDP addr, butI'm not sure how to fix this, or even if this is the root problem. Any suggestions would be appreciated. Thanks, - Bruce P.S. When I run caget, tcpdump shows: # /usr/sbin/tcpdump -i eth0 -n -nn udp dst portrange 5064-5065 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 21:46:55.934345 IP 192.168.254.2.54260 > 134.79.35.255.5065: UDP, length 16 21:46:57.179960 IP 134.79.32.161.43268 > 134.79.35.255.5064: UDP, length 48 21:46:57.211939 IP 134.79.32.161.43268 > 134.79.35.255.5064: UDP, length 48 21:46:57.275932 IP 134.79.32.161.43268 > 134.79.35.255.5064: UDP, length 48 21:46:57.403935 IP 134.79.32.161.43268 > 134.79.35.255.5064: UDP, length 48 -- Bruce Hill Member Technical Staff SLAC National Accelerator Lab 2575 Sand Hill Road M/S 10 Menlo Park, CA 94025 |