Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Tue, 17 May 2011 09:47:50 -0600

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.

> 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
______________________________________________________
Jeffrey O. Hill           Email        [email protected]
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

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> On Behalf Of Claude Saunders
> Sent: Tuesday, May 17, 2011 8:53 AM
> To: Mark Rivers
> Cc: [email protected]
> Subject: Re: Channel Access not connecting
> 
> 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
> ----------------------------------------------------------

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System