IPV6_RTHDR with a type-0 routing header
Steinar H. Gunderson
I've tried attaching a type-0 routing header to my IPv6 packets with
setsockopt(..., IPV6_RTHDR, ...), but the kernel just returns EINVAL.
looking at the source, it seems it simply refuses anything that's not type-2;
should that really be right? I found the following commit:
http://kerneltrap.org/mailarchive/linux-netdev/2008/11/11/4064594
However, it only seems to change EPERM into EINVAL. I don't see any
reasonable explanation why it should not be simply success; in fact, RFC 3452
only seems to talk about using type-0 headers with this option.
Any ideas?
/* Steinar */
--
Homepage: http://www.sesse.net/
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Rémi Denis-Courmont
On Thu, 20 Aug 2009 13:11:52 +0200, "Steinar H. Gunderson"
<sgund...@bigfoot.com> wrote:
> I've tried attaching a type-0 routing header to my IPv6 packets with
> setsockopt(..., IPV6_RTHDR, ...), but the kernel just returns EINVAL.
> looking at the source, it seems it simply refuses anything that's not
> type-2;
> should that really be right? I found the following commit:
RT0 headers have been deprecated by IETF. The kernel refuses to use then on
purpose.
--
Rémi Denis-Courmont
Jens Rosenboom
> Hi,
>
> I've tried attaching a type-0 routing header to my IPv6 packets with
> setsockopt(..., IPV6_RTHDR, ...), but the kernel just returns EINVAL.
> looking at the source, it seems it simply refuses anything that's not type-2;
> should that really be right? I found the following commit:
>
> http://kerneltrap.org/mailarchive/linux-netdev/2008/11/11/4064594
>
> However, it only seems to change EPERM into EINVAL. I don't see any
> reasonable explanation why it should not be simply success; in fact, RFC 3452
> only seems to talk about using type-0 headers with this option.
>
> Any ideas?
How about RFC5095?
Steinar H. Gunderson
>> I've tried attaching a type-0 routing header to my IPv6 packets with
>> setsockopt(..., IPV6_RTHDR, ...), but the kernel just returns EINVAL.
>> looking at the source, it seems it simply refuses anything that's not
>> type-2;
>> should that really be right? I found the following commit:
> RT0 headers have been deprecated by IETF. The kernel refuses to use then on
> purpose.
Hm, OK. And no replacement has been proposed, the deprecation RFC just refers
to "future routing headers"...
/* Steinar */
--
Homepage: http://www.sesse.net/
Steinar H. Gunderson
> Hm, OK. And no replacement has been proposed, the deprecation RFC just refers
> to "future routing headers"...
It looks like I can use destination options instead, but those don't seem to
be too easy to use either. The kernel seems to demand that I put eight bytes
of padding at the end?
#define ipv6_optlen(p) (((p)->hdrlen+1) << 3)
Why the +1?
FWIW, the program I try to run is at http://home.samfundet.no/~sesse/v6fun.c .
If I replace "len" in the setsockopt call by "len + 8", the program runs and
the packets get the right option attached -- but also eight padding bytes.
Jens Rosenboom
> On Thu, Aug 20, 2009 at 02:18:20PM +0200, Steinar H. Gunderson wrote:
> > Hm, OK. And no replacement has been proposed, the deprecation RFC just refers
> > to "future routing headers"...
>
> It looks like I can use destination options instead, but those don't seem to
> be too easy to use either. The kernel seems to demand that I put eight bytes
> of padding at the end?
>
> #define ipv6_optlen(p) (((p)->hdrlen+1) << 3)
>
> Why the +1?
Because that matches the definition of the hdrlen field in RFC2460.
> FWIW, the program I try to run is at http://home.samfundet.no/~sesse/v6fun.c .
> If I replace "len" in the setsockopt call by "len + 8", the program runs and
> the packets get the right option attached -- but also eight padding bytes.
ERROR 404: Not Found.
Steinar H. Gunderson
>> It looks like I can use destination options instead, but those don't seem to
>> be too easy to use either. The kernel seems to demand that I put eight bytes
>> of padding at the end?
>>
>> #define ipv6_optlen(p) (((p)->hdrlen+1) << 3)
>>
>> Why the +1?
> Because that matches the definition of the hdrlen field in RFC2460.
Hm, in that case I guess it's glibc that has one too much indeed (I never
write this field).
>> FWIW, the program I try to run is at http://home.samfundet.no/~sesse/v6fun.c .
>> If I replace "len" in the setsockopt call by "len + 8", the program runs and
>> the packets get the right option attached -- but also eight padding bytes.
> ERROR 404: Not Found.
Sorry, http://home.samfundet.no/~sesse/v6opt.c
/* Steinar */
--
Homepage: http://www.sesse.net/
Steinar H. Gunderson
>> Because that matches the definition of the hdrlen field in RFC2460.
> Hm, in that case I guess it's glibc that has one too much indeed (I never
> write this field).
Yes indeed. It's fixed in more recent glibc:
[BZ #5760]
* inet/inet6_opt.c (inet6_opt_init): Fix ip6h_len computation.
Patch by Roland Bless <rol...@bless.de>.
Shan Wei
> Hi,
>
> I've tried attaching a type-0 routing header to my IPv6 packets with
> setsockopt(..., IPV6_RTHDR, ...), but the kernel just returns EINVAL.
> looking at the source, it seems it simply refuses anything that's not type-2;
> should that really be right? I found the following commit:
>
> http://kerneltrap.org/mailarchive/linux-netdev/2008/11/11/4064594
>
> However, it only seems to change EPERM into EINVAL. I don't see any
About the cause of changing EPERM into EINVAL, can refer to
http://marc.info/?l=linux-netdev&m=122046709502496&w=3.
--
Best Regards
Shan Wei
> reasonable explanation why it should not be simply success; in fact, RFC 3452
> only seems to talk about using type-0 headers with this option.
>
> Any ideas?
>
> /* Steinar */
--