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  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020 
<== Date ==> <== Thread ==>

Subject: RE: Channel Access problem over SSH
From: "Hill, Jeffrey O" <johill@lanl.gov>
To: Pavel Masloff <pavel.masloff@gmail.com>
Cc: EPICS Tech Talk <tech-talk@aps.anl.gov>
Date: Tue, 17 Apr 2012 15:29:02 +0000

Hi Pavel,

 

Sorry, I should have given some addition details; what is occurring is that the thread in the IOC’s server that sends the beacon messages is using the “connect” function to fasten the UDP socket to a destination address. This was done so that the server can determine which of the local network interfaces will be used to forward out a beacon message that is being sent to a particular user configured destination address, when it is a system with multiple network interfaces. This is actually a somewhat common practice with UDP codes. The IOC’s proper source address is included in the beacon message so as not to preclude the potential for beacon messages being forwarded by other codes.

 

Ok, so when one “connect”s a UDP socket then any matching ICMP (IP networking diagnostic) message that is received by the IP kernel is cached with the socket, and this can result in an error being returned asynchronously from the next socket call {send, recv, etc} even if that call is by-itself, successful.  These ICMP error messages can be returned for various reasons. Typically, there might not be a UDP server listening at the destination address/port combination or it might be discovered, several hops away in the internet, that there isn’t a proper route to the destination. However, my understanding is that the RFCs require that an ICMP destination unreachable response is _not_ sent in response to a message with a _broadcast_ destination address. A message with a _unicast_ destination address will definitely solicit ICMP error responses, and also a poorly written IP kernel will be a possible source of aggravation. We had a situation here in the past where early HP/Apollo Unix machines, with improperly configured net masks, were sending an ICMP message in response to every CA broadcast (probably due to an IP kernel bug). At some point the number of improperly configured machines of this type grew to the point where this was actually overflowing the CA client’s UDP input queue, and thereby preventing the IOC’s response from getting through.

 

Up until now I haven’t 100% suppressed the warning messages that are emitted from this part of the code because the information can sometimes be useful when correcting EPICS CA configuration errors, but I am certainly open to suggestions from the user community, and I certainly _do_ buy into arguments for improving the signal-to-noise ratio with error messages.

 

Open to suggestions, threats etc.

 

Jeff

 

From: Pavel Masloff [mailto:pavel.masloff@gmail.com]
Sent: Tuesday, April 17, 2012 7:41 AM
To: Hill, Jeffrey O
Cc: EPICS Tech Talk
Subject: Re: Channel Access problem over SSH

 

Jeff,


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"

When I caget from another terminal window, the messages stop appearing. I stop the IOC. Then restart. No problems.
Should I set EPICS_CA_AUTO_BEACON_ADDR_LIST and EPICS_CA_BEACON_ADDR_LIST in linux (bashrc) or in directly in EPICS:

epicsEnvSet("EPICS_CA_AUTO_BEACON_ADDR_LIST","NO")
epicsEnvSet("EPICS_CA_BEACON_ADDR_LIST","localhost")

I think it has something to do with the Repeater (because of the port 5065)?

On Mon, Apr 9, 2012 at 4:59 PM, Hill, Jeffrey O <johill@lanl.gov> wrote:

Hi Pavel,

 

online_notify.c:CA beacon (send to "172.20.255.255:5065") error was "Connection refused"

This probably indicates that the IOC’s IP kernel is unable locate a route to the beacon address 172.20.255.255.

 

To avoid  this type of warning messages, one can modify the CA server beacon destination addresses, independent of the search message destination addresses, using EPICS_CA_AUTO_BEACON_ADDR_LIST and EPICS_CA_BEACON_ADDR_LIST. The server configuration chapter in the CA Reference Manual has some of the details.

 

Jeff

 

From: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-bounces@aps.anl.gov] On Behalf Of Pavel Masloff
Sent: Saturday, April 07, 2012 12:19 AM
To: EPICS Tech Talk
Subject: Channel Access problem over SSH

 

Hello tech-talkers,


There is an example IOC on a linux machine (Fedora 16) with an IP-address 172.20.92.99/16:
$EPICS_CA_ADDR_LIST=172.20.92.99
$EPICS_CA_AUTO_ADDR_LIST=NO

Which means I can access PVs on the same machine where the IOC is running. It works. No problem.

Now, when I connect to the linux machine via SSH from another machine on the same subnet (Windows XP, Putty), and when I run the IOC from the SSH client, then I get the following message in epics shell (over Putty) every once in a while:

online_notify.c:CA beacon (send to "172.20.255.255:5065") error was "Connection refused"

Still the IOC is running, I can caget, caput, camonitor. The Firewall is off. What might be the case?


Pavel




--
Best regards,


Pavel Maslov, MS
Controls Engineer at Pulsed power Lab
Efremov Institute for Electro-Physical Apparatus
St. Petersburg, Russia

Mobile: +7 (951) 672 22 19
Phone: +7 (812) 461 01 01




--
Best regards,


Pavel Maslov, MS
Controls Engineer at Pulsed power Lab
Efremov Institute for Electro-Physical Apparatus
St. Petersburg, Russia

Mobile: +7 (951) 672 22 19
Landline: +7 (812) 461 01 01


References:
Channel Access problem over SSH Pavel Masloff
RE: Channel Access problem over SSH Hill, Jeffrey O
Re: Channel Access problem over SSH Pavel Masloff

Navigate by Date:
Prev: RE: log message filter in Asyn Mark Rivers
Next: hardware register access Bai Jiaoni
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020 
Navigate by Thread:
Prev: RE: Channel Access problem over SSH Hill, Jeffrey O
Next: does CSS (CAJ?) support CA over an ssh tunnel Peter Milne
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020 
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 ·