| 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 | 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 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Re: error of beacon |
| From: | Scott Baily <[email protected]> |
| To: | Andrew Johnson <[email protected]> |
| Cc: | Azra Jabeen <[email protected]>, "[email protected]" <[email protected]> |
| Date: | Thu, 07 Aug 2014 08:08:12 -0600 |
On 8/5/2014 11:32 AM, Andrew Johnson wrote:
On 08/05/2014 11:58 AM, Hill, Jeff wrote:../online_notify.c: CA beacon (send to "192.168.1.143:5065") error was"Connection refused The host in question might be returning an ICMP port unreachable response. Typically, ICMP replies are not sent in response to a broadcast message by a well behaved IP stack, but if there was an explicit unicast IP in in the CA address list on this particular IOC (with the annoying messages), then an ICMP response when no CA repeater daemon is listening from this particular host (192.168.1.143) is likely to occur. Another possibility might be problems with the route from the IOC (with the annoying messages) to this particular host (192.168.1.143).We need to add code to suppress this message after it has been output a few times. The APS has operational IOCs for which we cannot see the console history because of floods from this error report. Our network guys have developed ways of tracing where the ICMP messages come from and can usually reconfigure the devices we trace them to to end them, but once the beacon error messages from online_notify.c have started we have to reboot the IOCs to stop them again (not always possible while we're running). If you want to take a look at fixing the code I'd be happy to help out with testing, but if you don't have time I will be working on this and committing changes to the 3.14 branch to severely reduce the frequency of these error messages.
I'm pretty sure this is related to the new TCP/IP stack in a recent version of vxWorks (I believe the change was in 6.5). Our IOCs will occasionally receive the connection refused message in response to a broadcast. A soft IOC running on linux, printed this connection refused message exactly twice. All of our 6.8 IOCs repeat this message until reboot, AND do not send out beacons, until the reboot. However, it is possible to send out a broadcast from the IOC (e.g., ping the broadcast address). I haven't had time to test anything, but I think the solution will be either to send the broadcast anyway, and suppress the message after the first few, or to actually setup a new UDP socket after receiving this message. Although, these are really just workarounds, perhaps we should take this up with WindRiver (I don't see any reason why a local UDP broadcast socket should need to be invalidated because of an ICMP response from a misbehaving device).
-- Scott Baily AOT-IC, MS H820 Los Alamos National Laboratory Los Alamos, NM 87545 ph: (505) 606-2260