You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The UDP man pages states that received errors are returned on subsequent calls to the socket. Additionally, errors can be set to be collected and requested using a separate API.
Error handling
All fatal errors will be passed to the user as an error return even when the socket is not
connected. This includes asynchronous errors received from the network. You may get an
error for an earlier packet that was sent on the same socket. This behavior differs from
many other BSD socket implementations which don't pass any errors unless the socket is
connected. Linux's behavior is mandated by RFC 1122.
[...]
When the IP_RECVERR option is enabled, all errors are stored in the socket error queue,
and can be received by recvmsg(2) with the MSG_ERRQUEUE flag set.
Their current approach is to notify the PathStats monitor that the path in the message is down when the socket receives either ExternalInterfaceDown or InternalConnectivityDown. All other SCMP messages are propagated as an error.
The text was updated successfully, but these errors were encountered: