Mailing List Archive: Re: [Zebra-pj-commit] "quagga/lib ChangeLog sockopt.c sockopt.h"

Re: [Zebra-pj-commit] "quagga/lib ChangeLog sockopt.c sockopt.h"

Aug 19, 2004, 6:54 AM

Post #1 of 4 (407 views)

2004-08-19 Paul Jakma <paul@dishone.st>

* sockopt.h: Update renamed exported functions
Rename the CMSG_SIZE macros to IFINDEX.
Guard IPv4 PKTINFO in a conditional define.

#define SOPT_SIZE_CMSG_PKTINFO_IPV6() (sizeof (struct in6_pktinfo));

I don't mean to imply that you caused any problems with this, but
there seems to be an underlying problem in ospfd where this is used:

char buff [sizeof (*cmsg) + SOPT_SIZE_CMSG_PKTINFO_IPV4()];

msgh.msg_control = (caddr_t) buff;
msgh.msg_controllen = sizeof (buff);

The macro in sockopt.h returns the actual size, but the CMSG_SPACE
padding is not done (see /usr/include/sys/socket.h on netbsd, assuming
this is the same on linux but not sure).

In contrast, I fixed zebra/rtadvd.c:

msg.msg_controllen = CMSG_SPACE(sizeof(struct in6_pktinfo));

cmsghdr is 12 bytes, so on sparc and sparc64 it gets aligned to 16.

So I would expect this not to work on NetBSD/sparc64, yet it seems to.

Re: [Zebra-pj-commit] "quagga/lib ChangeLog sockopt.c sockopt.h" [ In reply to ]

paul at clubi

Aug 19, 2004, 7:52 AM

Post #2 of 4 (399 views)

Permalink

On Thu, 19 Aug 2004, Greg Troxel wrote:

> #define SOPT_SIZE_CMSG_PKTINFO_IPV6() (sizeof (struct in6_pktinfo));
>
> I don't mean to imply that you caused any problems with this, but
> there seems to be an underlying problem in ospfd where this is
> used:

Possible.

> char buff [sizeof (*cmsg) + SOPT_SIZE_CMSG_PKTINFO_IPV4()];
>
> msgh.msg_control = (caddr_t) buff;
> msgh.msg_controllen = sizeof (buff);
>
> The macro in sockopt.h returns the actual size, but the CMSG_SPACE
> padding is not done (see /usr/include/sys/socket.h on netbsd,
> assuming this is the same on linux but not sure).

Quite possible. My goal was simply to shift useage to a central place
with minimum of fuss. The above was the most common way to allocate
the cmsg buffer, so doing it so allowed me to remain bug compatible.

> In contrast, I fixed zebra/rtadvd.c:
>
> msg.msg_controllen = CMSG_SPACE(sizeof(struct in6_pktinfo));

I'd rather have SOPT_SIZE_CMSG_PKTINFO_IPV6() and have
SOPT_SIZE_CMSG_PKTINFO_IPV6() do the CMSG.

For IPv6 it doesnt matter, cause thankfully v6 APIs are more
consistent. But for v4, I'd prefer code not to have anything more
than a vague notion of "i want to retrieve the ifindex", and we migth
as well extend to v6.

This probably implies wrapping up controll message access completely.

> cmsghdr is 12 bytes, so on sparc and sparc64 it gets aligned to 16.
>
> So I would expect this not to work on NetBSD/sparc64, yet it seems to.

weird.

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
evil hackers from Serbia.

Re: [Zebra-pj-commit] "quagga/lib ChangeLog sockopt.c sockopt.h" [ In reply to ]

gdt at ir

Aug 19, 2004, 8:23 AM

Post #3 of 4 (396 views)

Permalink

> > char buff [sizeof (*cmsg) + SOPT_SIZE_CMSG_PKTINFO_IPV4()];
> >
> > msgh.msg_control = (caddr_t) buff;
> > msgh.msg_controllen = sizeof (buff);
> >
> > The macro in sockopt.h returns the actual size, but the CMSG_SPACE
> > padding is not done (see /usr/include/sys/socket.h on netbsd,
> > assuming this is the same on linux but not sure).
>
> Quite possible. My goal was simply to shift useage to a central place
> with minimum of fuss. The above was the most common way to allocate
> the cmsg buffer, so doing it so allowed me to remain bug compatible.

Sure, that's what I expected.

> For IPv6 it doesnt matter, cause thankfully v6 APIs are more
> consistent. But for v4, I'd prefer code not to have anything more
> than a vague notion of "i want to retrieve the ifindex", and we migth
> as well extend to v6.

> This probably implies wrapping up controll message access completely.

yes, probably does. So a function to create a cmsg structure
(chain?), and another to extract the info later, and then a free
routine. Unfortunately these need to be dynamically allocated because
the ALIGN routines apparently can call functions. Plus, that's more
likely MP-safe for down the road.

Re: [Zebra-pj-commit] "quagga/lib ChangeLog sockopt.c sockopt.h" [ In reply to ]

paul at clubi

Aug 19, 2004, 10:02 AM

Post #4 of 4 (405 views)

Permalink

On Thu, 19 Aug 2004, Greg Troxel wrote:

>> This probably implies wrapping up controll message access completely.
>
> yes, probably does. So a function to create a cmsg structure
> (chain?), and another to extract the info later, and then a free
> routine. Unfortunately these need to be dynamically allocated
> because the ALIGN routines apparently can call functions. Plus,
> that's more likely MP-safe for down the road.

Or the caller can pass in the cmsg (static or dynamic). we'll cross
that bridge when we come to it. ;)

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
La-dee-dee, la-dee-dah.