| 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 <2012> 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 <2012> 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | RE: Channel Access problem over SSH |
| From: | "Hill, Jeffrey O" <[email protected]> |
| To: | Pavel Masloff <[email protected]> |
| Cc: | EPICS Tech Talk <[email protected]> |
| 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:[email protected]] Jeff, On Mon, Apr 9, 2012 at 4:59 PM, Hill, Jeffrey O <[email protected]> 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:
[email protected] [mailto:[email protected]]
On Behalf Of Pavel Masloff Hello tech-talkers,
|