Adding UDP/TCP/Unix socket support to rlm_linelog
I've added UDP/TCP/Unix socket support to rlm_linelog in v3.1.x It's currently write only. It discards all responses. This support is intended to be used with things like carbon collector (graphite) and collectd, and is the result of the discussion on adding a rlm_graphite. The data written can be taken directly from octets type attributes, using an attribute ref as the format CONF_PAIR value. I'd appreciate comments and feedback on the socket code. It was written the code editor open in one window, and pubs.opengroup.org in the other, but that doesn't mean it will actually work the way it was intended across multiple platforms. Doing write(fd, NULL, 0); to check for socket connectedness seems like it's going to blow up somewhere at some point, so suggestions for what to do to get pending errors would be very helpful. I've merged a lot of the socket code back into v3.0.x, as the changes for TCP sockets were very minor, and it'll allow us to implement timeouts easily for RADIUS+TCP/RADSEC/Radmin connections. The main commits are: https://github.com/FreeRADIUS/freeradius-server/commit/7e850301ffd3a43a1808b... https://github.com/FreeRADIUS/freeradius-server/commit/97c3e8b01339d66a84a3c... I plan to fixup the config parsing a bit. Seems stupid to have to define the destination when it could be inferred from the config sections that are present, but that can't be done currently because of issues in the conf parser. There also needs to be a connect_timeout distinct from the write timeout. But that should probably be added to the connection pool section, as virtually every module that uses the connection pool supports connection timeouts, and putting in the pool section helps with consistency, even if the actual timeout is done by the library. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On 20/03/2015 18:31, Arran Cudbard-Bell wrote:
I'd appreciate comments and feedback on the socket code. It was written the code editor open in one window, and pubs.opengroup.org in the other, but that doesn't mean it will actually work the way it was intended across multiple platforms.
Very likely not, in all cases :o(
Doing write(fd, NULL, 0); to check for socket connectedness seems like it's going to blow up somewhere at some point, so suggestions for what to do to get pending errors would be very helpful.
I'd advise looking at the libevent code to see what they do. There should probably be some version of that lisp quote, but for libevent ;o) TBH it seems crazy-broken that OS X isn't returning pending errors but does then return an error on write(). Maybe that's an OS X bug? What type of sockets was this with?
On 23 Mar 2015, at 10:47, Phil Mayers <p.mayers@IMPERIAL.AC.UK> wrote:
On 20/03/2015 18:31, Arran Cudbard-Bell wrote:
I'd appreciate comments and feedback on the socket code. It was written the code editor open in one window, and pubs.opengroup.org in the other, but that doesn't mean it will actually work the way it was intended across multiple platforms.
Very likely not, in all cases :o(
Doing write(fd, NULL, 0); to check for socket connectedness seems like it's going to blow up somewhere at some point, so suggestions for what to do to get pending errors would be very helpful.
I'd advise looking at the libevent code to see what they do. There should probably be some version of that lisp quote, but for libevent ;o)
I think we're closer to 2/3rds now.
TBH it seems crazy-broken that OS X isn't returning pending errors but does then return an error on write(). Maybe that's an OS X bug? What type of sockets was this with?
Just a TCP socket with O_NONBLOCK set. Libevent uses SO_ERROR, which is helpfully documented on the Linux man page for connect, but not on the OSX man page or the pubs.opengroup.org page. The description here http://pubs.opengroup.org/onlinepubs/9699919799/ says: SO_ERROR - Requests and clears pending error information on the socket (getsockopt() only). So I guess that's it... Cheers, Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
participants (2)
-
Arran Cudbard-Bell -
Phil Mayers