https://bugs.dragonflybsd.org/https://bugs.dragonflybsd.org/favicon.ico?16293952082016-11-22T01:29:05ZDragonFlyBSD bugtrackerDragonFlyBSD - Bug #2965: read(2), etc. return EAFNOSUPPORT after UDP disconnecthttps://bugs.dragonflybsd.org/issues/2965?journal_id=130342016-11-22T01:29:05Zcmussercmusser@sonic.net
<ul></ul><p>Turns out that the kern.ipc.soconnect_async sysctl flag affects this. When disabled, the behavior is similar to the other BSDs: disconnecting a connected UDP socket returns EAFNOSUPPORT from connect(2), not read(2). Not sure if the soconnect_async flag is supposed to affect UDP sockets, but it does.</p> DragonFlyBSD - Bug #2965: read(2), etc. return EAFNOSUPPORT after UDP disconnecthttps://bugs.dragonflybsd.org/issues/2965?journal_id=130352016-11-22T02:21:30Zsepherosa
<ul></ul><p>OK, I see. I think the main issue is returning connect(2) error from<br />read(2) in async mode.</p>
<p>On Tue, Nov 22, 2016 at 9:29 AM,<br /><<a class="email" href="mailto:bugtracker-admin@leaf.dragonflybsd.org">bugtracker-admin@leaf.dragonflybsd.org</a>> wrote:</p>
<blockquote>
<p>Issue <a class="issue tracker-1 status-3 priority-4 priority-default closed" title="Bug: read(2), etc. return EAFNOSUPPORT after UDP disconnect (Resolved)" href="https://bugs.dragonflybsd.org/issues/2965">#2965</a> has been updated by cmusser.</p>
<p>Turns out that the kern.ipc.soconnect_async sysctl flag affects this. When disabled, the behavior is similar to the other BSDs: disconnecting a connected UDP socket returns EAFNOSUPPORT from connect(2), not read(2). Not sure if the soconnect_async flag is supposed to affect UDP sockets, but it does.</p>
<p>----------------------------------------<br />Bug <a class="issue tracker-1 status-3 priority-4 priority-default closed" title="Bug: read(2), etc. return EAFNOSUPPORT after UDP disconnect (Resolved)" href="https://bugs.dragonflybsd.org/issues/2965">#2965</a>: read(2), etc. return EAFNOSUPPORT after UDP disconnect<br /><a class="external" href="http://bugs.dragonflybsd.org/issues/2965#change-13034">http://bugs.dragonflybsd.org/issues/2965#change-13034</a></p>
<ul>
<li>Author: cmusser</li>
<li>Status: New</li>
<li>Priority: Normal</li>
<li>Assignee:</li>
<li>Category: Networking</li>
<li>Target version:<br />----------------------------------------<br />I ran into an unexpected return code from read(2)-like functions after unconnecting a connected UDP socket.</li>
</ul>
<p>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</p>
<p>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.</p>
<p>I have a Github project at <a class="external" href="https://github.com/cmusser/udp_disconnect">https://github.com/cmusser/udp_disconnect</a> that demonstrates this behavior.</p>
<p>--<br />You have received this notification because you have either subscribed to it, or are involved in it.<br />To change your notification preferences, please click here: <a class="external" href="http://bugs.dragonflybsd.org/my/account">http://bugs.dragonflybsd.org/my/account</a></p>
</blockquote>
<p>-- <br />Tomorrow Will Never Die</p> DragonFlyBSD - Bug #2965: read(2), etc. return EAFNOSUPPORT after UDP disconnecthttps://bugs.dragonflybsd.org/issues/2965?journal_id=130362016-11-22T03:04:05Zsepherosa
<ul></ul><p>The read error issue is fixed by<br />219503cf61ebf0aa6c01e49f6b073f0a40e0f1ec on the latest master. I<br />believe it should be adequate to fix your issue for asynchronous<br />connect.</p>
<p>On Tue, Nov 22, 2016 at 10:21 AM, Sepherosa Ziehau <<a class="email" href="mailto:sepherosa@gmail.com">sepherosa@gmail.com</a>> wrote:</p>
<blockquote>
<p>OK, I see. I think the main issue is returning connect(2) error from<br />read(2) in async mode.</p>
<p>On Tue, Nov 22, 2016 at 9:29 AM,<br /><<a class="email" href="mailto:bugtracker-admin@leaf.dragonflybsd.org">bugtracker-admin@leaf.dragonflybsd.org</a>> wrote:</p>
<blockquote>
<p>Issue <a class="issue tracker-1 status-3 priority-4 priority-default closed" title="Bug: read(2), etc. return EAFNOSUPPORT after UDP disconnect (Resolved)" href="https://bugs.dragonflybsd.org/issues/2965">#2965</a> has been updated by cmusser.</p>
<p>Turns out that the kern.ipc.soconnect_async sysctl flag affects this. When disabled, the behavior is similar to the other BSDs: disconnecting a connected UDP socket returns EAFNOSUPPORT from connect(2), not read(2). Not sure if the soconnect_async flag is supposed to affect UDP sockets, but it does.</p>
<p>----------------------------------------<br />Bug <a class="issue tracker-1 status-3 priority-4 priority-default closed" title="Bug: read(2), etc. return EAFNOSUPPORT after UDP disconnect (Resolved)" href="https://bugs.dragonflybsd.org/issues/2965">#2965</a>: read(2), etc. return EAFNOSUPPORT after UDP disconnect<br /><a class="external" href="http://bugs.dragonflybsd.org/issues/2965#change-13034">http://bugs.dragonflybsd.org/issues/2965#change-13034</a></p>
<ul>
<li>Author: cmusser</li>
<li>Status: New</li>
<li>Priority: Normal</li>
<li>Assignee:</li>
<li>Category: Networking</li>
<li>Target version:<br />----------------------------------------<br />I ran into an unexpected return code from read(2)-like functions after unconnecting a connected UDP socket.</li>
</ul>
<p>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</p>
<p>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.</p>
<p>I have a Github project at <a class="external" href="https://github.com/cmusser/udp_disconnect">https://github.com/cmusser/udp_disconnect</a> that demonstrates this behavior.</p>
<p>--<br />You have received this notification because you have either subscribed to it, or are involved in it.<br />To change your notification preferences, please click here: <a class="external" href="http://bugs.dragonflybsd.org/my/account">http://bugs.dragonflybsd.org/my/account</a></p>
</blockquote>
<p>--<br />Tomorrow Will Never Die</p>
</blockquote>
<p>-- <br />Tomorrow Will Never Die</p> DragonFlyBSD - Bug #2965: read(2), etc. return EAFNOSUPPORT after UDP disconnecthttps://bugs.dragonflybsd.org/issues/2965?journal_id=130372016-11-22T04:32:13Zcmussercmusser@sonic.net
<ul></ul><p>Yes, that change does prevent the subsequent read(2) (after the disconnect) from returning EAFNOSUPPORT.</p>
<p>Observations:</p>
<p>if soconnect_async = 1, the connect(2) to the null address (the disconnect) returns 0 (no error).<br />if soconnect_async = 0, the connect(2) to the null address -1 and sets errno to EAFNOSUPPORT.</p>
<p>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.</p> DragonFlyBSD - Bug #2965: read(2), etc. return EAFNOSUPPORT after UDP disconnecthttps://bugs.dragonflybsd.org/issues/2965?journal_id=130382016-11-22T05:06:20Zsepherosa
<ul></ul><p>Yeah :)</p>
<p>On Tue, Nov 22, 2016 at 12:32 PM,<br /><<a class="email" href="mailto:bugtracker-admin@leaf.dragonflybsd.org">bugtracker-admin@leaf.dragonflybsd.org</a>> wrote:</p>
<blockquote>
<p>Issue <a class="issue tracker-1 status-3 priority-4 priority-default closed" title="Bug: read(2), etc. return EAFNOSUPPORT after UDP disconnect (Resolved)" href="https://bugs.dragonflybsd.org/issues/2965">#2965</a> has been updated by cmusser.</p>
<p>Yes, that change does prevent the subsequent read(2) (after the disconnect) from returning EAFNOSUPPORT.</p>
<p>Observations:</p>
<p>if soconnect_async = 1, the connect(2) to the null address (the disconnect) returns 0 (no error).<br />if soconnect_async = 0, the connect(2) to the null address -1 and sets errno to EAFNOSUPPORT.</p>
<p>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.</p>
<p>----------------------------------------<br />Bug <a class="issue tracker-1 status-3 priority-4 priority-default closed" title="Bug: read(2), etc. return EAFNOSUPPORT after UDP disconnect (Resolved)" href="https://bugs.dragonflybsd.org/issues/2965">#2965</a>: read(2), etc. return EAFNOSUPPORT after UDP disconnect<br /><a class="external" href="http://bugs.dragonflybsd.org/issues/2965#change-13037">http://bugs.dragonflybsd.org/issues/2965#change-13037</a></p>
<ul>
<li>Author: cmusser</li>
<li>Status: New</li>
<li>Priority: Normal</li>
<li>Assignee:</li>
<li>Category: Networking</li>
<li>Target version:<br />----------------------------------------<br />I ran into an unexpected return code from read(2)-like functions after unconnecting a connected UDP socket.</li>
</ul>
<p>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</p>
<p>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.</p>
<p>I have a Github project at <a class="external" href="https://github.com/cmusser/udp_disconnect">https://github.com/cmusser/udp_disconnect</a> that demonstrates this behavior.</p>
<p>--<br />You have received this notification because you have either subscribed to it, or are involved in it.<br />To change your notification preferences, please click here: <a class="external" href="http://bugs.dragonflybsd.org/my/account">http://bugs.dragonflybsd.org/my/account</a></p>
</blockquote>
<p>-- <br />Tomorrow Will Never Die</p> DragonFlyBSD - Bug #2965: read(2), etc. return EAFNOSUPPORT after UDP disconnecthttps://bugs.dragonflybsd.org/issues/2965?journal_id=131892017-07-07T19:15:28Zcmussercmusser@sonic.net
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Resolved</i></li></ul><p>This was fixed a while back.</p>