From owner-freebsd-current Tue May 8 12:12:10 2001 Delivered-To: freebsd-current@freebsd.org Received: from hunkular.glarp.com (hunkular.glarp.com [199.117.25.251]) by hub.freebsd.org (Postfix) with ESMTP id 8F78A37B423 for ; Tue, 8 May 2001 12:12:04 -0700 (PDT) (envelope-from huntting@hunkular.glarp.com) Received: from localhost (localhost [127.0.0.1]) by hunkular.glarp.com (8.11.1/8.11.1) with ESMTP id f48JC3053365 for ; Tue, 8 May 2001 13:12:04 -0600 (MDT) (envelope-from huntting@hunkular.glarp.com) Message-Id: <200105081912.f48JC3053365@hunkular.glarp.com> To: freebsd-current@freebsd.org Subject: user connection request data w/ recvmsg(2)/getsockopt(2) From: huntting@glarp.com Date: Tue, 08 May 2001 13:12:03 -0600 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The following jucy tidbit has been hiding in the accept(2) man page for several years, but has apparently never been implemented. One can obtain user connection request data without confirming the con- nection by issuing a recvmsg(2) call with an msg_iovlen of 0 and a non- zero msg_controllen, or by issuing a getsockopt(2) request. Similarly, one can provide user connection rejection information by issuing a sendmsg(2) call with providing only the control information, or by call- ing setsockopt(2). There is no mention of this feature in the man pages for getsockopt(2), recvmsg(2) or sendmsg(2). Rather than correct the accept(2), I'd really like to see this feature implemented in the kernel, and incorporated into tcp wrapper. I think it would really help limit limit the effectivness of portscanning. Who's idea was this origionally and do they have thoughts on why it should or should not be implemented? Any gottchas? brad To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message