EPICS Controls 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  2020  2021  2022  2023  2024  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  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Channel Access not connecting
From: Claude Saunders <[email protected]>
To: Mark Rivers <[email protected]>
Cc: [email protected]
Date: Tue, 17 May 2011 09:52:54 -0500
Ah. I thought this applied to both UDP broadcast and unicast, but the message below seems to indicate only unicast. So, based on that, you wouldn't have any problem if EPICS_CA_ADDR_LIST was empty as it would broadcast. But I see Bruce is set to broadcast as well, so now I'm not sure what his issue is.

Below a snippet from Jeff Hill from tech-talk archives:
<snip>
PS: Behavior is known to vary between IP kernels for such unicast addresses
if there are two or more daemons (in this case two or more CA UDP servers)
listening to the same {IP address, port} tuple on the same host. The typical
behavior difference is that on certain IP kernels only one daemeon listening
on UDP port 5064 will receive a UDP message with a unicast destination
address, but in contrast on other IP kernels all daemeons listening on UDP
port 5064 will receive such messages. In my experience UDP frames with
broadcast address destinations always go to all registered listeners
listening on UDP port 5064 - a uniform behavior across IP kernel
implementations.
</snip>

    Claude

On 05/17/2011 09: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* 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 Jeff Hill
References:
Channel Access not connecting Bruce Hill
Re: Channel Access not connecting Claude Saunders
RE: Channel Access not connecting Mark Rivers

Navigate by Date:
Prev: RE: Channel Access not connecting Mark Rivers
Next: TCP_NODELAY option set failed Michael Davidsaver
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  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: Channel Access not connecting Mark Rivers
Next: RE: Channel Access not connecting Jeff 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  2020  2021  2022  2023  2024 
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 ·