Experimental Physics and
Industrial Control System

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

> I gather with linux, the network stack will only
> deliver an incoming (pv search) broadcast UDP packet to one of those
> processes.

You will see a warning message about the issue when you start the 2nd IOC.
As a workaround, a unicast (a single host IP) in the EPICS_CA_ADDR_LIST will
connect. 

PS: The new multicasting support will provide a nice solution for this
issue.

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