Re: error of beacon

[Scott Baily <sbaily@lanl.gov>]

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