(usagi-users 03420) Re: Any particular reason that IPV6_TCLASS/IPV6_RECVTCLASS is not implemented?

"Peder Chr. Norgaard" <[email protected]>
Newsgroups gmane.linux.ipv6.usagi.users
Message-ID <[email protected]>
On Wed, 22 Jun 2005, David Stevens wrote:

>
> > But - do you have any opinions on the other issue I raised - the
> > transition issue?  I will probably have to hack a solution within my
> > project - there I need packages right here and now (such as quagga and
> > iputils) that are run-time independent on whether the kernel contains
> your

>
> If you're compiling on a system that supports both,
> then you can call setsockopt with IPV6_RECVx. If that
> returns ENOPROTOOPT (I think that's the errno for an
> invalid socket option-- should check), then call again
> with "IPV6_2292x" (or whatever the old value is defined
> as in the eventual patch).
>
> Alternatively, you can call with "IPV6_x" and a boolean
> option and if that returns "EINVAL", then call with
> "IPV6_RECVx".

Of course - that solves my problem.  I should have thought about
that myself.  Thank you for your answer.

> The ancillary data processing is a little trickier, but
> it'll either be the old value of IPV6_x or the new one,
> so you can treat those as equivalent in recvmsg. If you do a
> socket option as above and set a flag to remember which
> flavor of kernel you have, you can use the appropriate
> one for both sendmsg() and recvmsg(). Without that, for
> sendmsg(), you'll get "EINVAL" when using a new cmsg_type
> on a kernel that doesn't support it, so then you switch
> to the old value (assuming that's the cause of the
> EINVAL :-)). In the kernel.org patch, the old
> value is, e.g., "IPV6_2292PKTINFO" and the new one is
> "IPV6_PKTINFO".
>

Yes, I can see how that would work, too.  That will be useful in some of
my less critical applications which do use ancillary data.

thank you and best regards

--
Peder Chr. Nørgaard        	Senior System Developer, M. Sc.
Ericsson Denmark A/S, Telebit Division
Skanderborgvej 232         	tel: +45 30 91 84 31
DK-8260 Viby J, Denmark         fax: +45 89 38 51 01
        e-mail: [email protected]
(old e-mail 2000-2003: [email protected])
         (old e-mail 1992-2000: [email protected])
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.