Experimental Physics and
Industrial Control System

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