[DragonFlyBSD - Bug #2965] read(2), etc. return EAFNOSUPPORT after UDP disconnect

bugtracker-admin at leaf.dragonflybsd.org bugtracker-admin at leaf.dragonflybsd.org
Mon Nov 21 20:32:13 PST 2016

Issue #2965 has been updated by cmusser.

Yes, that change does prevent the subsequent read(2) (after the disconnect) from returning EAFNOSUPPORT.


if soconnect_async = 1, the connect(2) to the null address (the disconnect) returns 0 (no error).
if soconnect_async = 0, the connect(2) to the null address -1 and sets errno to EAFNOSUPPORT.

Either one of these seems reasonable (Linux acts like case 1, the other BSDs act like case 2). The standard advice is to consider either of these cases to mean success, so the way it works is probably OK. Might want to document it though.

Bug #2965: read(2), etc. return EAFNOSUPPORT after UDP disconnect

* Author: cmusser
* Status: New
* Priority: Normal
* Assignee: 
* Category: Networking
* Target version: 
I ran into an unexpected return code from read(2)-like functions after unconnecting a connected UDP socket. 

>From what I've gleaned (from Stevens' "UNP", man pages, testing on other systems). unconnecting a connected UDP socket is done by passing a "null address" to connect(2). In response, it unconnects the socket and returns success (0) or EAFNOSUPPORT

On DragonFly, connect(2) returns success and unconnects the socket, but then the next read from the socket returns EAFNOSUPPORT. It seems as if EAFNOSUPPORT should come from `connect(2) instead. Neither read(2), recvfrom(2) or recvmsg(2) are documented as returning EAFNOSUPPORT.

I have a Github project at https://github.com/cmusser/udp_disconnect that demonstrates this behavior.

You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account

More information about the Bugs mailing list