Re: Removal of deprecated implied connect for TCP
On Sun, 29 Aug 2010, Andre Oppermann wrote: When T/TCP RFC1644 support was introduced in r6283 by wollman 15 years ago the semantics of sendto(2) with regard to TCP sockets were changed. It became possible directly do a sendto(2) call with the target address in the *to argument instead of doing a connect(2) first and subsequent write(2) or send(2) calls as the standard TCP API specifies. Optionally MSG_EOR could be specified to close the connection again right again after the data has been sent out. This is totally non-portable and no other OS (Linux, NetBSD, OpenBSD, Solaris, HP-UX) ever supported this functionality for TCP sockets. FreeBSD was the only OS to ever ship this. T/TCP was ill-defined and had major security issues and never gained any support. It has been defunct in FreeBSD and most code has been removed about 6 years ago. The sendto(2) extended functionality is one of the last parts that persisted and remained around living a zombie life. I want to remove it now because it is totally non-portable, has no known users and complicates the TCP send path. The patch is attached. If you have any objections speak up now. I'm not entirely comfortable with this change, and would like a chance to cogitate on it a bit more. While I'm not aware of any applications depending on the semantic for TCP, I know that we do use it for UNIX domain sockets. Since it's a documented API, if we are going to remove it, then we need to go through a deprecation process, not least by marking it as a deprecated API in 8.x before having it vanish in 9.0. (I won't be sorry to see the complexity go, but I'm not sure I have all the implications in mind as yet...) Robert ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Removal of deprecated implied connect for TCP
On Aug 31, 2010, at 12:04 PM, Robert Watson wrote: > > On Sun, 29 Aug 2010, Andre Oppermann wrote: > >> When T/TCP RFC1644 support was introduced in r6283 by wollman 15 years ago >> the semantics of sendto(2) with regard to TCP sockets were changed. >> >> It became possible directly do a sendto(2) call with the target address in >> the *to argument instead of doing a connect(2) first and subsequent write(2) >> or send(2) calls as the standard TCP API specifies. Optionally MSG_EOR >> could be specified to close the connection again right again after the data >> has been sent out. >> >> This is totally non-portable and no other OS (Linux, NetBSD, OpenBSD, >> Solaris, HP-UX) ever supported this functionality for TCP sockets. FreeBSD >> was the only OS to ever ship this. >> >> T/TCP was ill-defined and had major security issues and never gained any >> support. It has been defunct in FreeBSD and most code has been removed about >> 6 years ago. The sendto(2) extended functionality is one of the last parts >> that persisted and remained around living a zombie life. >> >> I want to remove it now because it is totally non-portable, has no known >> users and complicates the TCP send path. The patch is attached. >> >> If you have any objections speak up now. > > I'm not entirely comfortable with this change, and would like a chance to > cogitate on it a bit more. While I'm not aware of any applications depending > on the semantic for TCP, I know that we do use it for UNIX domain sockets. > Since it's a documented API, if we are going to remove it, then we need to go > through a deprecation process, not least by marking it as a deprecated API in > 8.x before having it vanish in 9.0. sendto() is also used for SCTP SOCK_STREAMS and SOCK_SEQPACKET sockets... Best regards Michael > > (I won't be sorry to see the complexity go, but I'm not sure I have all the > implications in mind as yet...) > > Robert > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Removal of deprecated implied connect for TCP
On 31.08.2010 12:04, Robert Watson wrote: On Sun, 29 Aug 2010, Andre Oppermann wrote: When T/TCP RFC1644 support was introduced in r6283 by wollman 15 years ago the semantics of sendto(2) with regard to TCP sockets were changed. It became possible directly do a sendto(2) call with the target address in the *to argument instead of doing a connect(2) first and subsequent write(2) or send(2) calls as the standard TCP API specifies. Optionally MSG_EOR could be specified to close the connection again right again after the data has been sent out. This is totally non-portable and no other OS (Linux, NetBSD, OpenBSD, Solaris, HP-UX) ever supported this functionality for TCP sockets. FreeBSD was the only OS to ever ship this. T/TCP was ill-defined and had major security issues and never gained any support. It has been defunct in FreeBSD and most code has been removed about 6 years ago. The sendto(2) extended functionality is one of the last parts that persisted and remained around living a zombie life. I want to remove it now because it is totally non-portable, has no known users and complicates the TCP send path. The patch is attached. If you have any objections speak up now. I'm not entirely comfortable with this change, and would like a chance to cogitate on it a bit more. While I'm not aware of any applications depending on the semantic for TCP, I know that we do use it for UNIX domain sockets. I don't have any plans to remove the implied connect support from the socket layer or other protocols, only from TCP. > Since it's a documented API, if we are going to remove it, then we need to go through a deprecation process, not least by marking it as a deprecated API in 8.x before having it vanish in 9.0. > (I won't be sorry to see the complexity go, but I'm not sure I have all the implications in mind as yet...) The only implication would be a FreeBSD-only application (since nobody else ever supported it) that depends on the TCP implied connect. While not impossible it is unlikely for such an application to exist. For deprecating this part of the TCP API there is no documentation to the implied connect in tcp(4). In sendto(2) it doesn't differentiate between protocols and simply says: "... sendto() and sendmsg() may be used at any time." For MSG_EOF it says that is only supported for SOCK_STREAM sockets in the PF_INET protocol family. These sentences have to be corrected. -- Andre ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Removal of deprecated implied connect for TCP
On 31.08.2010 15:01, Michael Tüxen wrote: On Aug 31, 2010, at 12:04 PM, Robert Watson wrote: On Sun, 29 Aug 2010, Andre Oppermann wrote: When T/TCP RFC1644 support was introduced in r6283 by wollman 15 years ago the semantics of sendto(2) with regard to TCP sockets were changed. It became possible directly do a sendto(2) call with the target address in the *to argument instead of doing a connect(2) first and subsequent write(2) or send(2) calls as the standard TCP API specifies. Optionally MSG_EOR could be specified to close the connection again right again after the data has been sent out. This is totally non-portable and no other OS (Linux, NetBSD, OpenBSD, Solaris, HP-UX) ever supported this functionality for TCP sockets. FreeBSD was the only OS to ever ship this. T/TCP was ill-defined and had major security issues and never gained any support. It has been defunct in FreeBSD and most code has been removed about 6 years ago. The sendto(2) extended functionality is one of the last parts that persisted and remained around living a zombie life. I want to remove it now because it is totally non-portable, has no known users and complicates the TCP send path. The patch is attached. If you have any objections speak up now. I'm not entirely comfortable with this change, and would like a chance to cogitate on it a bit more. While I'm not aware of any applications depending on the semantic for TCP, I know that we do use it for UNIX domain sockets. Since it's a documented API, if we are going to remove it, then we need to go through a deprecation process, not least by marking it as a deprecated API in 8.x before having it vanish in 9.0. > sendto() is also used for SCTP SOCK_STREAMS and SOCK_SEQPACKET sockets... sendto() will not be touched or modified. It's just that on a TCP socket the tcp protocol will not perform an implied connect anymore. The only thing that changes is TCP dropping a deprecated and experimental extension and behaving like every other UNIXy OS. sendto() will continue to work for UDP, SCTP and Domain sockets and whoever else currently supports it, except TCP. -- Andre ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Removal of deprecated implied connect for TCP
In article <4c7d02bb.40...@freebsd.org> an...@freebsd.org writes: >sendto() will not be touched or modified. It's just that on a TCP socket >the tcp protocol will not perform an implied connect anymore. The only thing >that changes is TCP dropping a deprecated and experimental extension and >behaving like every other UNIXy OS. That's a little bit disingenuous, methinks. Support for the "deprecated and experimental extension" -- RFC 1644 -- was dropped a number of years ago. (Longer ago than I can easily recall.) The implict open/close mechanism is orthogonal to the long-gone support for RFC 1644. There may be good reasons to remove it anyway, but please don't claim that the status of RFC 1644 has anyting to do with it. -GAWollman ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Removal of deprecated implied connect for TCP
On Tue, 31 Aug 2010, Andre Oppermann wrote: I'm not entirely comfortable with this change, and would like a chance to cogitate on it a bit more. While I'm not aware of any applications depending on the semantic for TCP, I know that we do use it for UNIX domain sockets. I don't have any plans to remove the implied connect support from the socket layer or other protocols, only from TCP. Right -- the implicit question is: why should TCP be the only stream protocol in our stack *not* to support implied connection, when we plan to continue to support it for all other protocols? For deprecating this part of the TCP API there is no documentation to the implied connect in tcp(4). In sendto(2) it doesn't differentiate between protocols and simply says: "... sendto() and sendmsg() may be used at any time." For MSG_EOF it says that is only supported for SOCK_STREAM sockets in the PF_INET protocol family. These sentences have to be corrected. In general, deprecating is taken to mean providing significant and explicit advance warning of removal -- for example, updating the 8.x man page to point out that the feature is deprecated and it will not appear in future releases of FreeBSD. Robert ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/150052: wi(4) driver does not work with wlan(4) driver for Lucent Orinoco Cards
Synopsis: wi(4) driver does not work with wlan(4) driver for Lucent Orinoco Cards Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Wed Sep 1 05:49:49 UTC 2010 Responsible-Changed-Why: reassign to networking team http://www.freebsd.org/cgi/query-pr.cgi?pr=150052 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
