'Connection refused' message when sending a beacon is confusing
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| EPICS Base |
Confirmed
|
Wishlist
|
mdavidsaver | ||
Bug Description
> ../online_notify.c: CA beacon (send to "172.16.
> "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
http://
| Jeff Hill (johill-lanl) wrote | #1 |
| Changed in epics-base: | |
| status: | New → Confirmed |
| Till Straumann (strauman) wrote | #2 |
| Changed in epics-base: | |
| assignee: | nobody → mdavidsaver (mdavidsaver) |
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.