Hi,

coming back to this after quite some time, trying to build on OSX 10.5...

On Wed, Feb 22, 2012 at 11:49:15AM -0800, debrabander wrote:
> This is not the a problem when building using the latest Mac OS X SDK.
> I've did a quick search and it seems to be a more common issue on some
> (old) Darwin platforms. Please try building again after applying the
> patch below.
> 
> 
> Signed-off-by: Frank de Brabander <debraban...@gmail.com>
> ---
>  socket.c |    5 +++++
>  1 files changed, 5 insertions(+), 0 deletions(-)
> 
> diff --git a/socket.c b/socket.c
> index 1a772af..6337900 100644
> --- a/socket.c
> +++ b/socket.c
> @@ -893,8 +893,13 @@ create_socket_udp6 (const unsigned int flags)
>    else if (flags & SF_USE_IP_PKTINFO)
>      {
>        int pad = 1;
> +#ifndef IPV6_RECVPKTINFO /* Some older Darwin platforms require this
> */
> +      if (setsockopt (sd, IPPROTO_IPV6, IPV6_PKTINFO,
> +                   (void*)&pad, sizeof(pad)) < 0)
> +#else
>        if (setsockopt (sd, IPPROTO_IPV6, IPV6_RECVPKTINFO,
>                     (void*)&pad, sizeof(pad)) < 0)
> +#endif
>       msg(M_SOCKERR, "UDP: failed setsockopt for IPV6_RECVPKTINFO");
>      }
>  #endif
> --
> 1.7.5.4

I think the patch is fine, and I now understand why :-)

IPV6_PKTINFO is part of the "extended socket API" defined in RFC2292.
That RFC used IPV6_PKTINFO both for receiving the destination IPv6 address
in UDP packets, and for setting the source address for outgoing packets.

RFC2292 was updated by RFC3542, which renamed the "receive" function to
IPV6_RECVPKTINFO, leaving the "sending" function as IPV6_PKTINFO - and,
subsequently, in FreeBSD they have different "setsockopt()" opcodes.

So, on a system that has *both*, we need to use IPV6_RECVPKTINFO for
receving (turning it on with setsockopt) to make --multihome work, and
IPV6_PKTINFO for sending (which we don't actually do).  

On a system that only has IPV6_PKTINFO, because it's API only implements
2292 (MacOS up until 10.6), use IPV6_PKTINFO for setsockopt().


Now, the interesting question is whether a 10.5-compiled openvpn.exe
will behave correctly under 10.7 if --multihome is active...

Regarding the patch: I hereby ACK, and would ask David to include
a reference to RFC2292 and RFC3542 in the commit log, so others can
find this information more easily.

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             g...@greenie.muc.de
fax: +49-89-35655025                        g...@net.informatik.tu-muenchen.de

Attachment: pgpsREbP1UF6h.pgp
Description: PGP signature

Reply via email to