Experimental Physics and
Industrial Control System

"Hill, Jeffrey O" <[email protected]> · Tue, 17 Apr 2012 16:09:03 +0000

> I think we should change the way that the RSRV sends out beacon packets 
> from calling connect() followed by send() to just calling sendto().

As I recall, the determining factor is the "commect"ed state of the 
UDP socket, and not which call send/recv/sendto/recvfrom/etc are used, 
but IP kernel implementations are evolving so this is perhaps a moving 
target. Furthermore, attempts to dis"connect" a UDP socket in the past by 
attaching it to AF_ANY address (as opposed to an AF_INET address) 
has been a source of portability problems. 

BTW, in the new server I have allocated a dedicated UDP socket for 
each of the network interfaces that are discovered on the local host, 
and during initialization the list of beacon destination addresses is 
traversed with each of them being assigned to one of these dedicated 
UDP sockets. This avoids any need to connect a UDP socket to a 
destination at any time except, using as I recall a temporary UDP 
socket to determine a local interface used for the beacon's destination, 
during initialization.

Jeff

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> On Behalf Of Andrew Johnson
> Sent: Tuesday, April 17, 2012 9:12 AM
> To: [email protected]
> Subject: Re: Channel Access problem over SSH
> 
> Hi Michael,
> 
> On 2012-04-17 [email protected] wrote:
> > From: [email protected] [mailto:tech-talk-
> [email protected]]
> >  On Behalf Of Pavel Masloff
> >
> > > Look. I have noticed that even when I am normally starting
> > > an IOC on a linux machine, then I get these messages:
> > > online_notify.c:CA beacon (send to "172.20.255.255:5065") error was
> > > "Connection refused"
> >
> > These messages are an old old chestnut and a pain in the bum.  We get
> them
> > here all the time on our development network, and I understand that
> > they're triggered by a misconfigured IOC somewhere on our network
> > incorrectly responding to discovery packets (or something like that).  I
> > would so much like to see the offending machine thrown in the bin, but
> > apparently it's too hard to fix or something.
> 
> I started seeing these recently from vxWorks 6.8 and in looking further
> discovered how to enable them on Linux too.  I think we should change the
> way
> that the RSRV sends out beacon packets from calling connect() followed by
> send() to just calling sendto().  The former method allows us to detect
> ICMP
> returns, but it's starting to look like we don't really want to do that,
> especially since the error gets reported on a later use of that socket by
> which time we may have changed the address if we have more than one
> address in
> the EPICS_CA_ADDR_LIST or EPICS_CAS_BEACON_ADDR_LIST.
> 
> Any comments on that idea from the more network-savvy developers out
> there?
> 
> - Andrew
> --
> Never interrupt your enemy when he is making a mistake.
> -- Napoleon Bonaparte

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System