Experimental Physics and Industrial Control System
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* 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.
>
> See attached files for casr, epicsEnvShow, ifconfig, and netstat
output
> for 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, but
> I'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
>
--
----------------------------------------------------------
Claude Saunders<[email protected]>
Software Services Group Leader
Advanced Photon Source, Argonne National Laboratory
Argonne, IL 60439 630 - 252 - 6619
----------------------------------------------------------
We write suggestions, suggesting fading to silence
And that must please you
My mirror's tarnished with 'no help'
- Gary Numan
----------------------------------------------------------
- Replies:
- Re: Channel Access not connecting Claude Saunders
- Re: Channel Access not connecting Bruce Hill
- References:
- Channel Access not connecting Bruce Hill
- Re: Channel Access not connecting Claude Saunders
- Navigate by Date:
- Prev:
Re: Channel Access not connecting Claude Saunders
- Next:
Re: Channel Access not connecting Claude Saunders
- 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: Channel Access not connecting Claude Saunders
- Next:
Re: Channel Access not connecting Claude Saunders
- 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