Date: Mon, 7 Nov 2011 17:35:39 GMT From: Jukka Ukkonen <jau@iki.fi> To: freebsd-gnats-submit@FreeBSD.org Subject: kern/162352: Enhancement: Message-ID: <201111071735.pA7HZd3N092295@red.freebsd.org> Resent-Message-ID: <201111071740.pA7He6th045313@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 162352 >Category: kern >Synopsis: Enhancement: >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Mon Nov 07 17:40:06 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Jukka Ukkonen >Release: FreeBSD-9.0-RC1 >Organization: --- >Environment: Sorry, the system I tried this on is powered down at this moment. FreeBSD-9.0-RC1 still covers it all. >Description: In FreeBSD there has been getsockname()/getpeername() which have easily provided the address family of a socket and getsockopt() with SO_TYPE providing the communication type (stream, datagram, sequential packet, reliable packet delivery) for the socket. The thing that has been missing has been an easy way to find the protocol used. Now that we have 2 protocols TCP and SCTP for address families inet and inet6 which can both be stream sockets we really need an easy way to ask the kernel for the actual protocol. The attached patch adds a new socket option SO_PROTO (aliased to SO_PROTOCOL for Linux compatibility) to getsockopt(). I decided to call the option SO_PROTO due to the fact that we already have a whole lot of IPPROTO_this_and_that and I simply wanted to follow the tradition in the naming. Naturally this option cannot be used for setsockopt(). Assume we have a function which gets an anonymous socket as a call argument or a program which receives an anonymous socket from an another program over a UNIX domain socket or inherits one from its parent. To do anything useful with the socket one would most likely have to know what are the address family, the communication type, and the protocol used with that socket. An additional benefit will be improved portability between FreeBSD and other UNIX type systems. At least Linux has a similar feature. >How-To-Repeat: No problem when the attached patch gets applied to the system. This is just a very straight forward extension, not a bug as such. The extension follows the exact same model that has already been used for SO_TYPE. So, it should be harmless and very useful. >Fix: Try to figure out the protocol used for a previously unknown socket inside a function without the attached patch and the reasoning for this enhancement should be obvious. The patch should work roughly as-is also for older FreeBSD versions, but notice that I have only tried it on FreeBSD-9.0-RC1. Patch attached with submission follows: --- src/sys/sys/socket.h.orig 2011-11-05 23:25:51.000000000 +0200 +++ src/sys/sys/socket.h 2011-11-06 09:21:41.000000000 +0200 @@ -139,6 +139,8 @@ #define SO_SETFIB 0x1014 /* use this FIB to route */ #define SO_USER_COOKIE 0x1015 /* user cookie (dummynet etc.) */ #endif +#define SO_PROTO 0x1016 /* Get socket protocol IPPROTO_xyz. */ +#define SO_PROTOCOL SO_PROTO /* Linux compatibility */ /* * Structure used for manipulating linger option. --- src/sys/kern/uipc_socket.c.orig 2011-11-05 23:20:34.000000000 +0200 +++ src/sys/kern/uipc_socket.c 2011-11-05 23:43:01.000000000 +0200 @@ -2730,6 +2730,10 @@ optval = so->so_type; goto integer; + case SO_PROTO: + optval = so->so_proto->pr_protocol; + goto integer; + case SO_ERROR: SOCK_LOCK(so); optval = so->so_error; >Release-Note: >Audit-Trail: >Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201111071735.pA7HZd3N092295>