Bug#966459: linux: traffic class socket options (both IPv4/IPv6) inconsistent with docs/standards
Ben Hutchings dixit:
>ip(7) also doesn't document IP_PKTOPIONS.
Hmm, I don’t use IP_PKTOPIONS though. I’m not exactly sure I found
the correct place in the kernel for what I do.
On the sending side, I use setsockopt with either
IPPROTO_IP,IP_TOS or IPPROTO_IPV6,IPV6_TCLASS to
set the default traffic class on outgoing packets.
On the receiving side I use setsockopt with either
IPPROTO_IP,IP_RECVTOS or IPPROTO_IPV6,IPV6_RECVTCLASS
to set up the socket then recvmsg to get a cmsg(3) of
IPPROTO_IP,IP_TOS/IPPROTO_IPV6,IPV6_TCLASS from which
I read the traffic class octet.
These are where I believe I found inconsistencies
between code and documentation.
>Those are two different APIs though: recvmsg() for datagram sockets, vs
>getsockopt(... IP_PKTOPTIONS ...) for stream sockets. They obviously
>ought to be consistent, but mistakes happen.
OK, I’m currently looking at the datagram case only.
This may change later if there’s enough time.
>I see no point in changing the IPv6 behaviour: it seems to be
>consistent with itself and with the standard
Not really: if the kernel writes an int and userspace reads
its first byte, it only works by accident on little endian,
but not elsewhere.
>so only risks breaking user-space that works today.
Hrm. It risks breaking userspace that reads an int. But the
RFC clearly says it should read the first byte, not an int.
>But you should know that the highest priority for Linux API
>compatibility is to avoid breaking currently working user-space. That
>means that ugly and inconsistent APIs won't get fixed if it causes a
>regression for the programs people actually use. If the API never
>worked like it was supposed to on some architectures, that's not a
>regression, and is lower priority.
This is why I just put this up for discussion instead of
requesting a specific change.
That being said, given that the IPv6 API is *only* documented
in the RFC and *not* documented in the Linux manpages…
(Perhaps codesearching for IPV6_TCLASS might also help.
It’s unclear how many users this has…)
In the end, what I really want, is clear documentation for
how I should implement the following file that it works on
Linux, and ideally also other systems implementing the RFC
API (FreeBSD supposedly does but needs testing):
https://github.com/tarent/ECN-Bits/blob/master/linux-c/lib/ecn.c
Given that there’s no documentation, trying to read the
coffee grounds from the kernel source, finding it doesn’t
even match the RFC (which, again, doesn’t match what itojun
proposed, for some reason), does not instigate trust in the
things I *think* I’ve found.
bye,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Reply to: