Standard Nagios Plugins 1.4.9 and IPv6 problem?

[Holger Weiss]

* Holger Weiss <holger at CIS.FU-Berlin.DE> [2007-09-21 17:32]:
> * Andreas Ericsson <ae at op5.se> [2007-09-21 17:06]:
> > Holger Weiss wrote:
> > > -----------------------------------------------------------
> > > --- netutils.c.orig	2007-01-20 07:07:48.000000000 +0100
> > > +++ netutils.c	2007-09-21 16:28:13.117372070 +0200
> > > @@ -39,7 +39,7 @@
> > >  unsigned int socket_timeout = DEFAULT_SOCKET_TIMEOUT; 
> > >  int econn_refuse_state = STATE_CRITICAL;
> > >  int was_refused = FALSE;
> > > -int address_family = AF_UNSPEC;
> > > +int address_family = PF_INET;
> >
> > Since we're nitpicking anyways, this should be AF_INET, although
> > any system where AF_INET != PF_INET is quite clearly insane ;-)
>
> Heh :-P  At least on Linux, NetBSD and Solaris, getaddrinfo(3) uses the
> PF_* macros for the addrinfo->ai_family.  NetBSD's manpage explicitely
> defines it as the "protocol family" for the socket :-P

Okay, I did a little more digging on this critical question and stand
corrected :-)  While the original definition of getaddrinfo(3) in POSIX
1003.1g apparently[1] used PF_*, the current version of the standard[2]
uses AF_*.  Linux' getaddrinfo(3) manpage was changed[3] accordingly.

Holger

[1] See ftp://ftp.fu-berlin.de/doc/rfc/rfc2553.txt (6.4), for example.
[2] http://www.opengroup.org/onlinepubs/009695399/functions/getaddrinfo.html
    http://www.opengroup.org/onlinepubs/009695399/basedefs/netdb.h.html
[3] http://article.gmane.org/gmane.linux.kernel/339408 (getaddrinfo.3)

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null