'Connection refused' message when sending a beacon is confusing

Bug #541324 reported by Jeff Hill
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

> ../online_notify.c: CA beacon (send to "") error was
> "Connection refused"
> What does this mean? Why is it trying to connect to the broadcast
> address?

Additional information:
This message is emitted when the socket library indicates an error condition when the CA server attempts to send its beacon message. The part in quotes is a direct ASCII translation of the error number supplied by the socket library (the error number returned by the "sendto" function). Such details can be confusing at times, but can also be quite useful when attempting to debug networking problems so when coding this component I was not inclined to suppress them.

So one might ask the question, "how can we get a connection refused error when sending the CA beacon considering that the beacon is based on UDP which isn’t a connection oriented protocol?" My best guess is that a previous call to sendto elicited the ICMP error response message "port unreachable", and somehow the IP kernel is caching this response and returning ECONNREFUSED condition from a subsequent call to sendto. Mark is probably correct in guessing that there is a derelict device on your network that doesn’t know that sending the ICMP error message "port unreachable" in response to a broadcast message is improper etiquette.

It turns out that in this situation the CA server is "connecting" its UDP socket in order to obtain the IP address of the network interface (there can be more than one of them) that will be selected by the host's routing tables to send the beacon message. This is done so that this interface's address can be embedded in the beacon message. It also turns out that it is normal in BSD Unix to return ECONNREFUSED when a "connected" UDP socket elicits the "port unreachable" ICMP response.

Original Mantis Bug: mantis-294

Tags: ca
Revision history for this message
Jeff Hill (johill-lanl) wrote :

So ... to avoid confusion in the future I could modify the code to "disconnect" the UDP socket prior to sending the message (slightly more overhead) or I could add code to suppress this specific message - when ECONNREFUSED is returned.

Andrew Johnson (anj)
Changed in epics-base:
status: New → Confirmed
Revision history for this message
Till Straumann (strauman) wrote :

Same behavior under windows. Caused me a lot of grief recently (in a different application). You can actually turn that off (windows) using an (undocumented) socket ioctl _WSAIOW(IOC_VENDOR, 12). However, it's probably best to ignore that message. Windows has this problem (w/o the aforementioned ioctl) even for sockets that are not 'connected' and the socket call (even if it's a 'receive from anywhere') that follows the send operation which caused the ICMP message fails.

I.e., the sequence

sd = socket();
sendto(sd, data, n, 0, nonexisting_dest, sizeof(nonexisting_dest))

status = recvfrom(sd, ...)

fails in **recvfrom** due to the ICMP message that resulted from the earlier sendto!

Changed in epics-base:
assignee: nobody → mdavidsaver (mdavidsaver)
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.